ptv visum-fundamentals

VISUM 11.52 – Fundamentals

Copyright© 25.2.11 PTV AG, KarlsruheAll brand or product names in this document are trademarks or registered trademarks of thecorresponding companies or organizations. All rights reserved.

Legal agreementsThe information contained in this documentation is subject to change without notice andshould not be construed as a commitment on the part of the vendor.This manual may not be reproduced , stored in a retrieval system, or transmitted, in any form,or by any means, electronic, mechanical, photocopying, recording, or otherwise, edited ortranslated, except for the buyer's personal use as permitted under the terms of the copyright,without the prior written permission of PTV AG.

Warranty restrictionThe content accuracy of this manual is not warranted. We are grateful for any information onerrors.

ImprintPTV AG76131 KarlsruheGermanyTel: +49 721 9651-300Fax +49 721 [email protected]

Last amended 25. Februar 2011 EN-US nF

Structure

Structure

1 Program basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4 Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

5 User Model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

6 User Model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

7 Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

8 Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . 613

9 Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . 625

10 GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633

11 Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

12 Tabular and graphic display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755

© PTV AG I

Structure

II © PTV AG

Contents

Contents

1 Program basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Network model – the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.2 Demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.3 Impact models – methods to calculate the impact of traffic . . . . . . . . . . . . . . . . . .61.4 Evaluation of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71.5 Comparing and transferring networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

1.5.1 Comparing version files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5.2 Network merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5.3 Model transfer files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1 Network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

2.1.1 Transport systems, modes and demand segments . . . . . . . . . . . . . . . . . . . . . . 222.1.2 Nodes and turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.4 Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.1.5 OD pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.1.6 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.1.7 Main nodes and main turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.8 Main zones and main OD pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.1.9 Territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1.10 Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1.11 Stop hierarchy: Stops, stop areas, stop points . . . . . . . . . . . . . . . . . . . . . . . . . . 412.1.12 PuT operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.1.13 PuT vehicles: vehicle units and vehicle combinations. . . . . . . . . . . . . . . . . . . . . 452.1.14 The line hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.1.15 System routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.1.16 Points of Interest (POI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.1.17 Count locations and detectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.1.18 Toll systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.1.19 GIS objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.20 Screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.1.21 Junction modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662.1.22 Network check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.2 Spatial and temporal correlations in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . .712.2.1 Calendar and valid days . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.2.2 Time reference of the demand (time series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732.2.3 Time reference of volumes: analysis time intervals and projection . . . . . . . . . . . 752.2.4 Temporal and spatial differentiation of calculation results. . . . . . . . . . . . . . . . . . 792.2.5 Adjustment of the capacities to the demand values . . . . . . . . . . . . . . . . . . . . . . 80

2.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

© PTV AG III

Contents

2.3.1 Direct attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812.3.2 Indirect attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822.3.3 User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872.3.4 Time-varying attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

2.4 Subnetwork generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .932.5 The surface data model in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

2.5.1 Tables in the surface model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962.5.2 Multi-part surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3 Demand model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.1 Demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

3.1.1 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043.1.2 Demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043.1.3 Time series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.1.4 Demand model structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.1.5 Population groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.1.6 Activities, Activity Pairs, Activity Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.1.7 Demand strata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.2 Demand modeling procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1093.2.1 Standard Four-Stage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103.2.2 EVA Model for Passenger Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.2.3 Activity chain based model (VISEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443.2.4 Estimate gravitation parameters (KALIBRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563.2.5 Gravity model calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.2.6 Modal Split (standardized assessment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653.2.7 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

3.3 Displaying and Editing Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1703.3.1 Displaying matrices in tabular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713.3.2 Matrix values displayed as histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.3.3 Transpose, reflect upper or lower triangle, apply mean value . . . . . . . . . . . . . . 1723.3.4 Copy, paste and apply diagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.3.5 Round. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.3.6 Form reciprocal, raise to power, take logarithm, exponential function . . . . . . . . 1733.3.7 Maximum or minimum formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733.3.8 Make symmetrical: Mean value upper / lower triangle . . . . . . . . . . . . . . . . . . . . 1733.3.9 Calculate the combination of matrices and vectors . . . . . . . . . . . . . . . . . . . . . . 1733.3.10 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733.3.11 Converting zone and main zone matrix into each other . . . . . . . . . . . . . . . . . . . 1753.3.12 Extending matrices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1763.3.13 Aggregating matrix objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773.3.14 Splitting (extending) matrix objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

3.4 Matrix correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1793.4.1 Updating demand matrix with TFlowFuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1793.4.2 Projecting PrT Path Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873.4.3 Calibrating a PrT matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

4 Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

IV © PTV AG

Contents

4.1 The types of impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1894.1.1 The user model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1894.1.2 The operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1904.1.3 The environmental impact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

4.2 Impedance functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1914.3 Paths in PrT and PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1924.4 Skims / indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193

4.4.1 Skim matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934.4.2 Global indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

5 User Model PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1955.1 Overview of the PrT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . .1955.2 Example network for the PrT assignment procedures . . . . . . . . . . . . . . . . . . . .1975.3 PrT Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1995.4 Impedance and VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

5.4.1 Impedance of a PrT route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2005.4.2 Predefined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2025.4.3 Example of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . . 2095.4.4 User-defined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

5.5 Impedances at node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2105.5.1 Impedance of turns from Turns VD function . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125.5.2 Impedance of turns from Nodes VD function . . . . . . . . . . . . . . . . . . . . . . . . . . 2125.5.3 Intersection Capacity Analysis according to the Highway Capacity Manual

(ICA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2135.5.4 Signal timing optimization.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

5.6 PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2715.7 Distribution of the traffic demand to PrT connectors. . . . . . . . . . . . . . . . . . . . . .2725.8 Blocking back model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273

5.8.1 General notes on the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2755.8.2 Procedure of the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

5.9 Convergence criteria of the assignment quality . . . . . . . . . . . . . . . . . . . . . . . . .2885.10 Distribution models in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289

5.10.1 The Kirchhoff model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2905.10.2 The Logit model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2905.10.3 The Box-Cox model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2915.10.4 The Lohse model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2925.10.5 Lohse model with variable beta in the assignment . . . . . . . . . . . . . . . . . . . . . . 2935.10.6 Comparison of the distribution models for the assignment . . . . . . . . . . . . . . . . 295

5.11 Incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2965.11.1 Example of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2965.11.2 Procedure of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2985.11.3 Input and output attributes of the incremental assignment . . . . . . . . . . . . . . . . 2995.11.4 Evaluation of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

5.12 Equilibrium assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301

© PTV AG V

Contents

5.12.1 Evaluation of the equilibrium assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3025.12.2 Introductive example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 3035.12.3 Input and output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . 3055.12.4 Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3075.12.5 Calculation example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 311

5.13 Linear User Cost Equilibrium (LUCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3125.13.1 Mathematical formulation and theoretical framework. . . . . . . . . . . . . . . . . . . . . 3135.13.2 Local user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3155.13.3 Descent direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3195.13.4 Assignment algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3225.13.5 Input and output attributes of the equilibrium assignment (LUCE). . . . . . . . . . . 3235.13.6 Persistent storage of bushes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

5.14 Equilibrium_Lohse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3245.14.1 Example of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3255.14.2 Input and output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . 3285.14.3 Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . 3305.14.4 Evaluation of the Equilibrium_Lohse procedure. . . . . . . . . . . . . . . . . . . . . . . . . 331

5.15 Assignment with ICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3325.15.1 Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3325.15.2 Evaluation of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3335.15.3 Input and output attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . 3345.15.4 Description of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3375.15.5 Used turn VDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

5.16 Stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3425.16.1 Evaluation of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3425.16.2 Input and output attributes of the stochastic assignment . . . . . . . . . . . . . . . . . . 3425.16.3 Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3445.16.4 Similarity of routes and commonality factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3475.16.5 Example for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

5.17 TRIBUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3535.17.1 Input and output attributes of the TRIBUT procedure . . . . . . . . . . . . . . . . . . . . 3535.17.2 Basics of the assignment with toll consideration . . . . . . . . . . . . . . . . . . . . . . . . 3555.17.3 LogN distribution of the random variable VT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3615.17.4 Route search - efficient frontier as exclusive criterion . . . . . . . . . . . . . . . . . . . . 3635.17.5 Route split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3635.17.6 Route balancing in the equilibrium iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3645.17.7 Route distribution in the iteration of the TRIBUT Equilibrium_Lohse . . . . . . . . . 3655.17.8 List outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

5.18 Dynamic User Equilibrium (DUE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3675.18.1 Fields of application of the Dynamic User Equilibrium procedure . . . . . . . . . . . 3675.18.2 Overview of the dynamic equilibrium assignment model . . . . . . . . . . . . . . . . . . 3675.18.3 Mathematical framework of the Dynamic User Equilibrium . . . . . . . . . . . . . . . . 3705.18.4 Network performance model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3745.18.5 Assignment of the network demand (network loading) . . . . . . . . . . . . . . . . . . . 3845.18.6 The overall model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3865.18.7 Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

VI © PTV AG

Contents

5.18.8 Input and output attributes of the dynamic user equilibrium (DUE). . . . . . . . . . 3905.19 Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396

5.19.1 Evaluation of the Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . 3995.19.2 Input and output attributes of the dynamic stochastic assignment . . . . . . . . . . 3995.19.3 Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . 400

5.20 NCHRP 255 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4025.21 Assignment analysis PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403

6 User Model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4076.1 Overview of PuT assignment procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4076.2 Example network for the PuT assignment procedures . . . . . . . . . . . . . . . . . . . .4096.3 PuT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4126.4 PuT skims. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414

6.4.1 PuT skim categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4146.4.2 Perceived journey time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4246.4.3 Fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4246.4.4 Temporal utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

6.5 PuT impedance functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4256.6 Distribution of the travel demand to PuT connectors . . . . . . . . . . . . . . . . . . . . .4266.7 Allocation of skims with reference to lines/links . . . . . . . . . . . . . . . . . . . . . . . . .4276.8 Transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .428

6.8.1 Evaluation of the transport system-based assignment . . . . . . . . . . . . . . . . . . . 4296.8.2 Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . . 4296.8.3 Steps of the transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . 430

6.9 Headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4306.9.1 Evaluation of the headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . 4316.9.2 Headway calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4326.9.3 Generalized costs as impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4336.9.4 Choice models for boarding decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4346.9.5 The complete choice model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4406.9.6 The search in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4456.9.7 Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . . 4466.9.8 Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

6.10 Timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4526.10.1 Evaluation of the timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . 4526.10.2 Connection search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4536.10.3 Connection preselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4556.10.4 Perceived journey time PJT of a connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 4556.10.5 Connection Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4586.10.6 Handling of public transport systems of the PuT-Aux type . . . . . . . . . . . . . . . . 4656.10.7 Opening of the timetable-based assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . 466

6.11 Assignment analysis PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4756.12 PuT Passenger surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477

6.12.1 Basic data of a passenger trip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

© PTV AG VII

Contents

6.12.2 Passenger onboard survey: Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4806.12.3 Read survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4816.12.4 Plausibilization of survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4816.12.5 Assignment of survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

7 Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4897.1 Application areas and scope of operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .489

7.1.1 Calculation of indicators on different aggregation levels . . . . . . . . . . . . . . . . . . 4907.1.2 Introductory examples for PuT indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

7.2 Network objects in the operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4987.3 Typical work flow in the PuT operator model . . . . . . . . . . . . . . . . . . . . . . . . . . .4997.4 Line blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .500

7.4.1 Introduction into the line blocking procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 5007.4.2 Application example for line blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5047.4.3 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5157.4.4 Line blocking description without vehicle interchange . . . . . . . . . . . . . . . . . . . . 5287.4.5 Line blocking description with vehicle interchange. . . . . . . . . . . . . . . . . . . . . . . 5387.4.6 Displaying and editing blocks in the timetable editor . . . . . . . . . . . . . . . . . . . . . 5427.4.7 Vehicle requirement and line blocking indicators . . . . . . . . . . . . . . . . . . . . . . . . 5437.4.8 Description of the PuT interlining matrix procedure . . . . . . . . . . . . . . . . . . . . . . 545

7.5 PuT fare model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5467.5.1 Short overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5467.5.2 Ticket types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5497.5.3 Fare systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5597.5.4 Fare calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5637.5.5 Application of fares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

7.6 PuT Operating Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5687.6.1 Demonstration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5697.6.2 Indicators for line route and timetable evaluation. . . . . . . . . . . . . . . . . . . . . . . . 5727.6.3 Measurement of the transport supply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5767.6.4 Measurement of the network performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5807.6.5 Calculation of operating costs and fare gains (revenues) . . . . . . . . . . . . . . . . . 5847.6.6 Calculation of the operating costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5857.6.7 Calculation of the fare revenues (revenue calculation) . . . . . . . . . . . . . . . . . . . 5947.6.8 Basic calculation principles for indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603

8 Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6138.1 Noise volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .613

8.1.1 Noise-Emis-Rls90 procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6138.1.2 The Noise-Emis-Nordic procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6148.1.3 Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

8.2 Air pollution emissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6168.2.1 Pollution-Emis procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6168.2.2 Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

8.3 Emission calculation according to HBEFA 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . .6188.3.1 Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

VIII © PTV AG

Contents

8.3.2 Basics of the HBEFA calculation in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

9 Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6259.1 EWS – basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6259.2 EWS link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6289.3 EWS – Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6309.4 EWS – Cost-benefit analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .630

10 GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63310.1 Connection to the Personal Geo Database and GIS objects . . . . . . . . . . . . . . .63310.2 Shape files as a GIS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .634

10.2.1 Importing shape files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63410.2.2 Exporting shape files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

10.3 Intersect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63810.4 Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64610.5 Processing the network display with graphic objects . . . . . . . . . . . . . . . . . . . . .648

10.5.1 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64810.5.2 Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64810.5.3 Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64910.5.4 Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

10.6 GPS tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653

11 Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65511.1 Flow bundles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .655

11.1.1 Flow bundle definition by selecting network objects . . . . . . . . . . . . . . . . . . . . . 65711.1.2 Flow bundle definition through selection of traffic types . . . . . . . . . . . . . . . . . . 66011.1.3 Combination of flow bundle criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66211.1.4 Flow bundles with alternative routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

11.2 Isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66711.2.1 PrT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66911.2.2 PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67111.2.3 Combination of PrT and PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

11.3 Shortest path search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .676

12 Tabular and graphic display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67912.1 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .680

12.1.1 Specific network object lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68012.1.2 Matrix list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68412.1.3 Evaluation lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684

12.2 Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68612.3 Categorized display with attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68812.4 Labeling with tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69212.5 Labeling with diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69312.6 Turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .695

© PTV AG IX

Contents

12.7 Desire lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69612.8 Stop catchment areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69812.9 Lane allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70012.10 2D display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70212.11 Timetable network graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70412.12 Column charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70612.13 Evaluations in the timetable editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707

Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755

X © PTV AG

1 Program basics

VISUM is a software system that integrates all individual and public transport types in a singlemodel. It is supplemented with the microscopic traffic simulation system VISSIM. Together theprograms make up the ptv vision system. Most basic data supplied with transport informationand planning systems can be managed consistently with VISUM and updated using a networkeditor. Unlike simple GIS systems, VISUM allows complex relationships within single orseveral transport systems to be retained. In this way, an appropriate transport model can becreated.The transport model normally consists of a demand model, a network model based on VISUMand various impact models (illustration 1):• The demand model contains the travel demand data. Information on the demand within

the planning area is required for the analysis of transportation networks. Demand matricescan be determined partially through surveys. That is why mathematical models are used toreproduce real demand ratios, which calculate the traffic flows between the zones of theplanning area on the basis of the structure and behavior data, the spatial utilizationstructure and the transport system. In VISUM the Standard-4-Step, EVA and VISEMmodels are integrated. This is how you can create travel demand matrices in the program(see "Demand model" on page 103).

• The network model describes the relevant supply data of a transport system. It consists oftraffic zones, nodes, public transport stops, links and public transport lines with theirtimetable. Transport supply data can be visualized with VISUM and edited interactively withdifferent methods.

• The impact model takes its input data from the demand model and the impact model.VISUM provides different impact models to analyze and evaluate the comprehensivetransport system. A user model simulates the travel behavior of public transportpassengers and car drivers (see "User Model PuT" on page 407 and "User Model PrT" onpage 195). It calculates traffic volumes and service skims (such as journey time or numberof transfers). An operator model determines operational indicators of a public transportservice, like service kilometers, vehicle kilometers, number of vehicles or operating costs(see "Operator model PuT" on page 489). Derived from the demand data, the estimatesallow line related revenues for a line costing calculation. An environmental impact modeloffers several methods to assess the impacts of motorized transport on the environment(see "Environmental impact model and HBEFA" on page 613).

• VISUM displays the calculated results in graphic and tabular form and allows graphicalanalyses of results. In this way, for example, routes and connections per OD pair, flowbundles, isochrones, and node flows can be displayed and analyzed. Indicators such asjourney time, number of transfers, service frequency, and many more are computed asskim matrices.

• Different versions can be compared by a version comparison or the network mergeprocess. Via model transfer files model modifications can be exchanged between themodels.

1 © PTV AG

Chapter 1: Program basics

Illustration 1: VISUM network model and impact model

A transportation model, like all models represents an abstraction of the real world. The aim ofthe modeling process is system analysis, forecasting and model-based preparation fordecisions taken in the real world.In the following, especially the network data model and the procedures available in VISUM aredescribed and explained in a simple way.

1.1 Network model – the transport supplyA network model representing the transport system must describe the spatial and temporalstructure of the transport supply. For this reason, the network model consists of severalnetwork objects which contain relevant data about the link network, the lines and timetablesand trafficzones. The most important network object types in VISUM are described here.• Zones (also called traffic cells) describe areas with a particular land use and their location

in the network (for example residential areas, commercial areas, shopping centers,schools). They are origin and destination of trips within the transport network, which meanszones and the transport network are connected through connectors.

Network modelcontains supply data:

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

Transport modelTransport model

Demand modelcontains demand data:

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

Impact modelcontains 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.

ResultsListings and statistics (calculated attributes of network objects and routes)Indicator matrices (journey time, service frequency, ...)Graphical analysis (flow bundles, isochrones, ...)Plots

2 © PTV AG

Chapter 1.2: Demand model

• Nodes are objects which define the position of intersections in the link network and ofswitches 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 aparticular 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 timepenalty.

• Connectors connect zones to the link network. They represent the distance to be coveredbetween a zone’s center of gravity and the nodes/stops of the network.

• Stops are subdivided into stop areas and stop points served by lines where passengersmay board or alight.

• Lines which are listed with a name in a timetable usually go into both directions. A line canconsist of several line variants, so-called line routes which differ for example, in their routecourses. Line routes describe the spatial course of line services, for each line route one orseveral time profiles can be defined.

• Territories are network objects, which can be used for example, to illustrate districts orcounties. Based on a polygon which defines the territorial border, PrT and PuT indicatorsfor regular or single PuT line services can precisely be accounted for each zone.

Every network object is described by its attributes. Attributes can be subdivided as follows:• Input attributes such as link lengths or link numbers• Calculated attributes (output attributes) such as boarding passengers at a stop or the

number of assigned vehicles. They are only filled with values in the course of calculationprocedures.

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

1.2 Demand modelTravel demand develops when a sequence of activities (living - working - shopping - living)cannot be carried out at the same location and thus requires a journey. The travel demand is saved in a matrix, where all zones contained in a traffic model are incolumns and rows.• A matrix element of the PrT has the unit car trips, matrix element of the PuT has the unit

OD trips (do not mistake with the trip of a PuT line!). It contains the number of traveldemand from a traffic zone i to a traffic zone j.

• A travel demand matrix refers to a time interval (analysis time interval) and thus onlycontains 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).

3 © PTV AG


• A demand matrix is assigned to exactly one demand segment. A demand segmentdescribes a group of road users with homogeneous travel behavior.

Travel demand can be divided into surveyed and calculated demand as well as into today'sand future demand.Surveyed travel demand describes the number of trips and the trip distribution within a fixedtime interval for an existing transport supply system. It represents a snapshot of the currenttraffic situation and cannot be reproduced again practically. An exact survey of today'scurrent travel demand in an area of interest is not possible in practice because all travelerswould have to be interviewed at the same time. For this reason, only a representative, randomsample of travelers is interviewed to determine travel demand for the purposes oftransportation 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 tripdistribution. To calculate travel demand, demand models are used which, for example,differentiate between the three steps of trip generation, trip distribution and mode choice. Thecalculated 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, andtoday's transport supply system.

• Forecasted travel demand is based on data on future land use, future population andeconomic structure and the future transport supply system.

An overview of the procedures for determining travel demand can be found in LEUTZBACH etal. (1988).Within VISUM all 4 stages of the classical traffic model (four-stage model) can be calculated,besides traffic assignment (choice and volume of the route to get from origin zone todestination zone) the other three stages Trip generation, Trip distribution and Mode choice(choice of means of transport), too.In the first step of the classical model, Trip generation, the production and attraction (origin anddestination traffic) of each zone is determined on the basis of socio-demographic data (forexample, number of inhabitants and jobs). These production and attraction values define thetotals of the total demand matrix, which is determined by means of relevant indicators (forexample, journey times, fares etc.) in the second step, Trip distribution. In the third step thetotal demand matrix is distributed onto the different traffic modes (for example, PrT, PuT) onthe basis of mode-specific indicators. In a fourth step the resulting mode-dependent demandmatrices can be assigned to the supply VISUM network) by means of the PrT and PuTassignment procedures in order to obtain link volumes and new indicators. These indicatorscan again be used as inputs for trip distribution or mode choice of a new demand calculation.The Go to the operation operation allows iterating the calculations until a convergencecriterion concerning link volumes or matrix values is fulfilled.VISUM contains three alternative calculation models for the demand modeling.• The Standard-4-Step Model is based on North American practice for aggregated demand

models (see "Standard Four-Stage Model" on page 110).• The EVA Model is another aggregated demand model for passenger demand. It differs

from the Standard-4-Step Model by a simultaneous trip distribution and mode choice as

4 © PTV AG

Chapter 1.2: Demand model

well as by its particular method of balancing the differences between origin and destinationtraffic (see "EVA Model for Passenger Demand" on page 115).

• When calculating demand matrices, the VISEM model (traffic in cities generation model)takes into consideration activity chains which homogenous-behavior user groups (forexample employees with or without a car, pupils, students) perform during the course of theday (see "Activity chain based model (VISEM)" on page 144).

The Matrix Editor integrated in VISUM supports matrix processing and provides a gravitymodel.The calculation models are based on specific VISUM demand objects describing thecharacteristics of trip purposes and road users. Person groups combine road users featuringcomparable mobility behavior to groups. The break-down of the population into person groupsmay be based on their job status (employed, students, retired persons) and (optionally) theircar ownership (with/without car). Activities are activities or locations of a person in the courseof the day which are not traffic related (work, school, home). Activity pairs describe transitionsbetween two activities and may imply trips from one place to the other (home - work, home -school). They are then called trip purposes.A demand stratum links one or several person groups with an activity. Almost allcalculations of the first three stages of the model are carried through separately for eachdemand stratum and their results stored separately for a better illustration and verification. Theresulting demand matrices always have the unit [persons].By aggregating the demand strata to demand segments parts of the demand jointly to beassigned are combined prior to the fourth stage, Traffic assignment. Hereby, the PrT demandmatrices are converted into the [Vehicles] unit by dividing the demand stratum matrices by theoccupancy rate of the respective transport system.

Temporal Distribution of Travel DemandThe trips from one traffic zone to another traffic zone in reality take place at different times. Thetemporal distribution of travel demand within the analysis period is described by a start timeand a time series when modeling in VISUM. The time series is taken into consideration at thePuT assignments and the dynamic PrT assignment. The demand distribution is ignored in thecase of static PrT assignments. Temporal distribution of the trips within each time interval of anobserved 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 onwhich the period referred to by the demand in the matrix starts. The end of the period iscalculated from the length of the assigned time series.Time series can be defined in two different ways.• Time series by percentage of a demand matrix• As a distribution curve consisting of several demand matricesA time series by percentage specifies the proportion of trips with the desired departure timewithin the respective time interval. Demand distribution curves can cover more than 24 hoursif a weekly or annual calendar is used. An equal distribution of travel demand during theobserved time period is assumed as default. Instead of this default, a user-defined demanddistribution curve can be specified for the entire matrix. This user-defined demand distributioncurve can be overwritten again for selected pairs of origin-destination zone types with specificdemand distribution curves. In this way, it is possible to specify deviating distribution curves forzones, for example, with known structural features (for example purely residential or

5 © PTV AG


commercial areas) that reflect the different traffic loads in one direction (illustration 2) at certaintimes of the day for journeys between home and work.

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

A time series of demand matrices allocates a separate matrix to each time interval whichcontains the demand with the desired departure time in the respective time interval. It shouldbe used if for example matrices on an hourly basis already exist based on a trip generationmodel. Contrasting time series, here the time dependent course of the demand can be freelyselected for each matrix item. However, the data entry expenditure and the memoryrequirements are higher accordingly, because several complete matrices are supplied.

1.3 Impact models – methods to calculate the impact of trafficA transport supply system has diverse impacts which may vary because of measures (forexample 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 usersUsers of infrastructure for private transport are mostly car drivers and their passengers, butalso non-motorized travelers such as cyclists and pedestrians. Users of public transport arepublic transport passengers.

Transport operatorsThe road network is usually operated by the state, federal states or communities andincreasingly by private investors. These operators of the road network have to decide oninvestments for the construction and maintenance of road infrastructure. PuT operators are thetransport companies and transportation agencies. In the broader sense, the PuT contractorsalso belong to the operators. To offer public transport service, PuT operators develop line

05

10152025303540

7:00 8:007:30 9:008:30

%

6 © PTV AG

Chapter 1.4: Evaluation of results

networks and timetables from which the user can then choose connections. To organizedrivers and vehicles, PuT operators develop vehicle employment plans and rosters.

Models to calculate the impact of trafficVISUM includes different models which are used to determine the impacts of given transportsupply.• Different assignment procedures make it possible to assign current or anticipated travel

demand to existing or planned transport supply. The most important information of theseassignment procedures are network object volumes (link volumes for example).

• The connection quality of each transport systems or for the selected demand segments isdescribed via skims, which can be output in skim matrices (impedance matrices).

• The environmental model makes it possible to determine noise and/or pollution emissionsof motorized private transport for traffic volumes in the existing or planned transportnetwork.

• 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. Thenumber of required vehicles is computed by a line-blocking calculation procedure, whichare necessary to be able to offer the PuT supply.

1.4 Evaluation of resultsTransportation demand and the results of the impact models can be evaluated and outputunder different aspects. The following functionalities are available (see "Tabular and graphicdisplay" on page 679 and "Interactive analyses" on page 655).• Flow bundles, which filter demand segment-specific paths traversing network objects

selected by the user (nodes, links, zones, stop points, stop areas and stops)• Evaluation of network volumes according to traffic types (origin, destination, through,

external, internal and bypassing internal trips)• Turn volumes, which display PrT turning flows at intersections• Isochrones for classifying the reachability of network objects and for comparing PuT

journey times and PrT travel times• Graphical shortest path search for the PrT, which visualizes the shortest path between

zones or nodes in the network for a PrT transport system• Graphical shortest path search for the PuT, which visualizes the shortest path between

zones, nodes or stop areas. The shortest paths can be based on transport systems ordetermined on the basis of the timetable provided in VISUM

• Skim matrices describe different properties for each relation from origin zone to adestination zone in the traffic model. Each skim (such as the in-vehicle-time) is derived fromthe properties of all paths found from origin zone to a destination zone

• Lists for all network object types, which allow a tabular display of all attribute values of anetwork 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

7 © PTV AG


volumes calculated in the assignment and the observed values, and the assignment modelcan continue to be calibrated

• Column charts for the display of time rows (for example link volumes in the course of theday)

• Graphic and tabular display of trips in the Timetable editor This is how volumes from theassignment can be displayed as bars for each journey.

• Comparing and transferring networks (Network merge, Version comparison, Modeltransfer file)

1.5 Comparing and transferring networks VISUM offers various possibilities to compare and transfer networks and version files:• Version comparison (see "Comparing version files" on page 9)• Network merge (see "Network merge" on page 12)• Model transfer files (see "Model transfer files" on page 15)

Version comparison and network mergeTo compare transport networks, the Version comparison function has been introduced fromVISUM 11.5 onwards in addition to the classical „Difference network“. At the same time thedifference network has been renamed as Network merge since the merging of different datais the main feature of this function. The following table gives an overview and lists thedifferences between the two functions. In most cases you will be working with the new versioncomparison in future.

Model transfer filesA model transfer file allows recording the modifications required to transfer a model, i.e. acombination of network data and OD demand data, to another model. You generate the modeltransfer file from two version files, whereby data can be limited to selected network object types

Version comparison Network merge (previously Difference network)

Normal working is possible Simply additional evaluation attributes are created, which can be deleted or updated, if required.

Special mode serving mere evaluation purposes, hardly editable, not saveable

Simultaneous comparison of various variants possible

Comparison with exactly one variant

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

Evaluation attributes replace original attributes, i.e. graphic parameters, filters etc. have to be adjusted.

Evaluation attributes (beside value of original network): Value of comparison network, difference, relative difference, minimum, maximum

Evaluation attributes: Value of original network, value of comparison network, difference, DiffNet (see "Network merge" on page 12)

Attributes and network objects to be compared can be selected.

All attributes and network object types are compared.

Updatable by pushing a button Not updatable

8 © PTV AG

Chapter 1.5: Comparing and transferring networks

or attributes. You can exchange modifications between the different version files at any time,and equally maintain several scenarios.

1.5.1 Comparing version filesThe version comparison is used for a quick and easy addition of attribute values from othernetwork variants and their comparison with the values of the current network. Network objectswith the same keys are compared. Therefore, compared to the Network merge function, thisfunction is more suitable for networks basically including the same network objects.

Use cases for version comparisonExample 1: You have increased the capacity of a link corridor or extended the timetable of PuTlines. By comparing the assignment attributes of each version comparison you can analyzehow 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 likeVolume and Passengers transferring as well as the modified OD demand data directly bymeans 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 vehiclecombination, by means of the version comparison.

The version comparisonRead one or several version files to an already opened version file for comparison. As a resultof this version comparison VISUM automatically creates attributes containing the selectedattribute values of the other version files. You can recognize the newly added attributesbecause the attribute name (Table 1) is suffixed by the code labeling the comparison.In case of numerical attributes VISUM automatically adds various comparison attributes: Foreach numerical attribute compared additional attributes specifying the absolute difference, therelative deviation as well as the minimum and maximum are created. By way of example the following table lists the seven additional attributes which are created forthe numerical attribute Volume PrT (AP) when comparing version A with version B.

Note: Using the model transfer file you can transfer the network data and the OD demanddata of the compared models (see "Model transfer files" on page 15).

New attribute Short name German Long name German

Value of network B VolVehPrT,B(AP) Volume PrT [Veh] B (AP)

Absolute difference A-B VolVehPrT,-B(AP) Volume PrT [Veh] - B (AP)

Absolute difference B-A VolVehPrT,B-(AP) Volume PrT [Veh] B - (AP)

Relative deviation regarding B (A-B)/B VolVehPrT,-B%(AP) Volume PrT [Veh] - B % (AP)

Relative deviation regarding A (B-A)/A VolVehPrT,B-%(AP) Volume PrT [Veh] B - % (AP)

Minimum of both attribute values VolVehPrT,B,Min(AP) Volume PrT [Veh] B Min (AP)

Maximum of both attribute values VolVehPrT,B,Max(AP) Volume PrT [Veh] B Max (AP)

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

9 © PTV AG


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

Illustration 3: Network of the original version

10 © PTV AG


Illustration 4: Network of the version used for version comparison

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

Above all, you can convert the attribute values of the additionally read version easily into user-defined attributes so that they are still available after the version comparison has beenterminated.

11 © PTV AG


The reference to the additionally read data is not updated automatically, but can be updated, ifrequired. Thus, for example, you can read the same version file at different times, thus tracingthe modifications.The reference to the additionally read data can be dropped again at any time.

Special cases of version comparisonsIf the compared versions do not contain the same network objects or attributes, the followingwill happen (opened version: A, additionally read version: B)• If an object exists in B only, it does not appear in the version comparison.• If an object exists in A only, the attribute values of B are empty.• If an attribute exists in B only, it cannot be selected for the version comparison.• If an attribute exists in A only, it is not compared.• If the subattributes of an attribute are different in A and B, only those subattributes valid in

A are considered. Subattributes which do not exist in B have an empty attribute value.

1.5.2 Network merge

The network merge function provides for the comparison of two transport networks and thedisplay 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 mergeFor 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 fordifferent 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 havedifferent values. If, for example, you model different expansion statuses of the same networkin two version files, there will be deviations in the Number of lanes and Capacity PrTattributes of some links, for instance. Furthermore, network objects can only be in one of thetwo models and missing completely in the other. If for example, one of the two models containsa planned case with an additional by-pass, the respective links will be missing in the othermodel. The following illustrations show both cases. Network 1 compared to network 2 contains onelink more, furthermore the links have different attribute values TSysSet and v0PrT.

Note: Prior to VISUM version 11.5 this function was called Difference network.

12 © PTV AG


Illustration 6: Network 1 for the merge network

Illustration 7: Network 2 for the merge network

The merge networkThe two models to be compared, Network 1 and Network 2, have to be available as versionfiles. If you open both version files in the network merge mode, VISUM shows a so-calledmerge network. The merge network is created by first identifying all objects which occur in bothmodels. Two objects are the same if they have identical key attributes. Compulsory referencesto other networks (for example, the keys for links from From Node and To Node) mustcorrespond. Exceeding this intersection of the network objects, objects which only occur in oneof the two models are also transferred to the merge network. This is the main differencecompared 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 thestatus of the network object.• In network 1: Only network 1 contains the object, network 2 does not.• In network 2: Only network 2 contains the object, network 1 does not.• DIFF: Network 1 and 2 both contain the object, with at least 1 attribute having different

values in both networks.• EQ: Network 1 and 2 both contain the object, all attributes are identical in both networks.• In no network: The object exists only in the merge network and has no attribute values.

Example: A turn between links from network 1 and one from network 2. Such objects are

13 © PTV AG


created in rare cases so that the merge network is a permissible VISUM network. Theyhave no real equivalent and have no attribute values.

In the merge network, a read-only attribute is created for each network 1 and/or network 2attribute (VISUM attributes and user-defined attributes). This attribute has the followingproperties:• The attribute has identical properties as in network 1 or network 2.• The attribute has a subattribute with values Net1, Net2 and Diff. Net1 and Net2 indicate

the original attribute values stored with each original network version file if the object is partof the original network version; otherwise, 0 or blank is output.

• The Diff. subattribute value serves to output the difference and has the following values.• For numerical attributes, the difference is calculated from Net1 and Net2 data• For strings, "==" is output in case of identical strings, whereas "<>" indicates deviating

strings. Blanks are output for objects which are not part of both original networkversions.

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

Illustration 8: Merge network of network 1 and network 2

Note: In case of user-defined attributes with identical IDs but different min/max value ranges,the value range of Net1 will be used. For objects with coordinates, the coordination values aretaken 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

14 © PTV AG


In the network view of the merge network, you can see that the link at the bottom left of network2 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 intervalsIn 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 intervalproperties, no intervals will be created in the merge network. The conformity of the analysisperiods and horizons is not checked. Attribute values which refer to different analysis periodsor 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 dataand OD demand data. A model transfer file created that way can be applied again to a suitableversion file in order to add the modifications. With this function it becomes easier to managethe different scenarios.The model transfer files constitute the basis for scenario management, which will be availablein VISUM 12.When creating the model transfer file, you can specify which data you want to save and whichnot. However, as when saving a network normally, you have to take care that the selectionmade makes sense.Example: You would like to adjust the timetable of one network to that of another one. The PrTattributes of the networks are different, which is to remain unchanged. In this case, whencreating the model transfer file, you only select the network objects with regard to thetimetables.

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

15 © PTV AG


16 © PTV AG

2 Network model

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

Subjects• Network objects• Spatial and temporal correlations in VISUM• Attributes• Subnetwork generator• The surface data model in VISUM

2.1 Network objectsThe network model differentiates basic network objects such as nodes and links, whichillustrate a network structure (see "Basic network objects of a transport network" on page 17).Additionally, there are network objects which are only used for modeling PuT networks (see"PuT network objects of a transport network" on page 19) and general networks, which do nothave to have any relevance to traffic and especially no influences on procedure calculations(see "General network objects" on page 21).

Network object Description

Transport system (TSys)

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

Mode In PrT a mode comprises exactly one transport system. In PuT, however, a mode can comprise several transport systems. This is how you can define a mode PuT for example, which comprises the PuT transport systems tram, bus and train.

Demand segment (DSeg)

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

Node

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

Table 2: Basic network objects of a transport network

17 © PTV AG

Chapter 2:Network model

Turn

Turns specify which movements are permitted at a node, that is, whether turning at a node from one link to another link is permitted.For PrT transport systems, turning time penalties and capacities can be specified which describe the influence of the intersection on the performance of the network. Turning prohibitions are taken into consideration as follows:• For public transport systems in the construction of a line route• For private transport systems in a route search

Turn standard Turn standards are patterns, from which an emerging turn with standard values is allocated for their attributes Time penalty and Capacity PrT. Which turn standard is used for the allocation of turn attributes, depends on the node type, the turn type and the flow hierarchy.

Link

Links connect nodes and thus describe the structure of the road and rail network. A link has a particular direction, so that the opposite link represents a separate network object and can thus have different attribute values.

Link type Link types are used as a template when inserting new links. When inserting a link, a link type has to be specified. The link then takes over the attribute permissible transport systems (TSysSet), Capacity PrT, velocities (v0-PrT, vMin-PrT, vMax-PrT and vDef-PrT), Number of lanes and the link rank as standard values.

Zone

Zones (traffic cells) describe the position of utilities in the network (for example, residential areas, commercial areas, shopping centers, schools). They are origin and destination of trips within the transport network, which means zones and the transport network are connected through connectors.

Connector

Connectors connect zones to the link network. They represent the distance to be covered between a zone’s center of gravity and the connector nodes. For public transport demand, the zone has to be connected via a stop area with stop(s) allocated to a node.

Main node

Several nodes can be aggregated to one main node. Each node is only allowed to be part of a main node. Using main nodes is useful, if the VISUM network is strongly aggregated and lanes are available as individual links for example and intersections therefore consist of several nodes (this situation can occur when working with navigation networks in VISUM).

Main turn

Main turns are created when using main nodes. Each movement via the main node is represented by a main turn. Main turns possess the same attributes as turns. In the assignment, the main turn replaces the node turn, which has the effect that only one turn penalty flows into the assignment for each main turn.

Main zone

Main zones group multiple zones and allow aggregated evaluations. A main zone can represent a county for example, which has multiple communities as traffic cells.

Territory

Territories are network objects, which can be used for example, to illustrate districts or counties. Based on a polygon which defines the territorial border, PrT and PuT indicators can be precisely accounted for each zone (for example the driven service kilometers within a zone).



18 © PTV AG

Chapter 2.1:Network objects

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

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

Valid day A valid day is a freely defined set of days within the used calendar. If a weekly calendar is used, a valid day can comprise the days Monday to Sunday (for example "Monday to Friday"). If an annual calendar is used, any individual days can be selected within the validity period. If no calendar is used, there is only the valid day "daily". It is then not possible to create new valid days.In PuT: a valid day can be assigned to each vehicle journey section.In PrT: the transport supply can be time-varying for the dynamic stochastic assignment, DUE and the assignment procedure Metropolis. Time-varying attributes are used (see "Time-varying attributes" on page 90). When using a calendar, valid days can be specified for these time-varying attributes, on which they should have an affect.


Stop

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

Stop area

A stop area divides a stop into areas. It can, for example, represent a train station platform, intersections with multiple stop points or a station concourse. A stop area has the following properties:• It is assigned exactly one stop.• It can comprise multiple stop points.• It can be assigned a network node. This allows a PuT connection of a zone

to the road network.• The stop areas are connected with each other with a transfer walk matrix

(walk times between the stop areas). It contains the transfer walk time of each PuTWalk for example.

Stop point

A stop point is the location, where PuT lines stop for passenger boarding. A stop point can either lie on a node or on a link (link stop point).• A stop point at a node can be served by all lines which pass the node.• A stop point on a link can only be served by lines which pass this link. A

detailed direction modeling based on masts is optionally possible with link stop points. Alternatively, undirected stop points can also be inserted on links.

Table 3: PuT network objects of a transport network



19 © PTV AG


Line

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

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

Time profile Time profiles describe the length of travel times between stop points of a line route and if boarding or alighting is allowed at the stop points of the line route. Because it is possible to create multiple time profiles per line route, you can model so that the travel times of a tram between stop points are longer during evening rush hours than the rest of the day. The allocation of the time profile is carried out on trip level, so that you can assign a different time profile to each trip.

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

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

Main line Main lines are used to aggregate several lines and evaluations (such as for PuT operating indicators) on this aggregation level. Aggregation can also be carried out via lines with different transport systems.

System route

A system route describes the in-vehicle time and the spatial course between two stop points. Compared to the line route, it is independent of the affiliation to a line or even a concrete trip. System routes with their path and in-vehicle-time information are used as a template for the efficient digitalization of line routes and for setting in-vehicle-times in the time profile. System routes are optional network objects, therefore not mandatory when creating a PuT model.

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

Vehicle combination You can optionally assign each service trip section a vehicle combination. You can assign a vehicle combination, time and distance dependent cost rates for service trips and empty trips, and cost rates for the layover in the depot and the stand time. These cost rates are applied within the operator model (see "Operator model PuT" on page 489).



20 © PTV AG


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

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

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

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

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

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


Point of Interest (POI) and POI category

Points of Interest are user-defined network objects with spatial reference, for example parking facilities, pre-emption points for AVL systems or SCJ controllers. POIs are used to display special land uses such as restaurants or hotels, for data management as well as for reachability analyses.

Count location

A count location is an independent network object allocated to a link by direction. Count locations serve for data management and display of counted link data.

Table 4: General network objects



21 © PTV AG


Network processing modifies the properties of the transport network which produces differentindicator values and assignment results.• In the case of modifications to the network structure, a current assignment result is

initialized. Inserting, deleting or renumbering a network object as well as merging nodes,splitting zones or links and aggregating zones represent modifications to the networkstructure. 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 alink, the current assignment result will not be initialized, although another assignment mightproduce a different result.

2.1.1 Transport systems, modes and demand segmentsThe transport supply consists of several transport systems. Modes and demand segments areused to link the transport supply with the transportation demand.

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

Detector

Detectors are optional network objects provided with the count locations add-on, they can be used for lane-based data management of counted link data.

Toll system

Toll systems are optional network objects which can be used to integrate toll zones into the network model. For the TRIBUT procedure, they are the basis for the calculation of road tolls.

GIS object

GIS objects (GIS = geographic information system) extend the network model by special layers which are directly incorporated from GIS ArcGIS and can be linked with the VISUM network data, via blending features. The objects are only available during the connection with a Personal Geo Database (PGD).

Screenline

Screenlines are a useful construction to calibrate an assignment model by means of counted link data. The course of screenlines often follows natural realities, for example rivers or railway tracks.


Table 4: General network objects

Priv.TSys1(e.g. HGV)

Priv.TSys2(e.g. Car)

Publ.TSys1(e.g. Bus)

Publ.TSys2(e.g. Tram)

Transport systems

Modes

HGV Publ.TranspStudents

Car Publ.Transport(Bus+Tram)

Car-private

Car-business

HGV Park&Ride(Car, Bus, Tram)

Publ.Transp.Adults

P&R

Matrix Matrix Matrix Matrix Matrix Matrix

Demand segments

Demand matrices

22 © PTV AG


2.1.1.1 Transport systemsThe transport supply consists of several transport systems. Links, turns and connections canbe attributed subject to the transport system ("transport system-based"). It can be specificallydetermined, if a transport system is allowed to traverse one of these network objects or not. Forexample, links can only be opened for the transport system Car, but not for the transportsystem HGV. Furthermore, the impedance functions (see "Impedance and VD functions" onpage 200) are defined for the assignment transport system dependent. A transport system has the following properties:• Transport system type (available are PrT, PuT, PuTWalk or PuTAux)• Means of transport (= vehicle type), for example car, tram, taxi, wheelchair

The four types of transport systems are different in the following ways.• PrT

Travel times of a private transport system depend on the following attributes:• Maximum speed of the means of transport for example 100 km/h for HGV• Permissible speed of the traversed link for example 80 km/h• Capacity of the traversed link

• PuTRun times of vehicles of a public transport system and the dwell times at stops aredetermined by the timetable.

• PuTWalkThis mode serves to model entrance and exit paths for public transport and walking transferlinks between stop points of a stop or several stops. In order to calculate a public transportassignment, at least one transport system of type PuTWalk must exist. Several transportsystems of type PuTWalk can be defined.

• PuTAuxThis type describes subordinate PuT transport systems without specification of a timetable.It is suitable for the following use cases.• Modeling lower-ranking public transport (supply systems):

In large networks, for example in train networks, one often does not want to enter thereachability of long-distance stations by means of a connector, but in instead one wantsto roughly display the available public transport supply. For a simple representationsuch as this, it is meaningful to define one or several additional public transportsystems. In this case, the successive public transport supply is only described as a linknetwork 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 reachedon 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 thesealternatives for connectors, it is possible to disable possible transport systems of typePuTWalk or to define different connector times. Two modes can then be defined for thePuT assignment: one mode that is only used if the stop is reached on foot and onemode that can be used if the stop is reached by car or bicycle.

Note: The number of modeled transport systems, modes or demand segments is not limited.

23 © PTV AG


Table 5The following table provides an overview of the transport system types’ properties:

2.1.1.2 ModesA 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 carYou can define multiple PuT modes. This way it is possible to model that for example long-distance passengers (Mode PuT-Long) may use all public transport systems (e.g. Intercity,Regional train, Bus) whereas, for example, commuters (Mode PuT-Local) may use onlyparticular transport systems (Regional train, Bus).

2.1.1.3 Demand segmentsA demand segment belongs to exactly one mode. It is the link between transport supply andtransport demand. As several demand segments can be defined for each mode, different typesof demand can be combined in the transport model.Demand segments can be used for differentiation among

Note: Transport systems of type PuTAux are only taken into consideration for thetransport system-based and timetable-based assignment. In headway-basedassignment, however, they are not considered.

TSys type Description Example

PrT • Transport system for private transport• Capacity-dependent travel times resulting from link speed and

turn times

Car, HGV

PuT • PuT with timetable• Run times from timetable• Transport system is not valid for transfer walks or on a connector

Bus,Tram,Train

PuTAux • Public transport system without timetable or PrT access system to PuT

• Run times result from links• Transport system is not valid for transfer paths within a stop - just

between stops

Bus,Taxi,P&R access

PuTWalk • Transport system for• access/egress paths from/to stops or• transfer paths within a stop or between stops

• Travel times from links or from a transfer walk time matrix of the stop

Footpath,Escalator,Lift

Table 5: PrT transport systems properties

24 © PTV AG


• Population groupsEmployed PrT (car drivers), Employed PuT, Students PuT, etc.

• Ticket typesSingle trip ticket, monthly pass, etc.

• Trip purposesto work, shopping, home

• Vehicle typesCar - diesel, Car - petrol, etc.

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

in car units (CarUnits)• PuT

in passenger unitsFor calculation of OD trips (PrT) from car units, the occupancy rate can be specified for eachdemand segment (see User Manual, Chpt. 2.10.3.2, page 180).

Assignment of demand segmentsIn case of all private transport assignment procedures (see "User Model PrT" on page 195),demand segments of different modes can be assigned simultaneously.• Tribut procedure, Stochastic or Dynamic stochastic assignment

Per iteration step, a route search is carried out for each transport system, because eachtransport system has a transport system-specific impedance function.

• Incremental and Equilibrium assignment, Equilibrium_Lohse assignmentThe search for each demand segment is carried out individually, using the same TSys-specific impedance function. This means, that volumes can be issued by DSeg. Adding thedemand matrices prior to the assignment saves calculating time.

• DUEDue to the parameterization by demand segment, the route search is always carried out byTSys.

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

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

25 © PTV AG


2.1.2.1 NodesNodes determine the locations of street junctions and points in the rail network. They arestarting and terminating elements of links, where there are turning relations from one link toanother in PrT or PuT turns (see "Turns" on page 26). Optionally, a major flow can be definedfor every node specifying the direction of the flow with the right of way. The major flow whichhas the right of way can be determined automatically by VISUM from the ranks of theintersecting links (see "Links" on page 28). Any number of nodes can be incorporated in a mainnode (see "Main nodes" on page 36). Impedances can be modeled for nodes, which then havean effect on the route search and thus on the assignment results (see "Impedances at node"on page 210). This is how influential factors on time can be integrated in the assignments,which a vehicle needs to cross an intersection.

2.1.2.2 TurnsTurns indicate whether turning is permitted at a node and what time penalty has to beconsidered 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 PrTtransport systems during assignment.

• For public transport systems turning prohibitions are considered during the construction ofa line route and during transport system-based PuT assignment.

When inserting a link, VISUM creates all theoretically possible turns at both nodes of the linkand 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 straightahead, 4 left turns and 4 U-turns).Each turn is described by the following elements:• A list of permissible/blocked transport systems• PrT capacity• PrT time penaltyThe transport systems have to be specified for each turn which uses this turn. A turndifferentiates permitted and blocked transport systems.

By default, the following applies when inserting a new link:• U-turns are blocked for all transport systems at the beginning.• Other turns are open for all transport systems at first which are allowed to use the To Link.

Permitted PuT transport systems

The turn can be used when constructing the line route.

Permitted PrT transport systems

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

Blocked transport systems

Prohibited turns

26 © PTV AG


2.1.2.3 Turn typesVISUM distinguishes 10 turn types (0 to 9), of which types 0 to 4 are predefined.0: Not specified1: Right turn2: Straight on3: Left turn4: U-turn5..9: Free for user-defined casesThe turn type can be calculated automatically from the geometry of the turn.

2.1.2.4 Turn standardsTurn standards are patterns, which assign a newly created turn with values for their attributesTurn time penalty (t0-PrT) and Capacity. Which turn standard is used to assign attributes ofeach 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 nodeFor each node, VISUM evaluates the rank of the links involved and thus determines a majorflow (see "Link types" on page 29). This automatically determined major flow can be editedmanually. The flow hierarchy describes whether a turn follows this major flow, from this oneinto a minor flow, from one minor flow into the major flow or leads from minor flow to minor flow.These four steps of the flow hierarchy are designated with the symbols from Table 6.

In combination with node types, turn types and flow hierarchy, you can assign the turns verydifferentiated turn times as standard. These turn times can then be considered within theassignment (see "Impedances at node" on page 210). illustration 10 shows an example of turnstandards.

Symbol Right of way

++ from major flow into major flow

+- from major flow into minor flow

-+ from minor flow into major flow

-- from minor flow into minor flow

Table 6: Flow hierarchy symbols

27 © PTV AG


Illustration 10: Example of a TURNSTANDARD table in the network file which is used to specify standard values for turn penalties and turn capacity

2.1.2.5 PrT capacity and PrT turn timeTurns show basically the same correlation between capacity and travel time as links. The onlydifference results from the fact that a turn does not have a length and that the travel time t0therefore comes from the turn time penalty.The turn time tCur in the loaded network then results from the selected VD function and therelationship 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

(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 setmethod for impedances at nodes (see "Impedances at node" on page 210).

2.1.3 LinksLinks describe roads and railway tracks of the transport network. The link nodes, this meansjunctions in PrT or stop points in PuT. A link is represented as a directed element and isdescribed by the From Node number and To Node number. Both directions of a link are twoindependent objects in the network model, who are assigned the same link number and whoseFrom Node number and To Node number has been swapped. This means, that you canattribute both directions of a link differently. For every link, you must specify the permissibletransport systems of PrT and PuT (which are allowed to use the link). This means, that you canblock one of the directions for traffic and therefore model a one-way road.

* Attention: time always in seconds* Table: Turn standards$TURNSTANDARD:ID;NODETYPE;TURNTYPE;FLOWHIERARCHY;T0PRT;CAPPRT1;10;1;--;10s;320002;10;1;-+;10s;32000 // Right turn from minor flow into major flow3;10;1;+-;10s;32000 // Right turn from major flow into minor flow4;10;1;++;0s;32000 // Road with right of way which bends to the right5;10;2;--;15s;32000 // Crossing from minor flow into minor flow6;10;2;-+;10s;320007;10;2;+-;10s;320008;10;2;++;0s;32000 // Crossing straight from major into major flow9;10;3;--;20s;3200010;10;3;-+;20s;32000 // Left turn from minor flow into major flow11;10;3;+-;15s;32000 // Left turn from major flow into minor flow12;10;3;++;0s;32000

tcur t0 1 a qqmax c⋅------------------⎝ ⎠

⎛ ⎞ b⋅+⎝ ⎠

⎛ ⎞⋅=

28 © PTV AG


2.1.3.1 Link typesVISUM describes the traffic-related properties of links with link attributes. It also offers thepossibility of dividing links with the same properties into 100 link types, which themselves haveattributes. Each link belongs to a link type via its attribute Type number. The 00 to 99 link typesserve as network classifiers and make it possible to assign type-specific standard values forthe following link attributes.• List of permissible transport systems on a link• Capacity PrT• Permissible PrT-speed (v0-PrT) free flow speed• Minimum speed• Number of lanes• Rank of identification of the link rating• Permissible maximum speed, vMax-TSys, of every PrT transport system• Transport system-specific road speed in PrT for toll• Transport system-specific road speed t-PuTSys, for the calculation of transport system-

specific PuT run times 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 585)the operator modelIn principle, the values of the attribute of a link of the assigned link type, is independent. Thismeans, that you can attribute each link independent of the link type. However, it isrecommended to apply exactly those values of the link type in the link. This is how you willachieve as consistent as possible modeling of links and modifications to attributes can bemade more easily, because you can change these in the link type and then apply these to thelinks (see User Manual, Chpt. 2.13.2, page 212).For the assignment, each link type can be assigned a capacity restraint function, which thusapplies for all links of this link type (see "Impedance and VD functions" on page 200). This ishow you can achieve, that a different mathematical coherence between the in-vehicle time forpassing a link and the traffic volume is applied on grade-separated urban roads than on at-grade non-urban roads.

Major flowsFrom the rank of the link types of the link which flow into a node, VISUM determines a flowhierarchy with a major flow. This always refers to two different link orientations (see "Networkobjects of the Junction model" on page 66). The major flow is taken from one of the threecriteria (see "Turn standards" on page 27) to determine the time penalties, for the exitingturning processes from the major flow or from another link. If possible, it should correspond tothe right of way or movement, advantaged through the SC. Due to this cohesion, the rank ofthe link type has a direct influence on the PrT assignment result. illustration 11 shows anexample of the determination of flow hierarchy and especially the major flow.

29 © PTV AG


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

2.1.3.2 Permissible transport systemsThe permissible transport systems specify the configuration of a link. The following types can,for example, occur:• a simple road which can be used by PrT-vehicles and street-bound PuT• a rail track which can only be used by trains (trains, subways)• a road with tramlines• a one-way road which can only be traversed in one direction• a transfer walk link between PuT-stopsillustration 12 shows three examples for permissible transport systems on different types oflinks.

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

30 © PTV AG


Illustration 12: Examples for defining transport systems of a link

The number of the lanes of a link is entered as an attribute, but also has to be considered forthe capacity (this means that the entered capacity does not refer to one lane, but to all lanes).A link is always meant for both directions. In order to define a one-way road, you block thetransport systems for the opposite direction.• Links which are permissible to PrT transport systems are taken into account during

private transport assignment.• Links which are permissible to PuT transport systems are taken into account during the

construction of line routes for public transport. PuT assignments (headway-based ortimetable-based procedures) are not based on link data, but on PuT line timetables.

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

2.1.3.3 PrT capacity, PrT speed and PrT travel timeIf there is free traffic flow in an unloaded network, the travel time, t0 of a link can be determinedfrom 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 / v0The free flow speed v0-TSys of vehicles of a particular transport system can be lower than thefree flow speed v0 of a link, because special speed limits might apply to these vehicles orbecause the vehicles cannot drive faster. The maximum speed of a PrT transport system,vMax-TSys, is an attribute of the link type. For speed v0-TSys and travel time t0-TSys therefore applies:• v0-TSys = MIN (v0, vMax-TSys)• t0-TSys = L • 3.6 / v0-TSysIn a loaded network, travel time of a link is determined through a so-called volume-delayfunction (also known as capacity restraint function) which describes the correlation between

Road with tram lines One-way road without tram lines Transfer walk link

⌧ Car⌧ HGV⌧ Bus⌧ Tram

PuT-Walk


PuT-Walk


PuT-Walk


PuT-Walk

⌧ Car⌧ HGV⌧ Bus

TramPuT-Walk

⌧ Car⌧ HGV⌧ Bus

TramPuT-Walk

CarHGVBusTram

PuT-Walk

CarHGVBusTram

PuT-Walk

CarHGVBusTram

⌧ PuT-Walk

CarHGVBusTram

⌧ PuT-Walk

CarHGVBusTram

⌧ PuT-Walk

CarHGVBusTram

⌧ PuT-Walk

31 © PTV AG


the current traffic volume q and the capacity qMax. The result of the VD function is the traveltime in the loaded network tCur.• Input: Free flow travel time t0[s]• Input: Traffic volume q [car units/time interval]• Input: Capacity qMax [car units/time interval]• Input: VD function, for example BPR-function from U.S. Bureau of Public Roads• Result: Current in-vehicle time in the loaded network, for example

(dependent on VD function type)

• Result: Current travel time of a transport system = MAX (tCur, t0-TSys)illustration 13 illustrates how speeds vCur of two PrT transport systems develop depending onthe volume.

Illustration 13: Example for the different speeds of two PrT transport systems depending on the volume

2.1.3.4 PuT run timeWith every link, a PuT run time is stored for each PuT transport system. When a link is inserted,this run time is calculated automatically from the link length and the link type-specific speed ofthe transport system. During the construction of a system or line route, a suggested run timebetween stop points is then calculated from the PuT run time of the link. This in-vehicle time isin the respective time profile (see "Specifications of lengths and times" on page 51).

2.1.4 ZonesZones (also traffic cells) are starting point and destination of trips. This means that each tripstarts and ends in a zone. Zones link the transport supply (network model with nodes, links,PuT lines, etc.) to the transportation demand (in form of demand matrices (see "Matrices" onpage 104), which contain the traffic flows between all OD pairs of the model.

Link type Motorway• vMax (car) = 150 km/h• vMax (HGV) = 100 km/h

Linkv0 = 130 km/h

Free traffic flow• tCur (car) = 130 km/h• vCur (HGV) = 100 km/h

partially linked traffic flow• vCur (car) = 110 km/h• vCur (HGV) = 100 km/h

linked traffic flow• vCur (car) = 80 km/h• vCur (HGV) = 80 km/h

tcur t0 1 a qqmax c⋅------------------⎝ ⎠

⎛ ⎞ b⋅+⎝ ⎠

⎛ ⎞⋅=

130 100

Car HGV

32 © PTV AG


Every zone can be assigned a zone boundary which represents the spatial extension of thezone. In the network model, zones are reduced to a zone centroid. Here the trips of a demandmatrix are fed into the network. Every zone must be connected via a connector (see "OD pairs"on page 33) to at least one node. The optional zone polygon has no influence on thecalculation results in the assignment; however, typical GIS functions such as intersecting canbe realized with the zone polygon (see "Intersect" on page 638). Multiple zones can also becombined to a main zone for evaluation purposes.The zone size can vary depending on the level of detail of the model. Zones generally describethe 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 numberof school places are stored here, which are used for calculating the traffic demand as inputdata (see "Demand modeling procedure" on page 109).illustration 14 shows an example of the transport demand between the zones and how they areavailable in the demand matrix.

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

2.1.5 OD pairsOD pairs (or relations) exist between all zones of the network. The values in skim matrices anddemand matrices (see "Matrices" on page 104) each refer to one relation. Compared to theother network objects, you cannot edit relations interactively in the network editor, but you canfilter relations and display them graphically. For each relation you can select the skim matrixvalues, demand matrix values and the direct distance as attributes. Table 7 shows a demandmatrix value for Matrix 1 X and the skim matrix values for the skim of mean travel time for allOD pairs in the example Example.ver.

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

From zone To zone Demand matrix value (1 X)

Skim matrix value (JRT)

100 100 0.00 0.00

100 200 2,000.00 38.00

Table 7: OD pairs in the example Example.ver

33 © PTV AG


2.1.6 ConnectorsConnectors connect zones to the link network. Each zone has to be connected to at least oneorigin zone and one destination connector to the network for the assignment, so that the roadusers can exit and enter this zone. A zone can be connected to the network with any numberof connector nodes.A connector corresponds to an access or egress route between the zone centroid and theconnecting node. A connector has therefore two directions.• Origin connector from zone to node

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

Illustrates the egress route from the network and therefore the last part of the change oflocation.

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

100 201 200.00 12.00

100 202 0.00 32.00

200 100 2,000.00 38.00

200 200 0.00 0.00

200 201 5,000.00 16.00

200 202 2,000.00 13.00

201 100 200.00 12.00

201 200 5,000.00 16.00

201 201 0.00 0.00

201 202 0.00 20.00

202 100 0.00 32.00

202 200 2,000.00 13.00

202 201 0.00 20.00

202 202 0.00 0.00

From zone To zone Demand matrix value (1 X)

Skim matrix value (JRT)

Table 7: OD pairs in the example Example.ver

34 © PTV AG


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

For each direction, the permitted transport systems, meaning those transport systems whichare permitted to use this connector, can be determined. In PrT, connections can be opened forall PrT transport systems. In PuT, however, a path always starts and ends with a route traveledby PuT pedestrian transit system on the connection. It is therefore assumed, that the accessand egress of the stop is always by foot. For connectors in PuT there are basically twopossibilities 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 theaccess nodes of the next stop area and from there to the stop point, from which a trip isused (this approach is not recommended).

• Only nodes which are also access nodes of a stop area are connected. In this case, eachpath starts and ends with a walk link on the connector and within the stop continues to thestart 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 whicheach transport system requires to pass the connector. The standard value for t0 per transportsystem is calculated from the connector length (standard value is the direct distance) and theconnector speed which also exists as a standard value (see User Manual, Chpt. 2.17.1,page 262). The standard value for the connector speed can be assigned separately for PuTand PrT connections. t0 can be overwritten manually by the user.

2.1.6.1 Distribution of demand of a zone to the connectorsFor modeling connectors in PuT and PrT, there are different possibilities of influencing thedistribution of a zone demand to the connectors (see "Distribution of the traffic demand to PrTconnectors" on page 272 and "Distribution of the travel demand to PuT connectors" onpage 426). illustration 16 provides an overview of these possibilities and describes eacheffect.

35 © PTV AG


Illustration 16: Possibilities for modeling connectors

2.1.7 Main nodes and main turnsAny number of nodes can be incorporated in a main node. Main nodes can be used, if theVISUM network is strongly aggregated.Main turns are constituent parts of main nodes. They are created automatically when a mainnode is defined.

2.1.7.1 Main nodesFor the illustration of roads and other transport-related areas, which are more or less structuredby central reservation or traffic islands, there are several possibilities of displaying these in atransport model. For relatively strong abstraction, the correlation of components with regard tocontent, for example lanes of both directions on a road are illustrated by an individual link. Thisis the best view for traffic engineering analyses. With the increasing application of navigationnetworks 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 lanedirections as two separated links in the VISUM model. However, combining these in anaggregated illustration would create a lot of work as well as a loss of information, because theexisting refined distribution is required when carrying out microsimulations with themicrosimulation program VISSIM.For conventional modeling, there is a contradiction between the activated demand fordisaggregated network display and that of differentiated turn delays per turn type. We want tomake it clear using an example.

Connectors

PrT PuT

Free distribution (Option: absolute)

- Connector is not limited by capacity.

- Im pedance for assignment regards the constant travel tim e t0 of the connector ( tC ur is not regarded).

Proportional distribution

(Option: by shares)

Total trips Each single OD pair (MPA)

- Assignment regards connectors just as links.

- The capacity of a connector results from the demand share that is distributed to this connector.

- In order that the connector is loaded dur ing assignment, t0 needs to exceed alternative paths in the network.

- During the internal calculation a new zone is created for each relevant PrT connector (D Segs with at least a single TSys that may use the connector).

- Upon these zones, the demand falls that results from the connector weights PrT.

- Since each zone has only a single connector, neither t0 nor tCur is regarded for shortest path search dur ing as signment.

- The demand of a zone is distributed to PrT connectors according to the connector weights PrT.

Free distribution(Option: absolute)

- Connector is not lim ited by capaci ty.

- Impedance for ass ignment regards the constant run time t0 of the connector.

Proportional distribution

(Option: by shares)

Each single OD pair (MPA)

- The demand of a zone is distr ibuted to PuT connectors according to the connector weights PuT .

- During the internal calculation a new zone is created for each relevant PuT connector (DSegs with at least a single TSys that may use the connector).

- Upon these zones, the demand falls that resul ts from the connector w eights PuT.

36 © PTV AG


Illustration 17: Intersection area with multiple nodes

If two roads intersect as in illustration 17 with separated lanes, the intersection area splits upinto four nodes. If a triangle island is also present, the turns with the respective node are alsoadded. A road user who comes from the bottom of the image and turns left, successivelypasses nodes 1 to 5. Only at node 3 does the user follow a turn which represents a left turn andcrosses all other nodes straight ahead. Right turns only touch two nodes, at both nodes theytraverse a right turn, whereas paths leading straight ahead cross four paths. If turn penaltieswere 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, toindividually set the turn times of each movement, so that the sum of all traversing turns resultsin the desired value for the movement. This, however, is not possible with a type-basedallocation of values, because turns of the same type would have to be attributed differently atthe 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 thenodes belonging to an intersection area explicitly in a separate object. All nodes of theintersection area thus form a logic unit, which takes the place of the previous nodes. Turns areregarded 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 ofthe main node. If just one of the nodes belongs to the main node, the link is called a cordonlink. These constitute the access and the egress of the main node: each movement enters themain node via a cordon link and exits it via a different one. A link is also a cordon link, if bothnodes are allocated to different main nodes.

The combination of several nodes in a main node defines, based on the nodes of the mainnodes, different kinds of links:

• Inner links: From node and To node belong to the main node (illustration 18: (1))• Cordon links: one of the two nodes belongs to the main node, the other one lies

outside of it (illustration 18: 2))• Directed links or one-way streets: this is a link with at least one direction with an

empty TSys set or zero lanes.There is also cohesion between main nodes and different node types:

• Inner nodes: only inner links originate here (illustration 18: (3)• Cordon nodes: at least one cordon link originates here, additionally possibly inner links

(illustration 18: (4))• Partial nodes: any nodes that are allocated to a main node. These could be inner

nodes, cordon nodes, and nodes lying beyond the boundary of the main node.

37 © PTV AG


Illustration 18: Node and link types of main nodes

2.1.7.2 Main turnsMain turns are constituent parts of main nodes. They are created automatically when defininga main node and can be edited manually.Main turns possess the same attributes as turns. They are automatically inserted or deletedwhen editing cordon links, i.e. when inserting or deleting cordon links and when editing theallocations 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 thetransfer from one cordon link to another. If the main node consists of a single node only, themain turn corresponds to exactly the turn between the links concerned. It is thus ageneralization of the usual turns at a node on the level of the main node.If we reconsider the intersection area in illustration 17, assuming that all displayed nodes wereincorporated in a main node, seven cordon links exist. Since a main turn leads from eachcordon link to each cordon link, there are 49 main turns at this main node. However, it does notmake sense to traverse some of them, as they enter one-way roads in opposite directions (see"Main turns not open to traffic" on page 39). Exactly the 16 (or 12, in case of closed U-turns)convenient movements via the main node remain the main turns that are open to traffic (see"Main turns open to traffic" on page 39).

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

1

2

3

4

38 © PTV AG


Illustration 19: Main turns open to traffic

Illustration 20: Main turns not open to traffic

Within the main node, the main turn takes the place of the network, meaning that the trafficengineering characteristics, which take effect when crossing the main node, are describedexclusively by the attributes of the main turn and the main node. A path that crosses the mainnode only uses the main turn between the incoming and the outgoing cordon link. Neither theattributes of the (inner) links, nodes and turns in between are evaluated, nor will these networkobjects be loaded during assignment.

2.1.8 Main zones and main OD pairsAny 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 (demandmatrices 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 zonematrices, as for zone matrices. As an option, main zone boundaries (polygons) can be defined.

Use cases for the application of main zones arise in the following situations: • Multiple zones can be aggregated to larger study areas in very detailed modeled networks.

This often also makes the graphical display in the network editor clearer.• Display of flow bundles on main zone level

Note: Main zone boundaries are managed (see "The surface data model in VISUM" onpage 96) like surfaces and can be made up of multi-face polygons or polygons with "holes".

39 © PTV AG


• Display of desire linesIf you connect multiple zones to one main zone, you can make the desire lines clearer.

• Executing diverse procedures on main zone level

2.1.9 TerritoriesLocal authorities such as counties or districts can be displayed as territories, for example. PrTand PuT attributes can be calculated precisely by inserting territories and applying theoperations territorial indicators (see User Manual, Chpt. 4.4.3, page 844) and PuT operatingindicators (see User Manual, Chpt. 7.3.1, page 1075). This means, that the indicator share iscalculated which applies to a territory. Use cases occur especially when calculating PuToperating indicators.

2.1.10 PathsAll assignments in VISUM in PrT as well as in PuT are path based, meaning that possible pathsin the assignment are calculated for each origin-destination relation and loaded with a demandshare. All other results, especially the volumes of the different network objects and the skimmatrices are derived from these loaded paths. Paths are therefore the central result of theassignment procedure.In VISUM the definitions path (PrT path and PuT path), PuT path leg and PrT path on link levelare used. PuT paths are thus described with a sequence of PuT path legs. Link-based PrTpaths display all links which lie on a PrT path.On the basis of assignment results, using paths you can execute detailed evaluations, such asflow bundles (see "Flow bundles" on page 655), or verify the assignment results.As an optionVISUM saves the assignment of paths found (see User Manual, Chpt. 5.1.2, page 849).

Editing paths in PrT (PrT path object)In PrT, the user can manually edit paths. New paths can be inserted and existing paths can bemodified. Both the course of PrT paths and their volume can be modified by the user (see UserManual, Chpt. 2.22.7, page 318). These paths are also available in the usual procedure (suchas 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 theprocedure convert paths. Furthermore, multiple so-called path sets can be maintained parallelin a network. Path sets thus combine multiple paths to a group. This is how you cansuccessively store and switch between these assignment results in the network, for example.The following use cases occur, editing paths manually:• Creating an own assignment result either by creating a network file in a text editor or

interactively by digitalizing paths.• Editing an assignment result, calculated by VISUM. This may occur interactively by

digitalizing the path course in the network editor or by editing the path volume in the pathlist. On the other hand, the paths can be written as network files and edited in a text editor.

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

Note: Zone boundaries are managed (see "The surface data model in VISUM" on page 96)like surfaces and can be made up of multi-face polygons or polygons with "holes".

40 © PTV AG


• Maintaining different assignment results in a network as path sets. Each path set thencontains the paths in an assignment.

• Maintaining different flow bundle results as path sets. Each path set then contains theresult (the paths) of one flow bundle calculation.

• Overwriting a selected section of the assignment result with external data. This is how onlypaths which start in this planned residential area can be edited manually and the rest of theassignment maintained in a transportation analysis.

• Distributing a matrix on paths. For a given matrix and given paths, the matrix values aredistributed to the paths. This enables them to replicate the trip distribution and quicklyupdate the manual assignment.

There are two procedures for handling PrT path objects, which can be integrated intocalculation processes (see User Manual, Chpt. 2.22, page 310):• Converting paths (see User Manual, Chpt. 2.22.12, page 323). The procedure can be used

for example, to replace one assignment result with another. There are the followingpossibilities:• Converting assignment result to path set• Converting path set to assignment result• Converting path set to path set• Converting assignment result to assignment result

• Distributing a matrix on paths (see User Manual, Chpt. 2.22.14, page 326). Based on thematrix and paths, the trips of a matrix are distributed on the paths. This enables them tochange the demand on the level of OD pairs and then distribute the new demand on allexisting paths of the relation, in proportion to the previous shares. Distribution is carried outwith the attribute ActualShareonPathSet. The attribute can be defined for each path bythe user. For each OD pair of a path set the attribute ActualShareonPathSet is first addedup (total weight) on all paths.

Where P is all paths in a path set of origin O to destination D. If for example, there are fivepaths from zone A to zone B, the ActualShareonPathSet of the five zones is added up.The volume of an individual path p then results from the following equation.

2.1.11 Stop hierarchy: Stops, stop areas, stop pointsIn 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 allowslarge stations to be illustrated in detail and also comprehend simpler situations, without havingto specify many entries. This illustration is shown in VISUM, by the so-called stop areahierarchy, which is composed of the network objects stop, stop area and stop point. Each ofthese three levels fulfills certain, clearly separated tasks within the transport network.

TotalWeight ShareOfPathSeti 1=

P∑=

p.Volume Matrix value p.ShareOfPathTargetTotal weight

--------------------------------------------------⋅=

41 © PTV AG


• Stop pointSpecified departure point for one or more lines. PuT lines stop here for passengerboarding. In the most detailed model, the stop point corresponds to a stop sign for busservices or the edge of a platform in the case of rail services.

• Stop areaCombines several stop points in close proximity and displays the access to the stop pointsin the remaining transport network via an access node.

• StopIs the object which comprises the entire complex of stop points and stop areas. It is thehighest object of the stop hierarchy and carries the name of the stop and others, for theentire construction applying attribute. In the real network, it is therefore of moreorganizational nature.

Illustration 21: The stop hierarchy

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

2

1H

H

Stop pointat link 1-2after 50 m

H H

Stop area

Stop

42 © PTV AG


The differentiation between stop points on nodes and links allows network models of differentlevels 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 areaand stop are generated automatically in the background, but generally remain hidden to theuser, if desired.

• For operational planning and AVM supply, it is useful to model the stop points on links sincethe required degree of detail can be achieved in this way.

It is also possible, of course, to mix both types in VISUM, for example by using the moreaccurate 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 routetrips, whose transport system is permitted, can stop there.

2.1.11.2 Stop areasA stop area divides a stop into areas. An area can for example represent a bus or train stationplatform, an intersection with stop points, a P&R car park, a station concourse, etc. A stop areais 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 areasof a stop. They combine stop points which do not differ from other stop points with respect totheir transfer walk times. If for example at a railway station the stop points of the individualplatforms are combined into a single stop area and the bus stops on the forecourt as well, thismakes it possible to include closely separated minimum transfer times from rail to rail, rail tobus, and bus to bus. The matrix of transfer walk times (From Stop Area – To Stop Area) canindicate which public transport walk system (for example, stairs, escalator, lift, ground-levelwalkway) is used. The transfer time for a demand segment is always the minimum timerequired for all permitted PuTWalk systems. User group-dependent transfer times, for example

Stop point on node Link stop points

Illustration 22: Possibilities of modeling stop points

Notes: We recommend to set the start or end point of a line route only at stop points whichare located on nodes, because inaccurate results might occur if a line route starts or ends atlink stop points, for example, when calculating PuT operational indicators or in case of PuTvolumes which are displayed on link level.Because trip stops always occur at a stop point, each stop has to have at least one stop point.

H H

HDirected

stop point on link

Undirected stop point on link

43 © PTV AG


for mobility-impaired persons, can be modeled by permitting selected PuTWalk systems (forexample, ground-level walkways and lifts) only for specific demand segments. Stop areas canalso represent intermediary levels in large station areas. In this case, while transfer times toother stop areas exist, the stop area itself does not contain stop points.

The second function of stop areas is to connect stops to zones and the walkway networkbeyond the stop. If required, a network node, which can be reached with the same transferwalk times as every other stop point of the area, can be assigned to each stop area. The timewithin the stop area (diagonal of the transition matrix) is not used for the transition to the accessnode. Via this network node, PuT paths can change from a public transport line to links withPuT walk or additional public transport systems as well as to connections to districts and viceversa.

2.1.11.3 StopsA stop comprises the entire complex of stop areas and thus also stop points. To ensure that astop can be localized and displayed in graphical form, it has a coordinate, but it is not assigneddirectly to a network node or link.The stop contains information on route times within each stop area (on the transfer walk timematrix diagonal) and between two stop areas. In addition to these walk times, as an option thestop also has transfer walk times and wait times between transport systems. With this aparticularly through structural or organizational measures aggrieved or favored transferbetween trips can be illustrated, for a modeled stop without stop areas, for example. Thegeneral transfer walk time of eight minutes could apply in a large train station, when changingfrom an ICE train to another train, however, because of track information, three minutes shouldbe sufficient, for example. In such a case, these three minutes could be defined as transfertime of the transport system ICE in the same transport system.

2.1.12 PuT operatorsProviders of PuT trips, for example local transport services or train operating companies, arecalled operators. The network object operator is the starting point for analyses of the publictransport supply from operator point of view. It is therefore used within the network for groupinglines and trips to jointly evaluate units. An application is for example, the fare/revenuedistribution to the different operators of a public transport system. This often occurs on thebasis of service kilometers or seat kilometers. If you have assigned operators to the trips inyour model, you can evaluate these and many other indicators (see "Operator model PuT" onpage 489).Operators can either be assigned to a whole line (one then talks about a standard operator) orindividual service trips.

Note: The transfer walk times (transfer walk times matrix) between the stop areas is definedat the stop.

Note: Please note, that changing the standard operator of a line subsequently, does notoverwrite the operators of existing service trips.

44 © PTV AG


2.1.13 PuT vehicles: vehicle units and vehicle combinationsPuT vehicles such as buses, trams or intercity trains are displayed in VISUM, through thenetwork objects vehicle units and vehicle combination. Using these network objects, it ispossible to change the composition of a service trip en route (see "Network objects of the linehierarchy" on page 46). This is how a train in the preceding and succeeding trip can run withfewer coaches than in the main leg. The second application case for PuT vehicles is in theoperator model section. Indicators such as service kilometers can be evaluated on the level ofvehicle combinations (see "Operator model PuT" on page 489).Each vehicle unit is assigned one or more transport systems. It can only be used for trips, linesor system routes, which belong to one of these transport systems. Furthermore, for eachvehicle it is specified whether it is a railcar or not. In addition to the seats and the total numberof seats, cost rates can be entered per distance and time unit, for service trips und empty tripsrespectively. These data are determined within the scope of the operator model forevaluations.Vehicle units are combined to vehicle combinations. A vehicle combination thus alwayscomprises one or more vehicle units. The same vehicle unit can appear repeatedly in thevehicle combination. This is how a vehicle combination intercity train can be composed of avehicle unit railcar and multiple vehicle units coaches, whereas for the railcar and the coachesdifferent cost rates or capacities can be specified.The set of permissible transport systems for a vehicle combination is determined as a mean ofthe permissible transport system sets of the respective vehicle units. If there is no transportsystem which can be combined for all respective vehicle units, these cannot be combined to avehicle combination.Path and time related cost rates can also be specified for each service and empty trips, forvehicle combinations. These take effect together with the cost rates of the respective vehicleunit. Use these entry possibilities therefore for such costs, which accumulate only once forvehicle combinations. Typically, maintenance costs per vehicle should be specified, personnelcosts however, per vehicle combination.Vehicle combinations can be assigned entire lines or time profiles (one then talks about astandard vehicle combination) or individual service trips. This enables very detailed modelingof changes in train formations or also strongly disaggregated evaluation of PuT operatorindicators, for example.

2.1.14 The line hierarchyThe modeling of the transport supply in PuT is hierarchical. This structure enables the user toreuse data specified once as efficiently as possible, for example the course of a line for severalvehicle journeys.

Note: Please note, that the successive modification of standard vehicle combinations of a lineor a vehicle profile, does not overwrite the vehicle combination of the existing service tripsections.

45 © PTV AG


2.1.14.1 Network objects of the line hierarchyillustration 23 shows the six network objects of the line hierarchy.

Illustration 23: The line hierarchy used to model the PuT supply

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

LinesA line structures the public transport supply. Within the VISUM data model, it is mainly used toaggregate several line routes. Each line has at least one line route or multiple line routes. Theline itself neither has a spatial course in the network (see "Line routes" on page 46), nor are runtimes specified between the stop points (see "Time profiles" on page 48). Each line belongs toexactly one transport system. You can optionally allocate a standard operator and a standardvehicle combination to a line. When creating new vehicle journeys, they will then be suggestedas standard values.

Line routesA line route is part of exactly one line and describes the spatial route course of the line forone 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 lineroute course are output between two consecutive route points. A route point can be a node ora stop point along the line route course. All stop points along the course at which the line routecan stop, are always route points. All nodes along the course can optionally be declared asroute 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 linecan incorporate any number of line routes (cf. for example illustration 24). Different line routes(pairs) of a line represent different route courses, which are organized in lines.

Vehicle journey itemVehicle journey

Time profileLine route

LineMain line

46 © PTV AG


Line routes can be generated either manually or based on existing system routes (see "Systemroutes" on page 58).

Illustration 24: Example for two line routes of a line

Link network Line route 1 Line route 2

MA

I

N

W

H

S

MA

I

N

W

H

S

MA

I

N

W

H

S

S important route point for line

other stop point or node

47 © PTV AG


Time profilesEach line route has one or more time profiles. A time profile describes the temporal sequenceof the line along the line route. However, specific departure times are not specified, but the runtimes between the individual route points.Analogous to the line route (route points), the time profile is described by a sequence of profilepoints. This sequence of profile points is called the course of the time profile. Any route pointsof the underlying line route can be profile points. However, the start stop point and the end stoppoint of the line route as well as all stop points, at which passengers can board or alight mustbe among them. It can also contain passage times for any route points of the line route, forexample 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 thesection between the previous and the current profile point. In case of stop points, a stop timecan 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 pointsor the run times on the different sections between the profile points (cf. for exampleillustration 25). If a vehicle journey of a line route shall stop at a stop point along the route yetanother one shall not stop, you need to define two time profiles for the same line route (yet notif 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, astandard vehicle combination can be allocated to the time profile. When inserting a new vehiclejourney, this is then applied automatically as a default value.

Fare points can still be specified at the time profile, for each profile point. These can enter thecalculation of revenues (see User Manual, Chpt. 7, page 1019). When modeling public transport, time profiles are important in the following use cases:• Couplings are set on time profile level (see User Manual, Chpt. 2.30.4.5, page 408).• Headways for the headway-based assignment are specified on time profile level (see User

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

Note: Please note that the vehicle combinations of existing vehicle journeys are notoverwritten. If a standard vehicle combination is specified for the line also, the standardvehicle combination of the time profile takes effect when inserting a new vehicle journey.

48 © PTV AG


Illustration 25: Example for two time profiles of a line route

Service trips (=vehicle journeys)A service trip describes a planned trip of public transport or a set of planned trips, which aresummarized to an administrative unit of a number. Everyday of the calendar used in thenetwork, 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 hasa reference to two stop points of the line route, which define the section on which the vehiclejourney follows the course of the line route. Vehicle journeys can therefore traverse any section

Line route 1 Time profile 1.1 Time profile 1.2

SPoint Stop Arr Dep. SPoint Stop Arr Dep.

M 0:00 M 0:00

i 1:00 1:02 i - -

N 2:00 2:02 N 1:50 1:52

H 3:00 3:02 H 2:50 2:52

U 5:00 5:02 U 4:50 5:02

O 6:00 O 6:00

MA

I

N

W

H

S

49 © PTV AG


of a line route. It is therefore not necessary to define a line route with a shorter extension forvehicle journeys, which only traverse a line route partially. Trips cannot, however, switch fromone line route to another. This means that each trip can only run on exactly one line route.Furthermore, the trip contains a departure time at the origin stop point from which, togetherwith the relative times of the time profile, all arrival, departure and transit times of the trip aredetermined.A vehicle journey can optionally be assigned an operator. You can then calculate aggregatedevaluations of PuT operating indicators on operator level (see "Operator model PuT" onpage 489).

Service trip sections (=vehicle journey sections)Usually there is exactly one vehicle journey section per vehicle journey. This is createdautomatically when inserting a vehicle journey. As an option, a vehicle journey can besubdivided into multiple vehicle journey sections, which can then be divided into the followingproperties.• Valid day• Vehicle combination• Start and end stop point• Pre and post preparation time for line blocking (see "Line blocking" on page 500)This results in the following application possibilities for example.• A vehicle journey, which traverses from A to C via B from Monday to Friday, on the

weekend however, only from A to B, can be illustrated by two vehicle journey sections,which only differ in their valid days.

• A train, running from A via B to C, between A and B however with less coaches, can bedisplayed by two vehicle journey sections, which differ in their vehicle combination and startand end stop points.

• Any combinations are possible, for example a train which running between A and B andwhich is only short on the weekend.

• Vehicle journey sections are network objects, with which line blocking is carried out (see"Line blocking" on page 500).

Table 8 shows an example with three vehicle journeys of a line route. The line route has twotime profiles. Trip 993 is divided into three vehicle journey sections, which differ in valid daysand vehicle combinations.[

Trip number from -> to Departure time Valid day Vehicle combination

991 N H 06:02 AM (daily) daily Loco + 6 coaches

992 M H 05:10 AM (daily) daily Loco + 6 coaches

993 M H 06:00 AM (daily) daily Loco + 6 coaches

H S 11:02 AM (Sat+Sun) Sat+Sun Loco + 6 coaches

M N 06:00 AM (Mon-Fri) Mon-Fri 1 additional coach

Line IC1 IC1 IC1

Table 8: Example for three service trips

50 © PTV AG


2.1.14.2 Specifications of lengths and timesIn conjunction with lengths, different attributes exist at different network objects. illustration 26illustrates these attributes and their correlations. The attribute Length at the link is used asstandard value for the attribute PostLength at the line route items. The user has the possibilityof overwriting these standard values. This can be done manually, for example in the list for lineroute items (see User Manual, Chpt. 12.1.8, page 1244). If the standard value from the linklengths should be carried out, you can use the function set lengths. There are four possibilitiesfor changing the link length.• The link length can be allocated from the direct distance of the link (see User Manual, Chpt.

2.13, page 212).• The link length can be allocated from the polygon length of the link (see User Manual, Chpt.

2.13, page 212).• When shaping the link, it can be specified, that the link length should comply with the

polygon length (see User Manual, Chpt. 2.13.11, page 227).• You can overwrite the link length in the link list manually for example and thus assign the

link any length (see User Manual, Chpt. 12.1.8, page 1244).

Line route 1 1 1

Time profile 1.1 1.2 1.1

Trip number 991 992 993

Valid day daily daily - Mon-Fri Sat+Sun Mon-Fri

Vehicle combination L+6C L+6C - L+6C L+6C 1C

M dep. - 5:10 6:00 · · ·

I arr. - | 7:00 · · ·

I dep. - | 7:02 · · ·

N arr. - 7:00 8:00 · · ·

N dep. 6:02 7:02 8:02 · · ·

W arr. 7:00 8:00 9:00 · · -

W dep. 7:02 8:02 9:02 · · -

H arr. 9:00 10:00 11:00 · · -

H dep. - 11:02 - · -

S arr. - 12:00 - · -

• Trip number 991 requires one service trip section• Trip number 992 requires one service trip section• Trip number 993 requires three service trip sections

Table 8: Example for three service trips

51 © PTV AG


Illustration 26: Lengths in VISUM and their coherence

VISUM offers different possibilities to assign times to links and time profiles. illustration 27provides an overview on how you can influence the run time values for links and time profiles.The standard value for the link run time for a PuT transport system (t-PuTSys) is calculatedfrom the quotient of the link length and the link-specific speed of the PuT transport system. Thelink run time of the PuT transport system is in turn used as standard value for the run times ofthe time profile. The departures and arrivals of a trip always automatically result from the timesprovided in the respective time profile. The run times for each PuT transport system can bechanged as follows.• The run times can be assigned from the line run times.• The standard value (quotient of link length and link-specific speed of the PuT transport

system) can be restored.• You can overwrite the times manually in the link list, for example (see User Manual, Chpt.

12.1.8, page 1244).The run times of the time profile can be edited as follows.• Transferring the standard values from the link run time• Transferring the times from a system route• Transferring the times from a link attribute• Setting the times from a time profile attribute• You can overwrite the times manually in the time profile list, for example (see User Manual,

Chpt. 12.1.8, page 1244).

Length

Link

To Length

Line route items

Mulit-Edit – Attribute: use Length DirDist

Mulit-Edit – Attribute: use Length Polygon

When editing the shape of the link: „Take over Length-Polygon“

Set lengths: uses the length of the link

Manual overwriting

Standard

StandardThe 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)

Legend

Manual overwriting

Connection between lengths

52 © PTV AG


Illustration 27: Assignment of run times in VISUM

2.1.14.3 The term timetable in VISUMAccording to the line hierarchy the timetable in PuT in VISUM is set up hierarchically. The lineroute contains the information on the location, the time profile accounts for relative timespecifications and the trips and their trip sections provide valid day, departure time and thetraversed sections of the line route. All four object types together make up the timetable,therefore the information, where and when PuT trips take place.Alternatively, the trip service can also be described through line routes, time profiles and aregular service per time profile (see "Headway-based assignment" on page 430). In this casewe are also taking about a timetable in VISUM.Due to this hierarchical setup of the timetable, is it possible to reuse the data for similar trips ina different way. Otherwise, the exact route would have to be specified for each individual tripvia the network and all times entered. With the line hierarchy however, a regular headway caneasily be defined by specifying the departure times, the time profile and the line route.

2.1.14.4 Data consistency along the line hierarchyAn important property of the line hierarchy is the consistency of the various data. Line route,time profile and service trip section must match at any point of time. A run time between two

Link length

Link type-specific speed of the PuTSys

Link run time t-PuTSys

Link

run time

Time profile

Departure/ Arrival

Vehicle journey

Generating link run times from line run times

Standard values

Manual overwriting

Set times: from link run time

Set times: from system route

Set times: from link attribute

Set times: from time profile item attribute

Manual overwriting

Standard

Standard

Standard

Auto

Auto

The value of the attribute is used as standard value for another attribute. Please note: when editing the attribute (for example t-PuTSys) afterwards, the value is not adjusted automatically (e.g. for the Run time at 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.

Legend

Allocation of run times

53 © PTV AG


stop points, which are not touched by the used line route, are never allowed to be specified inthe time profile. VISUM assures, that this consistency is always maintained. If you makechanges to the objects of the line route, the objects based on these may be adjusted, toreestablish a consistent state applicable to the new situation.

2.1.14.5 Aggregation of line routesAggregation of line routes is the aggregation of several line routes or time profiles to combinedobjects. A number of line routes with the same or similar information, can occur especiallywhen importing old networks from VISUM 8 or when importing timetable data from an externalsource. In an extreme case, an individual line route and time profile are created for eachindividual trip. Essential advantages of the hierarchical setup of the VISUM PuT model are thuslost, such as the reuse of line route data for many trips. Furthermore, the number of line routesmakes editing and maintaining the overview more difficult. The function aggregate line routessupports you when importing third-party data, to use these to your advantage.

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

Illustration 28: Example for the aggregation of line routes

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

A B C D

B C

A B C

A B C D

A B C DB C D

A B C D

EB C D

A B C D

A B CF

A B C DA B C D

G

Line routes to be aggregated Aggregated line routes

Violates criterion 2: The start of the path leg in common is not the start of either line route

Aggregation not possible

Violates criterion 3: The end of the path leg in common is not the end of either line route

Aggregation not possible

Violates criteria 2 and 3 Aggregation not possible

54 © PTV AG


• Line routes have to be assigned to the same line.• Line routes must have the same lengths on the common section.• Line routes must have the same direction.Aggregating time profiles can also be made more difficult as an option.• Time profiles must have the same run and dwell times.• Time profiles must have the same permissibilities for access and egress.• Time profiles must have the same vehicle combination.

2.1.14.6 Coupling time profilesCoupling means connecting cars of two or more trains on a line route section. The figure showsseveral examples of coupling two or three line routes. In order to couple two line routes on asection, the stop points of the time profiles of the coupled line routes have to match, whereasthe run times and the dwell times on the coupled section do not necessarily have to beidentical. If required, they are adjusted.

Illustration 29: Examples: Coupling two and three line routes

The number of line route services (vehicle journeys) and their departure times from From/ToStop 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 thetimetable of the coupled line routes. VISUM automatically adjusts the data of all line routes ofthe coupling group after changes to the time profile of a single coupled line route.

Changes to the number of vehicle journeysChanges to the number of vehicle journeys on a coupled section may occur in the followingcases.• Inserting and deleting trips (see User Manual, Chpt. 2.42, page 563)• Inserting and deleting trip sections (see User Manual, Chpt. 2.42, page 563)

H2

H4

H6

L1-1

L1-2

H1

H3

H5

H1

H3

H4

L1-1

L1-2

H5

L1-3

H2

H1

H3

H6

L1-1

L1-2

L1-3

H5

H2 H4 H4

L1-1

L1-2

H1 H2 H3

55 © PTV AG


• Changing the extension of trips (see User Manual, Chpt. 2.42, page 563)These changes need to have an effect on coupled time profiles, so that the supply of vehiclejourneys in each coupling section is synchronized again.

Changes to the temporal position of vehicle journeysIn the following cases, the temporal position of vehicle journeys may change. These changesneed to have an effect on coupled time profiles, so that the supply of vehicle journeys in eachcoupling section is synchronized again.• In-vehicle time/stop time changes to the time profile

This has an effect on all vehicle journeys that include the section start item --> referencepoint 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 inthe timetable editor, Multi-edit in the network editor or by shifting the vehicle journey withinthe timetable editor.

Coupling when calculating the PuT operating indicatorsCouplings in some cases have an effect on the calculation of PuT operating indicators (see"Impact caused by couplings" on page 609). On which indicators exactly they have an effect oncan be found in the file Indicator availability.xls in your VISUM installation. The effect oncoupling is illustrated by some examples.• Service-km of the line route

The kilometers traversed by the coupling section are considered only once and distributedto the coupled line routes. 50% of the length of the coupled route section is assigned toeach of the coupled line routes after coupling 2 line routes.

• Service time of the line routeAs for kilometers, the service time is only calculated once and distributed evenly.

• Infrastructure cost of the line routes for links and stop pointsLink 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 lineroute, 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 transferbetween line routes.

56 © PTV AG


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

Number of trips 10 trips

Empty time 10 min/trip

Kilometer costs 1 euro/km

Hourly costs 60 euro/h

Track price 1 euro/km

Seats 100 seats/vehicle combination

Table 9: Input data for the calculation example

Not coupled Not coupled isCoupled isCoupled

Line route L1-1 L1-2 L1-1 L1-2

ServiceKm 1,300 km 1,300 km 1,050 km 1,050 km

SeatKm 13,000 km 13,000 km 13,000 km 13,000 km

Service time 900 min 1,000 min 750 min 850 min

Out-of-depot time 1,000 min 1,100 min 850 min 950 min

Costs 1,300 euros 1,300 euros 1,050 euros 1,050 euros

Costs 1,000 euros 1,100 euros 850 euros 950 euros

Track costs 1,300 euros 1,300 euros 1,050 euros 1,050 euros

Total cost 3,500 euro 3,600 euro 2,950 euro 3,050 euro

Num Service Trips 10 10 10 10

Table 10: Calculation of indicators for the line route

H2

H4

H6

L1-1

L1-2

H1

H3

H5

50 km30 min

40 km40 min

40 km30 min

50 km30 min

40 km30 min

40 km30 min

57 © PTV AG


2.1.15 System routesA system route describes a route within the network from one stop point to another, with thetime required. As an option, this required travel time as well as supplements for starting andbraking per vehicle combination can be further specified. It is important that the travel times arealways stored independent of concrete lines in the system route. The system route thusrepresents a time which a certain vehicle combination requires on a given route between twostop points, independent of whether they belong to a line or even to a concrete trip.This travel time and route information can be used in two ways for creating a timetable.• Editing the shape of a line route with system routes• Travel times of existing line routes and time profiles are composed of system routes

Editing the shape of a line route with system routesSystem route path information provides a part of the line route path. The travel time informationgoes into the upper travel time profile in sections. Alternatively, you can create line routes orindividual sections with system routes. As soon as there are successive system routes at thecurrent end point, these can be used to extend the line route to the end stop point of the systemroute. The travel times for this section can be taken from the system route, preferably the onefor the correct vehicle combination, if this is specified. If both the start stop point and the endstop point of the system route are served by the line route, the run time is determined as thesum of the passage time and the TStartStop and TEndStop of the line route. If the line routeruns past one of the successive stop points, the share of the corresponding supplement isomitted. In this way, it is possible to use system routes for stopping as well as for traversingtime profiles.

Setting travel times of existing line routes and time profilesYou can use system routes to reset run times of existing line routes and time profiles. The pathinformation of the line route is not lost. If a matching system route exists between two profilepoints of the time profile, its run time will be used for the time profile. Depending on whetherpassengers are scheduled to board and alight at the limiting stop points, only the pure passagetime or the sum of the passage time TStartStop and TEndStop will be used.A system route matches a section between two profile points, if the following conditions apply.• Both profile points are located at stop points.• These stop points are start stop point and end stop point of the system route (this requires

that these stop points must be open to the transport system of the time profile).• The course of the line route underlying the time profile is identical to the course of the

system route.• The transport system of the system route is identical to the one of the time profile (i.e. the

line).• If the respective option has been selected, at the system route, a specific run time must be

specified for the vehicle combination allocated to the time profile or line.

Link H2-H3 H3-H4 H2-H3 H3-H4

ServiceKm 1,000 km 400 km 500 km 400 km

Num Service Trips 20 10 10 10

Table 11: Calculation of indicators for the links

58 © PTV AG


If several matching system routes exist, the times are not set for the sections in question.When new time profiles are created, the run times are calculated on the basis of the systemroute (if available). Special defaults are taken into account for the vehicle combination if it isspecified for both the system route and the time profile. If no system routes have been defined, link times are used as before.

2.1.16 Points of Interest (POI)A Point of Interest (POI) is a user-defined network object with spatial reference. The spatialreference is established by entering an X and a Y coordinate for each POI. POIs can beinserted 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 apreselection of symbols, which can be used for visualizing POIs (star, cross, triangle, SC, andothers).

Points of interest are mainly used for data management (for example, network datamaintenance in Traffic management centers) and accessibility studies. For your datamanagement, you can create as many user-defined attributes for POIs as you like, in whichyou can store your data (see "User-defined attributes" on page 87). illustration 31 shows anexample for applying POIs in reachability analyses. Here secondary schools are included asPOIs (red stars) in the model. The catchment area of these schools was visualized with the 2Ddisplay (see "2D display" on page 702).

Note: POI polygons are managed like surfaces and can be made up of multi-face polygonsor polygons with holes (see "The surface data model in VISUM" on page 96).

59 © PTV AG


Illustration 31: Reachability analyses for secondary schools

POIs are managed in POI categories. Each POI must be allocated to a POI category. Beforeinserting the first POI, you thus have to create a POI category (see User Manual, Chpt. 2.33.1,page 450). Any number of POI objects can then be inserted in the defined POI category, in thenetwork.POI categories in a transport network are for example • Parking and Park&Ride facilities• Public facilities such as schools, churches of hospitals• Pre-emption points for AVL systems• SC controller among other thingsPOI categories can be organized as a hierarchy. This is how you can create a POI categoryschools with the three subcategories secondary schools, junior high schools and elementaryschools.Each POI can be assigned to a node, a link, another POI, a stop area, a stop point or a POIcategory. You can illustrate this assignment graphically in the network (see User Manual, Chpt.12.2.3.7, page 1272). In the example of illustration 32 allocations are used to illustrate forparking lots in a downtown area which links the approaches lead to.

60 © PTV AG


Illustration 32: Allocating POIs to links

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

2.1.17 Count locations and detectorsCount locations mark the geographical position of traffic counts. This can be both one-offcounts 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.0and describes where the count location lies on the link. Since a link in VISUM is alwaysdirected, a direction is indicated as well. Furthermore, the count location has a type, todifferentiate permanent count locations and manual count locations, for example. Thecoordinates of the count location are available as a calculated attribute; these are calculatedfrom the coordinates of the link and the position along this link. Each link can be assigned bydirection to one or more count locations. Each count location can in turn be assigned todetectors.A detector illustrates a lane-related count direction. It breaks down the count data of a countlocation precisely by lane. The detector is identified by its number and has in addition to codeand name a geographic position, specified by a pair of coordinates. It is not assigned to a link,

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

61 © PTV AG


but optionally a count location and thus indirectly a link. The number of observed lanes isdetermined by the attribute Observed lanes, the observed lane furthest to the right,determined by the attribute Lane position.If a detector is assigned to a count location and therefore a link, the observed lanes have to becompatible with the number of link lanes, which means that no lane is allowed to be observedwhich is not defined on the link. With a lane number of 2 the detectors for lanes 1 and 2 areallowed to be defined. It is however permissible, that a lane is observed by several or nodetectors.Count locations and detectors are used less to maintain data, but more to visualize andprocess thematic maps. Even though you can save count data to user-defined attributes ofcount locations, you can also save them directly to user-defined attributes of the link (see"User-defined attributes" on page 87). The advantage of saving count data directly at links isthat, in evaluations, you can compare them directly with the calculated volumes, which are alsosaved with the link attributes. This approach is particularly recommended if you want to use thematrix correction technique TFlowFuzzy (see "Updating demand matrix with TFlowFuzzy" onpage 179).Count locations are thus primarily used for marking the position of a count in the network. Youcan use the number to refer to external data, where applicable. illustration 33 shows a map,which is illustrated in the local position of the count location in the network, together with thedate of the last traffic count.

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

62 © PTV AG


2.1.18 Toll systemsToll systems are optional network objects which can be used to integrate toll zones and tollsinto the network model (see User Manual, Chpt. 2.37, page 476). They represent the (see"Basics of the assignment with toll consideration" on page 355)basis for the calculation of roadtolls in the Tribut procedure .

Notes: Do not just use count locations to integrate count values into the network. Instead useuser-defined attributes on links. However, if the current project requires the visualization ofcounts or count location-related values shall be managed externally, the effort for thecoverage of count locations and detectors can pay off.Compared to assignments for example, count locations and detectors do not have aninfluence on procedures. They are also relevant for signal-controlled nodes or the ANMexport to VISSIM.

63 © PTV AG


In VISUM, there are two kinds of toll model types:• Area toll

In case of an area toll, a geographically contiguous part of the network is designated as atoll zone and a distance-independent charge applies to any trip including a portion withinthe toll zone. In VISUM, you can define such toll zones by inserting a polygon andspecifying a toll for all associated chargeable links. The "Congestion Charge" in London is an example of an area toll. In the city center, a tollis charged as soon as the specified area is entered.

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

• Matrix tollThis type of toll model is the typical road pricing scheme for motorway corridors. A subsetof 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 thereis an individual price for each pair (entry – exit). Because of these pairs, this type of roadpricing scheme is called a matrix toll. Toll typically increases with distance but in adegressive way, i.e. the toll per km decreases with distance.

2.1.19 GIS objectsGIS objects are POI-like network objects (n categories with m objects of the type point, polylineor polygon) that are only available during a Personal Geo Database (PGD) connection (see"Connection to the Personal Geo Database and GIS objects" on page 633). This is how GISdata can constantly be synchronized between the PGD and VISUM.

2.1.20 ScreenlinesA screenline is a polygon, which can be inserted into the network by the user with any numberof intermediate points. The screenline is inserted so that it intersects multiple links. The valuesof any attributes of all links, which are intersected by the screenline, can then be aggregatedwith the screenline. The following aggregate functions are thus available respectively for all oronly for the active links (see "Indirect attributes" on page 82).• Number of links which intersect the screenline.

64 © PTV AG


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

screenline.The orientation of a screenline depends on the sequence of the polygon points along itscourse. It is always oriented to the right in the direction of creating. By default, arrow headsalong the course indicate the orientation. For the aggregation, you can take into account alllinks 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.000and 3.000 persons. The screenline then aggregates the values of the links that it intersects. Inthe example, it identifies a total of 4.000 persons in screenline orientation for all links and anaverage of 2.000 persons.

Illustration 35: Summation and average calculations with screenlines

With the aid of screenlines, you can for example determine the traffic that enters and exits thedowntown area every day in a traffic engineering study which analyses the traffic volume of adowntown area. In illustration 36 149.334 vehicles of the PrT enter the downtown area and76.370 persons in PuT.

65 © PTV AG


Illustration 36: Calculation of the urban traffic volume with screenlines

Screenlines are a useful construction to calibrate an assignment model by means of countedlink data. A screenline aggregates all links intersecting it. This is useful for the calibration of themodel 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. Ascreenline could, for example, take the course of a river. For the calibration of the model, inprinciple, 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 theaid of the assignment analysis, you can evaluate aggregated count data and assigned volumesof the screenline statistically (see User Manual, Chpt. 4.4.2, page 838). With this analysisfunctionality, the efficiency of the calibration can be increased considerably.

2.1.21 Junction modelingVISUM provides the possibility to model junctions in detail. There are two major fields ofapplication, namely the use of a detailed node impedance model among others in assignmentprocedures, and the export for a microsimulation in VISSIM.

Element Description

Topology Topologies are used to describe the geometry of nodes and main nodes in detail. The principal elements of topologies are legs.

Table 12: Network objects of the Junction model

66 © PTV AG


2.1.21.1 Link orientationsLink orientations play an essential role when defining node topologies (see "Topologies" onpage 68). The link orientations are used to determine the amount of legs. Each link has fourorientation attributes, namely From and To node orientation, and From and To main nodeorientation. The two latter attributes are only defined for cordon links of a main node (see"Main nodes and main turns" on page 36). The orientations are always undefined for closedlinks. A link is closed, if its transport system set is empty or if the number of lanes is zero. If alink 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 nodehas more than sixteen open incoming links or more than sixteen open outgoing links, all linkorientations will be undefined. At such nodes, a topology and thus a signal control cannot bedefined.The allocation of link orientations complies with specific rules. If an incoming link and itsopposite outgoing link are open, the To (Main) Node Orientation of the incoming link and theFrom (Main) Node Orientation of the outgoing link are identical. If there is an incoming linkwhose 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-wayroads and outgoing one-way roads in one leg (see "Topologies" on page 68), if you give themthe 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 calculatedautomatically, the type of calculation depends on the option set under Network > Networkparameters > Network objects > Link orientations (see User Manual, Chpt. 2.13.4,

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

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

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

Signal control A signal control describes the total of all signal control data at one or more nodes or main nodes. There are signal group-based and stage-based signal controls.

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

Signal group A signal control contains a set of signal groups, even if it is stage-based. Signal groups serve to describe lane turn-based signal controls in detail.

Crosswalk Crosswalks serve to describe the pedestrian conditions at nodes and main nodes. They refer to legs. A leg can have several crosswalks depending on whether a center island or a channelized island has been defined.

Element Description

Table 12: Network objects of the Junction model

67 © PTV AG


page 215). Normally, the value is set to 8. This means that VISUM picks the best orientationsfrom 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 theorientation. If the orientations do not suffice – i.e. the node or main node has more than eightlegs – VISUM adds the subordinated secondary orientations (e.g. NNE).

2.1.21.2 TopologiesIn macroscopic traffic models, an at-grade junction is represented by a node (point object) withturns. The macroscopic modeling does not reveal anything about the exact topology or thegeometric layout of an intersection. Nearly the same applies to the node control. The optionalenhancement of the VISUM network model by the node topology and the junction control canbe used in the following fields:• Calculating the performance at a node• Considering node impedances during assignment• Providing entire intersections for the microscopic model VISSIMA node topology consists of the items node legs, lanes, lane turns, and crosswalks. If a signalcontrol is allocated to a node, its data refer to the node topology. By default, no topology dataare provided at a node. These are generated not until the first access.

LegsThe principal elements of the topology are the legs. A node/main node can have up to sixteenlegs. The set of legs is determined by the orientations of the incoming and outgoing links (see"Network objects of the Junction model" on page 66). For each used link orientation, exactlyone 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, thecenter island length and width both need to have a value > zero. For a channelized island toexist, the channelized island length needs to be > zero. The Stop line position attribute is onlyused for the export to VISSIM. Legs also possess a set of lanes.

LanesThere are incoming lanes and outgoing lanes, as well as through lanes and pockets. Thenumber of through lanes at a leg cannot be changed. It is based on the set number of lanes atthe links which underlie the leg. Therefore, if the incoming link of the leg has three lanes(attribute Number of lanes at the link) and at least one transport system, the leg features threeincoming through lanes. If the number of lanes at this link is changed, the number of throughlanes at the leg will be adjusted automatically. We recommend double-checking the adjusted

Notes: In VISUM versions prior to 11.5, this setting did not exist for the calculation. VISUMused to implicitly calculate with today's setting 4. This means that VISUM first tried to allocateonly the main orientations, and only switched to the secondary orientations in case of nodeswith more than four legs. The subordinated secondary orientations were not used in earlierVISUM versions.Please note, that you can define varying numbers of legs at a node or main node, dependingon the number of pairs of incoming and outgoing one-way roads that are given the sameorientation.

68 © PTV AG


topology data after such modifications. Since at least one open link underlies each leg, eachleg features at least one through lane.The number of lanes at a leg can be changed by creating pocket lanes (pockets). Pocket lanesalways 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 duringVISSIM exports and for specific methods of impedance calculations at nodes.By default, the transport system set permitted on a lane corresponds to the transport systemset of the underlying link. For pockets, the transport system set of the origin lane is used bydefault.

Lane turnsA lane turn connects an incoming lane with an outgoing lane. When generating a topologyautomatically, 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 theoutgoing 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 ofthem makes a left turn on a right lane and the other one goes straight on a left lane. This is yetpossible and desired, if the left turn is a PrT turn and the other one a PuT turn. In this way, atram can, for example, be modeled in central position.The set of lane turns basically determines the results of the node impedance calculations at anode/main node.

CrosswalksCrosswalks are objects that connect the sides or the islands of a leg per direction. Dependingon the combination of islands at a leg, you can define up to six crosswalks. If the leg has, forexample, a center island, i.e. its center island length and width are both > zero, and achannelized 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 islandand the other side, and one each in the opposite direction.Crosswalks are exported to VISSIM. For crosswalks, a pedestrian volume can be specified.This is relevant when calculating the node impedance employing ICA (see "IntersectionCapacity Analysis according to the Highway Capacity Manual (ICA)" on page 213).

Leg templates and geometry templatesIn order to ease the input, leg templates can be used for legs. With the aid of leg templates, aset of predefined lanes, lane turns, and crosswalks are generated at a leg. Contrary to earlierprogram versions, the object's reference to the template is not kept when using leg andgeometry 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 aretransferred to the template. They can, however, be edited later on. A leg template consists oflane templates. If a leg template is generated from a leg, the lanes of the leg are used as amodel for the lane templates. The lane templates can also be edited later on.Leg templates can only be used at topologies of 3 or 4 legs. The data must match so that a legtemplate can be used at a leg. If a template is suitable for nodes with three legs, it can thus not

Note: The numbering of the lanes differs from the one in VISSIM.

69 © PTV AG


be used for legs at nodes with four legs. The number of incoming and outgoing lanes of the legand of the template must also be identical.Contrary to leg templates, geometry templates can be applied to all legs of the node. They canalso be used exclusively at nodes with 3 or 4 legs. A geometry template is made up of severalleg templates. When using a geometry template, the leg templates are applied to the legs ofthe node. To determine which leg template is to be used at which leg, a reference leg must bespecified for the template. Geometry templates can only be used, if at least one valid referenceleg exists, so that all leg templates can be used in the right order for all legs at the node.

2.1.21.3 Signal controlsSignal controls (SCs) can be allocated to signalized nodes and main nodes (attribute Controltype has the value Signalized). There are three types of SCs: signal group based, stagebased and VISSIG. In case of signal-group SCs, signal groups can be defined immediately. Incase of stage-based SCs, stages must be defined first, and after that, signal groups can beallocated to the stages. VISSIG controls are managed with an external program (see "Externalcontrols" on page 71).

The key attributes of a signal group are its Green time start and its Green time end. Theseattributes are relevant to the node impedance calculation (see "Signalized nodes (HCM 2000Chapter 16)" on page 214). In case of stage-based SCs, green time start and green time endof a signal group correspond to the green time start and green time end of its stage. If theattributes Green time start and Green time end have value 0 at a signal group or a stage, andthe attribute Green time end is identical to the cycle time of the SC, this will be interpreted aspermanent green. Both attributes are restricted by the cycle time of the SC. The Green timeend can have a smaller value than the Green time start. The green time is determined bysubtracting the difference of both values from the cycle time of the SC. The green time cannotfall below the minimum green time of a signal group.Signal groups also have the attributes Amber and Allred. Furthermore, intergreens can bedefined between signal groups. All of these values are important when calculating the signalcycle and split optimization. Hereby, the attribute Used intergreen method of the signalcontrol determines whether the amber and allred time or the intergreen matrix is used foroptimization. The attribute ICA loss time adjustment is used in the calculation of theimpedances with ICA to determine the effective green times with the aid of the specified greentimes. The attribute VISSIM coordinated is only relevant for the VISSIM export.The relation between the signal control and the network is established when allocating thesignal 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 tothe SC of the signal group. Likewise, any number of signal groups of the SC can be allocatedto each lane turn that is allocated to the node or main node of the lane turn. A signal group canalso be allocated to any number of crosswalks. A crosswalk, however, can only refer to onesignal group. The data model is not restricted here. As an example, VISUM does not checkwhether a signal group is allocated to each lane turn. It does not check either whether

Note: An SC can be allocated to multiple nodes or main nodes. This is not recommendedthough, because then the Signal cycle and split optimization operation does not yield goodresults. The number of the coordination group of the SC plays a role in the Optimization ofthe SC offset operation (see User Manual, Chpt. 2.39.14.1, page 539).

70 © PTV AG

Chapter 2.2:Spatial and temporal correlations in VISUM

conflicting volumes have overlapping green times. Should the signal control be used todetermine node impedances, it is recommended to carry out the respective ICA network checkoption to detect incomplete node models (see User Manual, Chpt. 2.40, page 545).

External controlsA special feature of external SCs is that the data are not saved in the version file. The data aresaved in control files of the format *.sig. This way, they can also be accessed by otherprograms, for example VISSIM. The program VISSIG is used in VISUM to edit external controldata. In external controls, multiple signal programs can be stored. This is not the case for signalgroup based or stage based controls. Therefore, the SC attribute Signal program number isonly relevant when dealing with external controls. VISUM accesses the data saved in thecontrol file at certain times. This is, for example, the case when opening a version file or whenrunning the operations Signal cycle and split optimization and Update impedances atnode via ICA.

Stage templatesStage templates can be used to easily generate signal control data at a node or main node(see User Manual, Chpt. 2.39.13.2, page 535). If a stage template is allocated to a node, theSC of the node then possesses a lot of stages and signal groups. Lane turns are alreadyallocated to the signal groups. This means, for example, that conflicting volumes are signalizedwith different green times.

2.1.22 Network checkVISUM 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 indicatesa modeling error. To identify such errors, several tests are provided (see User Manual, Chpt.2.40, page 545).

2.2 Spatial and temporal correlations in VISUMIn VISUM, the following can be specified:• Calendar• Valid days• Time series• Analysis time intervals

2.2.1 Calendar and valid daysYou can specify a calendar and valid days for your network.

Note: It is recommended to complete the modeling of a node or main node, before allocatingsignal groups to lane turns. When deleting or inserting lane turns, the signal control data canget lost.

Note: Prerequisite for the use of a stage template is, however, that a stage-based SC isalready allocated to the node or main node.

71 © PTV AG


2.2.1.1 CalendarWith the aid of the calendar, the modeling of transport supply (in PuT and for the DUEprocedure in PrT) and demand (for the dynamic procedures of PrT and the headway-basedand timetable-based assignments of PuT) can be refined considerably. It is not only possibleto model any day, but also to manage any combination of weekdays or individual days. Thecalendar is global, i.e. only one of the following three calendar options can be applied to theentire model. Use of the calendar is optional. The following options can be selected for anetwork model:• No calendar

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

• Weekly calendarThe demand (for the dynamic procedures of the PrT and for the headway-based andtimetable-based procedures of the PuT) and the PuT supply can be differentiated for theindividual weekdays Monday to Sunday. It is possible to specify for each service trip sectionweekdays on which there will be a service. The analysis period can be any time period ofentire days within the week (such as Monday to Friday).

• Annual calendarValid days can be defined for any day of the year. The analysis period can be set to anytime period (in entire days) within the calendar period (e.g. 14th of July 2008 to 20th of July2008).

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

In the Dynamic stochastic assignment and DUE, traffic supply can be time-varying. Time-varying attributes are used (see "Time-varying attributes" on page 90). When using acalendar, valid days can be specified for these time-varying attributes, on which theyshould take effect.

• Assignments in PuTValid days are allocated to and affect single vehicle journey sections.

• PuT analysis (operation PuT operational indicators)• PuT passenger survey

2.2.1.2 Valid daysValid days are closely linked to the calendar as they can be specified on the basis of theselected calendar. First the kind of calendar is thus chosen when modeling, and then validdays are specified on the basis of the respective calendar.A valid day is a freely definable set of days within the used calendar. If a weekly calendar isused, a valid day can, for example, span the days Monday to Friday (the valid day can then becalled Monday to Friday for example). The timetable in PuT is based on a calendar (see "Calendar" on page 72). A valid day can beassigned to each vehicle journey section. Optionally, this can consist of an individual day or anexample week, however, a defined period on the calendar can also be used. In each case, theavailability of individual service trip sections can be specified by valid days. A valid day is afreely definable set of days of the underlying calendar. Each valid day can be assigned its ownname. Valid days usually represent regularly recurring patterns, such as Monday to Friday, but

72 © PTV AG


these could also be individual days (for example 01.01.2009). How to define a valid daydepends of the selected calendar:• No calendar

Exclusively uses the valid day daily. It is not possible to create further valid days. Demandand supply are modeled for an unspecified, recurring day in this case.

• Weekly calendarApart from the predefined valid day daily, any desired valid days can be created, which arespecified by entering one or several valid weekdays (e.g. all weekdays with the valid dayname Mon-Fri).

• Annual calendarValid days can be defined for any day of the year within the calendar period. The followingpossibilities 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 assignmentprocedures:• (see "Dynamic stochastic assignment" on page 396)Dynamic Stochastic assignment• Dynamic User Equilibrium (DUE) (see "Dynamic User Equilibrium (DUE)" on page 367)• Metropolis (see "NCHRP 255" on page 402)

2.2.2 Time reference of the demand (time series)Just like the transport supply and the assignment, any demand has a time reference. In statistic PrT assignments, the demand always refers to the analysis period. The demandtime 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 nothave an explicit time reference here, but are described by a start time and a time series.

The start time specifies the time and – if the weekly or annual calendar is used - the day onwhich the period referred to by the demand in the matrix starts. The end of the period iscalculated from the length of the assigned time series.There are two different types of so-called standard time series which have to be defined inVISUM:• 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 seriesas percentages is used for a demand segment, a demand matrix must also be specified,

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

Note: A time series must be allocated to the demand segments in order to calculate anassignment with these procedures.

73 © PTV AG


whose demand is distributed temporarily with the specified weights. This matrix mustcontain the number of travel demands in the time period, defined by the starting time andthe length of the time series.

Illustration 37: Time series by percentage

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

Illustration 38: Time series of matrix numbers

Time series of matrix numbers require a full matrix for each time interval, which must begenerated and also saved. In order to save the effort and still be able to model a certain loaddirection in the demand, VISUM provides demand time series as a compromise. These aregenerated on the basis of a standard time series, whereas a different standard time series canbe specified for each pair of zone types. In this way, it is possible to specify deviating timeseries for selected pairs of origin and destination zones with known structural features (forexample purely residential or commercial areas).For each demand segment, either a fixed demand matrix together with a time series aspercentages is specified, or a demand time series which itself is a time series of matrices.Moreover, a start day and the start time per demand segment must be specified.

Note: When using time series of matrix numbers, it is possible to specify a value for thedemand 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 factorapplies to each OD relation per time interval.

74 © PTV AG


2.2.3 Time reference of volumes: analysis time intervals and projectionVolumes always have at least an implicit time reference which they get from the time referenceof 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 ashared time unit and then project them evenly to longer temporal horizons, the followinganalysis time intervals are provided in VISUM. • The calendar period covers the set calendar, i.e. one, seven or any number of days.• The Time reference of the demand determines the number of travel demands within the

assignment time interval. The time reference is established by the start time of the demandsegment and the time series allocated to the demand segment (see User Manual, Chpt.3.1, page 635).

• The Assignment time interval mainly serves to determine the share of the demand thatneeds to be assigned. It is crucial that the assignment time interval of each assignment lieswithin the analysis time period. In the assignment, the share of the demand that accountsfor the assignment time interval according to the time series is assigned to the paths foundin this time period. The assignment area and the demand time series need to overlap, sinceotherwise 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, DynamicStochastic assignment) of the PrT and for the headway-based and timetable-basedassignment of the PuT. The assignment time interval is specified in the parameters of theassignment procedure. In all statistic PrT assignments (Equilibrium assignment,Incremental procedure, Equilibrium_Lohse, Stochastic assignment, Tribut), the assignmenttime interval automatically corresponds to the analysis period.

• The Analysis period (AP) represents the period on which all evaluations are based. If nocalendar is used, the analysis period is one day. If a weekly or annual calendar is used, theanalysis period is specified in the procedure parameters. The analysis period is a timeperiod 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 intoanalysis time intervals or the analysis horizon. The analysis period must be within thecalendar period. The assignment intervals must lie completely within the analysis period.For the analysis period projection factors can be specified at the demand segments, whichproject 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 demandmatrix is identical to the analysis period, the projection factor is 1. If the demand matrix isbased on one day, yet the analysis period on a week, the factor would have to be set to 7(when assuming that the traffic is the same on all 7 days of the week).

• The Analysis horizon (AH) is a longer time period on which the results can be projected.It is not specified explicitly. Instead, the projection factors on the analysis horizon arepredefined. These can be specified at the demand segment (for the volumes) and at the

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

75 © PTV AG


valid day (for the operator model) (see "Basic calculation principles for indicators" onpage 603). As a rule, an analysis horizon of a year is regarded. Since a different projectionfactor can be specified for each demand segment, the projection factor of daily values to ayear can for example be smaller for a demand segment Pupils than for a demand segmentCommuters, as the pupils have more vacation days on which they do not generate anytraffic. The volume of a network object in terms of the analysis period is always the sum ofthe volumes of all paths which lead via this network object, multiplied by the projectionfactor of the demand segment. This projection factor compensates that the assignmenttime interval might just cover a part of the analysis period.

• Analysis time interval (AI)For a more refined temporal evaluation of calculated results, analysis time intervals can bedefined (see "Temporal distinction with analysis time intervals" on page 79). Each analysistime interval needs to lie completely within a calendar day of the analysis period.

Illustration 39: The relationship between the different analysis time intervals

Example for projection factorsVolumes are to be determined per week in a model with a weekly calendar. To reduce the runtime of an assignment procedure, the entire week should not be used as an assignment timeinterval. It is assumed that the demand and the supply of week days Monday to Friday are thesame. Demand data are available for the standard working days, Saturday and Sunday.

Note: Contrary to the analysis period, which incorporates the assignment time interval andthus requires a projection of the volumes, the analysis time intervals identify the exact volumewhich arises in the respective time period. The projection factors of the individual demandsegments thus do not affect the volume per analysis time interval. If the analysis period iscovered entirely by the analysis time interval, the ratio of the sum of all volumes of theintervals for the volumes based on the analysis period is in strict conformity with theprojection factor.

Day nDay 1Calendar period CP

DSeg 1

DSeg i

Analysis period AP in CP

Analysis time interval AI in AP

AP

AI

ATIAssignment time interval ATI in AP

Demand segments

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

76 © PTV AG


This is solved in the following way. Three demand segments are set, which each represent thedemand on the working day, Saturday and Sunday. Each demand segment is provided with anappropriate time series, whereas the standard working day has to be one of the days Mondayto 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 followingprojection factors are used, to correctly project the volumes.

Example for the interaction of analysis time periods and time seriesTo calculate an assignment, the assignment time interval and the time, which is valid for thedemand, have to overlap. Three examples are shown below. In the first case (illustration 40),the demand and assignment intervals do not match and the assignment cannot be calculated.VISUM then issues the error message No OD pair shows demand > 0 within assignmentinterval. No connections calculated. In the second (illustration 41) and third example(illustration 42) assignment time interval and validity period of the demand overlap, so that anassignment can be calculated. Table 14 provides an overview on analysis time intervals andtime series of the three examples.

Demand segment Projection factor AP Projection factor AH

Standard working day 5

Saturday 1 52

Sunday 1 52

Table 13: Deriving projection factors for AP and AH

Calendar Assignment time interval

Analysis period

DSeg start day

DSeg start time

Standard time series from

Standard time series to

Assignment can be calculated

Ex. 1 Weekly calendar

Mo. 6:30-7:30

Mo. - Mo. Mo. 01:00:00 00:00:00 02:00:00 No


Mo. 6:30-7:30

Mo. - Mo. Mo. 05:30:00 00:00:00 02:00:00 Yes


Mo. 6:30-7:30

Mo. - Mo. Mo. 00:00:00 05:30:00 07:30:00 Yes

Table 14: Example for the interaction of analysis time intervals and time series

3657

--------- 5⋅ 260=

77 © PTV AG


Illustration 40: Assignment not possible because the validity of the demand and the assignment time interval do not overlap

Illustration 41: The demand between 6:30 and 7:30 am is assigned

Calendar period CP

Analysis period AP in CP AP

Assignment interval AI in AP

Time series of the demand segment

Mo Tu

6:30 7:30

1:00 3:00

AI

Calendar period CP



Time series of the demand segment

Mo Tu

6:30 7:305:30

AI

Share of the demand that is assigned

78 © PTV AG


Illustration 42: The demand between 6:30 and 7:30 am is assigned

2.2.4 Temporal and spatial differentiation of calculation resultsThe results of the impact models, after the completion of the calculation, are available as alarge number of attributes, some of which refer to the routes or connections found in theassignment procedures, while the majority refers to the network objects (links, nodes, turns)and all objects of the PuT network model (see "Impact models" on page 189). In addition tostructuring the content, many attributes can additionally be differentiated by space, bymodeling territories (territorial section) or by time, by creating analysis time intervals (timesection).An extremely high level of model detail can be achieved with a combination of temporal andspatial distinctions. Passenger kilometers, costs, and revenue, for example, can be displayedfor trips served by a specific line using low-floor buses between 6:00 and 7:00 am in thecommunity territory.

2.2.4.1 Temporal distinction with analysis time intervalsIf a period, which is shorter than the analysis period, shall be analyzed for the temporaldifferentiation of calculation results, several analysis time intervals can be specified (see UserManual, Chpt. 4.2.2, page 824). The analysis time intervals must lie within the analysis period.They have to neither be consecutive nor of the same length. The analysis time period, musthowever, be within a day, is therefore not allowed to contain a day changeover. Provided thatattributes can be assigned on a time basis, the portion assigned to each defined analysis timeinterval can be identified separately. In PrT, evaluations broken down by time slices can only be made for the dynamic assignmentDUE and the Dynamic Stochastic assignment (see "Dynamic User Equilibrium (DUE)" onpage 367 and "Dynamic stochastic assignment" on page 396). The reason is that only in thoseassignments, the traffic demand can be time-varying. Therefore, evaluations for analysis timeintervals within the analysis period can only be made in the course of these procedures. The

Calendar period CP



Time series of thedemand segment

Mo Tu

6:30 7:305:30

AI

Share of the demand that is assigned

DSeg Start timeMo. 00:00

79 © PTV AG


link volume of the rush-hour traffic from 7 to 9 am can thus for example be evaluatedseparately.In PuT, evaluations broken down to time slices are only possible for the timetable-basedassignment procedure. In the timetable-based assignment procedure however, there are noconnections that are fixed in time, so that it is not possible to apply assignment results to aspecific analysis time interval.

2.2.4.2 Spatial distinction with territoriesFor spatial distinctions, the user initially defines territories (see "Territories" on page 40). Theseare 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 passengerkilometers of a line can be spatially localized, the share assigned to each territory can beidentified separately. Thus all passenger kilometers will be calculated, which arise within theterritory polygon. To calculate such an evaluation, the Territory indicators procedure must berun (see User Manual, Chpt. 4.4.3, page 844). The results can be displayed in the listTerritories > Basis (see User Manual, Chpt. 12.1.8, page 1244) and are also available in thefilters 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" onpage 489). Here you can even calculate indicators for combinations of territories, objects of theline hierarchy (transport system, main line, line, line route, time profile, vehicle journey) and asan option, vehicle combinations. You can thus for example calculate the number of servicekilometers traveled by the vehicle combination tram on line 2 in the urban area. Here, anadditional distinction can be made for most of the indicators on a temporal basis. You wouldthus get just the service kilometers between 5 and 6 pm for example. Use the procedure PuTOperating Indicators to carry out such an evaluation (see User Manual, Chpt. 7.3.1,page 1075). The results can be displayed in the Territories > PuT detail list (see UserManual, Chpt. 12.1.8, page 1244).

2.2.5 Adjustment of the capacities to the demand valuesPlease note, that the link and turn capacities can have different units depending on theselected assignment procedure. While in statistic assignments of the PrT (such as theEquilibrium assignment) the link capacity is, for example, entered in car units per analysisperiod (PCU/AP), in the dynamic DUE procedure, the link capacity is interpreted in car unitsper hour (PCU/h). Although the Capacity attribute is attributed identically at the link, its unit isinterpreted differently depending on the assignment procedure that is used.Furthermore, the units in which link and turn capacities are modeled always need to match theunits of the demand matrix. It is thus not allowed to manage link capacity values in unit PCU/hand assign a demand matrix in the same model which contains values for the whole day.More detailed information on which units are used for capacity and demand in the individualprocedures will be given in the section on input and output attributes of each assignmentprocedure (see "User Model PrT" on page 195).

2.3 AttributesIn VISUM there are the following types of attribute:

80 © PTV AG

Chapter 2.3:Attributes

• Direct attributes• Indirect attributes• User-defined attributes• Time-varying attributes

2.3.1 Direct attributesEach of the network objects is described by means of VISUM attributes (direct attributes). Thefollowing types are differentiated as follows:• Input attributes (for example Stop number) and• calculated attributes, which are also called output attributes (for example Passengers

boarding at a stop)Each VISUM attribute is described as follows:• by a name (for example Number)• by a code (for example No.)• by an attribute identifier (attribute ID), which is always in English (for example No)

The Table 15 shows an example of some input and output attributes of the link.

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

Note: The Attribute.xls file in the Doc directory of your VISUM installation contains thecomplete list of all VISUM network object types (which are also designated as tables inconnection with databases) and all attributes of each network object. You will find each IDthere, which clearly identifies the attribute, as well as its name and code and a description,what the attribute means.

Attribute Input attribute Calculated attribute

Number X

TSysSet X

Capacity PrT X

Number of lanes X

t0-PrTSys X

tCur-PrTSys X

Capacity PrT [Veh] X

Saturation PuT seats X

Passenger kilometers X

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

81 © PTV AG


2.3.2 Indirect attributesIn addition to direct attributes of the currently selected network object, users can also accessindirect attributes (read-only). These are direct objects of other network object types that arenetwork model-related to the selected object. Therefore, for a marked network object, both thedirect 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 logicalrelation to the base object. It is often convenient to filter network objects not only by their ownproperties, but also by the properties of their logical neighbors in the network, or to displaythese properties next to their own properties in listings or graphics (for example displaying theaggregated 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 allowaccess 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 selectednetwork object type and other network object types are indicated as follows.

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

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

Selection of the indirect attribute Zone\Number of connectors in the attribute selection window

Display of indirect attributes in the table right next to the attributes of the connector

Table 16: Example for a 1..1 relation in the VISUM network model

82 © PTV AG


• several relations (0..n). Such a relation, for example, exists between stop areas andstop points. Since no 1:1 link exists between the network objects types in this case, youneed to select an aggregate function which pools all related network objects (the aggregatefunction 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 selectedstop area). Below, an example is given for each of the aggregate functions provided inVISUM.

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

Determine the number of associated network objects. In Table 18, the number of stopareas associated with a stop is determined.

• Min and MinActiveDetermine the minimum value of all associated network objects for the selected attribute.In Table 19, the minimum number of boarding passengers at all stop points of the stop areais output.

Selection of the indirect attribute Main node\Name in the attribute selection window

Display of indirect attributes in the table right next to the attributes of the node

Table 17: Example for a 0..1 relation in the VISUM network model

Selection of the indirect attribute Num: Stop areas in the attribute selection window for stops

Display of indirect attributes in the table right next to the attributes of the stop

Table 18: Example for a 0..n relation with aggregate function Num

83 © PTV AG


• Max and MaxActiveDetermine the maximum value of all associated network objects for the selected attribute.Table 20 displays the maximum number of boarding passengers at all stop points of thestop area.

• Sum and SumActiveDetermine the total of the values of all associated network objects for the selected attribute.Table 21 displays the total of boarding passengers at all stop points of the stop area.

Selection of the indirect attribute Min:Stop points\Passengers boarding(AP) in the attribute selection window

Display of indirect attributes in the table right next to the attributes of the stop area

Table 19: Example for a 0..n relation with aggregate function Min

Selection of the indirect attribute Max:Stop points\Passengers boarding(AP) in the attribute selection window


Table 20: Example for a 0..n relation with aggregate function Max

84 © PTV AG


Table 21: Example for a 0..n relation with aggregate function Sum

• Avg and AvgActiveDetermine the mean of the values of all associated network objects for the selectedattribute. Table 22 displays the average number of boarding passengers at all stop pointsof the stop area.

Selection of the indirect attribute Sum:Stop points\Passengers boarding(AP) in the attribute selection window


Selection of the indirect attribute Avg:Stop points\Passengers boarding(AP) in the attribute selection window


Table 22: Example for a 0..n relation with aggregate function Avg

85 © PTV AG


• Concatenate and ConcatenateActiveString all values of the associated network objects together for the selected attribute.Table 23 displays the number of boarding passengers at each stop point of the stop area.At the stop points of stop area 2012 for example, 545 and 1046 passengers board each.

• Histogram and HistogramActiveContrary to the aggregate function Concatenate, each occurring value is issued only oncealong with the frequency of its occurrence. This display offers more clarity especially if theuser wants to see which values occur at all and how many times. Table 24 illustrates thedifference between the Concatenate and the Histogram display. Here, for each line, thenumber of stop points of the associated line routes is displayed. For example, 13 line routesare allocated to line S4. Two of the line routes have 10 stop points, 4 line routes have 20stop points, and 7 line routes have 21 stop points.

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


Table 23: Example for a 0..n relation with aggregate function Concatenate

86 © PTV AG


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

2.3.3 User-defined attributes For all network object types it is possible – as for databases or GIS - to define UDAs in additionto the input and output attributes predefined in VISUM. User-defined attributes can be editedand stored just like predefined VISUM attributes.The following data can thus be included in the model.• Structural data of traffic zones (such as the number of households or the number of

workplaces), which serve as input data for demand modeling.

Selection of the indirect attribute Histogram:Line routes\Number stop points in the attribute selection window

Display of indirect attributes in the table right next to the attributes of the line

Table 24: Example for a 0..n relation with aggregate function Histogram

87 © PTV AG


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

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

88 © PTV AG


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

• Different categories of line services• User-defined attributes for storing calculation results from Multi-Edit operations (see User

Manual, Chpt. 2.8, page 153). Table 25 shows an example in which the line costs perkilometer of the link length are calculated with the aid of a formula and the result is savedin the user-defined attribute Cost_per_Km.

Each user-defined attribute has a data type. The following data types can be selected.• Bool (for example for a user-defined attribute "in scenario active", which can only be 0 or 1)

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

001 13,012.86 22.94 567.06

002 22,797.80 36.02 632.83

003 13,390.06 14.60 916.71

004 10,428.43 19.99 521.58

005 10,109.21 17.87 565.65

006 6,833.93 23.03 296.65

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

89 © PTV AG


• File (for example for a user-defined attribute at count locations which specifies which filecontains further information on the count location)

• Integer• Number with decimal places• Kilometers• Meters• Long text• Text• Time period• Time (for example 06:32:45)

2.3.4 Time-varying attributesIn the procedures DUE (see "Dynamic User Equilibrium (DUE)" on page 367), dynamicstochastic assignment (see "Dynamic stochastic assignment" on page 396) and Metropolis(see "NCHRP 255" on page 402), time-varying traffic supply can be modeled. In VISUM, time-varying attributes are used for this purpose. Time-varying attributes only affect these threeassignment procedures.Otherwise time-varying attributes override the valid value of an attribute with a deviating valuefor a certain amount of time. They can thus model, for example the impact of tidal flow laneallocation or transient road works.Time-dependant attributes can be assigned to the following network objects.• Links• Turns• Main turns• Nodes• Main nodesFor these network objects, only specific attributes can be time-varying, and the deviating valueof the attributes is not relevant to all procedures. Table 26 gives an overview of whichattributes can be time-varying in which assignment procedures. For details, please refer to thedescription of the Dynamic Stochastic assignment (see "Dynamic stochastic assignment" onpage 396) and DUE (see "Dynamic User Equilibrium (DUE)" on page 367).

Network object Time-varying attribute Dynamic Stochastic Assignment

DUE

Links Out capacity PrT X

Capacity PrT X X

Toll-PrTSys X

v0 PrT X X

TSysSet X

AddValue 1...3

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

90 © PTV AG


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

AddValue-TSys

Turns Capacity PrT X X

ICA final capacity

t0 PrT X

TSysSet X

AddValue 1...3

Main turns Capacity PrT X X

t0 PrT X

TSysSet X

AddValue 1...3

Nodes Capacity PrT X

t0 PrT X

AddValue 1...3

Main nodes Capacity PrT X

t0 PrT X

AddValue 1...3

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

91 © PTV AG


The links 11 - 41 and 41 - 40 are charged with the full capacity of 800.

With the aid of a time-varying attribute for the capacity PrT on the two links (11-41 and 41-40), both links are charged with a reduced capacity of 100. Therefore, the volumes of the links are lower.

Table 27: Impact of time-varying attributes in the Dynamic Stochastic assignment

92 © PTV AG

Chapter 2.4:Subnetwork generator

2.4 Subnetwork generatorWith the Subnetwork generator add-on module, a subnetwork together with the associatedpartial matrices can be generated from the overall network in such a way that, generallyspeaking, comparable assignment results are obtained for the subnetwork.The subnetwork is generated on the basis of the following rules:• The basis are all active links and all active line routes.• Apart from that, the following network objects are transferred to the subnetwork:

• All From nodes and To nodes of the active links.• All junction editor / junction control data for the nodes, including all legs located within

the subnetwork• Turns whose From link and To link belong to the subnetwork• All connectors at a node located in the subnetwork• All zones with connectors at a node located in the subnetwork• All count locations located on active links• All active POIs and, if applicable within the subnetwork; all references to nodes, links,

POIs, stop points and stop areas are copied• All screenlines• All existing toll systems with at least one active link.• All active territories• All main nodes if all associated partial nodes are active, and all associated main turns• All stops that have at least one stop point on an active line route or a stop area within

the active area are transferred in full (inclusive of all stop points and stop areas).Moreover, nodes (of the stop areas or stop points) referenced by the stop and, whereapplicable, connectors and zones connected to them are transferred.

• All active line routes, cut off if necessary• All stop points and links of cut-to-length line routes• All lines that have at least one active line route• All main lines with at least one line included in the generated subnetwork• All line route items of the active line routes• All time profiles and time profile items of the active line routes• All vehicle journeys, vehicle journey sections and vehicle journey items of the active line

routes• All coordination groups which are with their time profiles and extension completely

within the subnet.• All turn standards and block item types

In addition, the following network objects are transferred from the entire network to thesubnetwork.• Demand segments• Modes• Transport systems• Link types

93 © PTV AG


• Main zones• Calendar periods• Valid days• Fare zones• Ticket types• Directions• Operators• Vehicle combinations• Vehicle units• Surfaces• Demand matrices *• Time series *• Demand time series *• Activities, activity pairs, activity chains *• Person groups, structural properties *• Demand strata *• Skim matrices *• Procedure parameters ** when activating option Include the demand model in the subnetworkThe subnetwork generator considers the paths of an existing assignment and generates newzones at the network’s interfaces at which traffic flows enter or leave the network. Thesevirtual boundary zones (subnetwork cordon zones) are added to the partial matrices of thedemand 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 atwhich active and passive links meet, meaning at which at least one link is not included inthe subnetwork. A subnetwork cordon zone is generated for each generated connector.VISUM can then supplement the demand matrix using the paths. This requires performingan assignment.

• PuT demand matrixBoundary stop points are the first and last stop points of the active line routes and all stoppoints at which transfer events to passive line routes take place. Generated connectors arecreated at each stop area of a boundary stop point. A subnetwork cordon zone is generatedfor each generated connector. This requires performing an assignment. Alternatively, twokinds 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 zoneis generated each at the start and end stop point. The volume of the route is recordedas a demand between the respective zones, which means it emerges as many times inthe new matrix as there are partial routes within that route.

• On path levelFor each route a subnetwork cordon zone is generated for the first stop point of allactive line routes (start). If the route is no longer active or if a partial route is followed bya walking link which leads across a passive link, a subnetwork cordon zone is created

94 © PTV AG

Chapter 2.4:Subnetwork generator

at the last stop point of the last active partial route (end). The demand is recordedbetween the start and the end. As soon as the route is active again, a subnetworkcordon zone is firstly generated at the first stop point of the first active partial route againetc.

If all line routes of all links are active, the total of the stop point matrix equals the total of thedemand matrix.The following applies to both matrices regarding path legs and those regarding paths. If thetransport system PuTAux is used in a PuT assignment, the subnetwork generator managesroutes that contain PuTAux as follows:• If there is a passive link on a route section that uses PuTAux, a subnetwork cordon zone is

generated at the From node of this link. As soon as the next active link is found, thesubnetwork generator creates another subnetwork cordon zone at the From node of thatlink. The volume is transferred as demand data from one subnetwork cordon zone to thenext one.

• In contrast, the following applies to the transport system PuT Walk: If there is at least onepassive link within a walk link, subnetwork cordon zones are created at the last stop pointbefore the walk link and at the next stop point after the walk link and not at the nodes of thepassive link, as for PuTAux.

The example in illustration 45 illustrates the differences. The Numbering of cordon zoneswith offset option has been selected in order to clarify the connection with the nodes. Theoffset specified is 10.

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

Zone

Node

Stop point

Walk link via active links

Path leg on active line route

Zone

Node

Stop point

Walk link via active links

Path leg on active line route

Stop point matrix (regarding path legs)

Stop point matrix (regarding paths)

External zone

Stop point matrix (regarding path legs)

Stop point matrix (regarding paths)

External zone

12 13 14 15 16 17

Stop point matrix:

12 13 14 15 16 17

Stop point matrix:

12 14 15 18

Stop point matrix:

18

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

12 13 14 15 16 17 1812 5013 501415 501617 5018

12 14

12 14 15 18

Stop point matrix:

18

1 2 3 4 5 6 7 8

1 2 3 4 5 6 7 8

12 13 14 15 16 17 1812 5013 501415 501617 5018

12 14 15 1812 501415 5018

1

Walk link (via at least one passive link)

Pathleg on passive line route

12

95 © PTV AG


2.5 The surface data model in VISUMIn 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 andextent of network objects. Based on freely definable points and edges that connect thesepoints, they are defined as surfaces independent of the network and allocated to the respectivenetwork objects via the SurfaceID attribute. The surfaces are displayed in the VISUM surfacemodel (see "Tables in the surface model" on page 96).

2.5.1 Tables in the surface modelThe VISUM surface model consists of the following seven tables. In these tables, the surfacesof 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

ExampleIn the following example, the seven tables are displayed and explained for a network thatcontains three main nodes with surfaces.The network includes the three main nodes with the IDs 2, 3 and 4. These main nodes areallocated via the SurfaceID attribute to the surfaces with the Ds 866, 867 and 868 (Table 28).

In the Surfaces table, all surfaces contained in the network are stored with their IDs. Since, inthe example, only the three main nodes have a surface, there are exactly three entries for themain node surfaces in this instance (Table 29).

Note: In VISUM, it is possible to save the polygons per network object type to a network file(see User Manual, Chpt. 1.3.3, page 39).

* Table: Main nodes$MAINNODE:NO;SURFACEID2;8663;8674;868

Table 28: Table Main nodes

* Table: Surfaces$SURFACE:ID866867868

Table 29: Table Surfaces

96 © PTV AG

Chapter 2.5:The surface data model in VISUM

Each surface is composed of one or multiple faces. The allocation of surfaces to faces iscarried out in table Surface items. In the example, the surfaces 866 and 868 have exactly oneface, whereas surface 869 has two faces. There are thus four faces in total with the IDs 1139,1141, 1144 and 1145 (Table 30).

In the Faces table, all faces contained in the network are stored with their IDs. In this example,there are thus four faces (Table 31).

In the Face items table, each face is allocated the IDs of the edges which define the face. Asyou can see in Table 32, the faces with the IDs 1141, 1144 and 1145 are squares each, as theyare defined by four edges. Face 1139 however, is a pentagon with five edges.

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

* Table: Surface items$SURFACEITEM:SURFACEID;FACEID;ENCLAVE866;1139;0868;1141;0869;1144;0869;1145;0

Table 30: Table Surface items

* Table: Faces$FACE:ID1139114111441145

Table 31: Table Faces

* Table: Face items$FACEITEM:FACEID;INDEX;EDGEID;DIRECTION1139;1;33136;01139;2;33137;01139;3;33138;01139;4;33139;01139;5;33140;0

1141;1;33145;01141;2;33146;01141;3;33147;01141;4;33148;0

1144;1;33160;01144;2;33161;01144;3;33162;01144;4;33163;0

1145;1;33164;01145;2;33165;01145;3;33166;01145;4;33167;0

Table 32: Table Face items

97 © PTV AG


In the Points table, all points are displayed which in turn define the edges. Each one containsinformation on the coordinates (XCoord and YCoord). This establishes the spatial reference ofthe surface to the network (Table 34).

No intermediate points were generated in the example. The table is therefore empty(Table 35).

2.5.2 Multi-part surfacesA surface can be made up of several faces (multi-part surfaces). Generally, a multi-part surfaceis defined by a set of so-called faces. Each face is a polygon with a sign. This is positive, ifcoordinates encircle the polygon anti-clockwise and negative, if the coordinate sequence is

* Table: Edges$EDGE:ID;FROMPOINTID;TOPOINTID33136;9449;945033137;9450;945133138;9451;945233139;9452;945333140;9453;944933145;9458;945933146;9459;946033147;9460;946133148;9461;945833160;9473;947433161;9474;947533162;9475;947633163;9476;947333164;9477;947833165;9478;947933166;9479;948033167;9480;9477

Table 33: Table Edges

* Table: Points$POINT:ID;XCOORD;YCOORD9449;3456991.5413;5430055.02049450;3456991.5413;5430004.38859451;3457052.3873;5429991.76999452;3457070.0872;5430048.95429453;3457026.8560;5430057.99889458;3458808.0227;5431086.80279459;3458821.3171;5431061.42259460;3458848.5102;5431078.94699461;3458835.5180;5431101.91009473;3456956.4483;5430005.52969474;3456948.8422;5430060.37359475;3456887.1928;5430052.76749476;3456903.2057;5429996.72259477;3456896.8005;5430097.60339478;3456938.0336;5430071.18219479;3456961.6525;5430097.60339480;3456945.2393;5430125.2254

Table 34: Table Points

* Table: Intermediate points$EDGEITEM:EDGEID;INDEX;XCOORD;YCOORD

Table 35: Table Intermediate points

98 © PTV AG


clockwise. Positive faces are thus digitalized anticlockwise, negative faces clockwise. Thisway, the type of polygon is clearly defined when interactively modifying polygons in the networkdisplay. This orientation of a face is thus a significant object feature. Positive faces add to thesurface, negative surfaces subtract from it (holes).

Illustration 46: Positive and negative surfaces

VISUM automatically normalizes the definition of any surface it encounters. Faces neverintersect 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 complexsurfaces requires the use of a normalized representation. Table 36 shows some examples forthe normalization of surfaces.

Specified surface Normalized shape of the surface

1

Two separate faces OK – the surface remains unchanged

2

Two overlapping faces not OK – both faces have been merged

Table 36: Examples for the normalization of surfaces

anti-clockwise = positive

clockwise = negative

anti-clockwise= positive

99 © PTV AG


A surface is thus "normalized“ if the following conditions are met.• None of the faces of the same orientation overlap. This means

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

• none of the faces have intersecting boundaries (criterion 2).The simple example of the area calculation suffices to understand why a normalizedrepresentation facilitates geometrical operations. The area of normalized surfaces resultsdirectly 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 besubtracted from the result. This would imply a significant increase in computation time.Computation time particularly increases because the mere determination of the intersection ofsets with multiple overlaps is a complex algorithmic procedure.

3

A face with a hole OK – the surface remains unchanged

4

A face with a hole which intersects the boundary of the surface

not OK – the hole is omitted and the face adjusted

5

A face with an intersecting boundary not OK – the negative part is deleted

Specified surface Normalized shape of the surface

Table 36: Examples for the normalization of surfaces

100 © PTV AG


When does the program normalize?Since normalized surfaces are required for efficient processing of polygons in variousgeometrical operations, VISUM needs to check and restore this property by transforming theinput data (where applicable) when loading surfaces from network files or when interactivelyediting the shapes of polygons.All of the examples above show surfaces that can be inserted interactively just as they aredisplayed in the left column. However, when leaving the Edit shape mode, VISUMautomatically normalizes the surfaces. The same applies when reading in network files.

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

101 © PTV AG


102 © PTV AG

3 Demand model

One of the main uses of VISUM is modeling demand. Demand modeling deals with trafficconditions. 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 peopletravel.VISUM offers three demand modeling procedures.• Standard Four-Stage Model (see "Standard Four-Stage Model" on page 110)• EVA (see "EVA Model for Passenger Demand" on page 115)• VISEM (see "Activity chain based model (VISEM)" on page 144)The result of this procedure are matrices, which contain trips between the origin anddestination zones of the network. These matrices are assigned to one or more demandsegments. Assignment takes place on the basis of demand segments (see "User Model PrT"on page 195 and "User Model PuT" on page 407).It is not mandatory to create a separate demand model in VISUM, which calculates thematrices 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 anassignment) first only consists of the following elements:• the demand in form of a matrix (see "Matrices" on page 104)• temporal distribution of the demand by specifying a time series (see "Time series" on

page 105). Specifying a time series is, however, only necessary for dynamic PrTassignments and PuT assignments. The demand distribution is ignored in the case of staticPrT assignments.

• the allocation of matrices to one or more demand segments (see "Demand segments" onpage 104)

There are several demand objects(see "Demand objects" on page 103) that allow you todisplay the demand within the VISUM data model. Which of these demand objects are appliedin your model, depends on the type of demand modeling in your network.

Subjects• Demand objects• Demand modeling procedure• Displaying and Editing Matrices• Matrix correction

3.1 Demand objectsA 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 demandmatrices. The demand object types in VISUM are described below.• Matrices

103 © PTV AG

Chapter 3: Demand model

• Demand segments• Time series• Demand model structure• Population groups• Activities, Activity Pairs, Activity Chains• Demand strataIn addition, the EVA and VISEM demand models also contain the demand structural properties(see "Structural properties" on page 115 and "VISEM Data model" on page 144).

3.1.1 MatricesMatrices are one of the most important components of demand models. There are severalmatrix types: • Demand matrices are used to show the transport demand between origin and destination

zones.• Skim matrices show the origin-destination zone skims, e.g. the travel time.• Weighting matrices are only used to calculate the Weighting step of EVA-P demand

models. (see "EVA Model for Passenger Demand" on page 115)In OD matrices, the demand is coded (by the number of trips) from origin zone i to destinationzone j. The temporal distribution of travel demand within the analysis period is described by astart time and a time series that is considered during PuT assignment and dynamic PrTassignments (see "Time series" on page 105). The demand distribution is ignored in the caseof static PrT assignments.The Matrix editor integrated in VISUM allows you to process existing matrix data and performcalculations based on the gravity approach (see "Gravity model calculation" on page 157).In VISUM, OD matrices and time series are independent objects which can freely be allocatedto demand segments for assignment. This means that you can also use a matrix for more thanone demand segment.

3.1.2 Demand segmentsA 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 bepupils or commuters. The journey times from origin zones to destination zones are calculatedper demand segment (see "Demand segments" on page 24).Demand segments are different from demand strata (see "Demand strata" on page 108).Demand strata contain demand groups for the steps trip generation, trip distribution and modechoice of the Standard Four-Stage Model. Another important difference is that each demandsegment is assigned to exactly one mode (for example PrT or PuT).The demand strata of a mode are generally aggregated to create demand segments. Theseaggregated demand segments are then assigned to the network. Aggregation is possible sincethe variables used to differentiate between the demand strata have no effect on theassignment. Demand strata, for instance, are often distinguished by employment, e.g.

Note: It is not mandatory to create a separate demand model in VISUM, which calculates thematrices for the assignment. You can also use and assign matrices from external sources.

104 © PTV AG

Chapter 3.1: Demand objects

employees with a car and non-employees with a car. If the study area has no toll roads, theemployee 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 oftheir 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 onematrix (see "Matrices" on page 104). For dynamic PrT assignments and all PuT assignments,a demand time series must also be assigned to each demand segment (see "Time series" onpage 105). VISUM establishes the link between demand and transport supply.

3.1.3 Time seriesThe temporal distribution of trip demand over the evaluation period is described using a starttime and a demand time series. The demand time series is considered for PuT assignment anddynamic PrT assignment. The demand distribution is ignored in the case of static PrTassignments (see "Temporal Distribution of Travel Demand" on page 5 and "Time reference ofthe demand (time series)" on page 73).

There are two types of standard time series:• Time series of matrix numbers, i.e. selection of several matrices that form the time series.• proportional time series of a demand matrix

• with distribution of travel demand in time intervals (in percent)• if required modified per pair of zone type relation

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

3.1.5 Population groupsThe population living in the planning area is broken down into so-called “behavior-homogenous“ groups. The traffic behavior of the different groups should be clearly different,but within the individual groups it should be as homogenous as possible.

Notes: A possibly specified time series is ignored in the case of static PrT assignments.A matrix can also be assigned to several demand segments. The same applies to time series.

Note: A time series can also be assigned to several demand segments.

Attribute DescriptionCode (Key) Code (any string), for example EVA-PName Name of the demand model, for example EVA-P ModelType Type of calculation model (Standard 4-Stage-, EVA Passenger Demand or

VISEM Model)ModeCodes Abbreviation of the modes of the demand model

105 © PTV AG


This documentation uses examples in which the population groups are normally broken downaccording to the criteria employment/education and motorization. The following table shows adivision into groups with homogenous behavior and their codes (Schmiedel 1984).

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

When using the Standard-Four-Step Model, generally only one single person group isrequired, i.e. there is a 1:1 relation between activity chain and demand stratum.

3.1.6 Activities, Activity Pairs, Activity ChainsThe demand model is based on the assumption that trip purposes or external activities causemobility. The examples given in this manual use the activities listed in the table below. They arederived from traffic surveys, e.g. from KONTIV 89, whereby the activity of education has beendifferentiated.

The demand object activity is described by the following attributes:

Employees with car available E+c

Employees without car E-c

Not-employed with car available NE+c

Not-employed without car NE-c

Apprentices Appren

Students 18 yrs and older Stud

Pupils from secondary school Class Pas

Primary school pupils PPup

Children under six Child

Attribute DescriptionCode (Key) Code (any string), for example StudName Name of person group, for example studentsDemandModelCode Abbreviation of the demand model the person group belongs to (any string), e.g.

DEFAULT

Work A

Shopping E

Education: vocational school B

Education: university U

Education: secondary school. Class S

Education: primary school P

Recreation F

Home H

Attribute DescriptionCode (Key) Code (any string), for example W

106 © PTV AG

Chapter 3.1: Demand objects

An activity pair corresponds to the trip between two successive activities in the daily routine ofa person.The demand object activity pair is described by the following attributes:

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

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

Name Name of the activity, for example housingIsHomeActivity This Boolean attribute is true (= 1) if the activity is the starting point and end point

of an activity chain. This is typically the case for the activity “Home“.DemandModelCode Abbreviation of the demand model the activity belongs to (any string), e.g. EVA-

P.

Note: Activities are optional and can be defined interactively only for EVA and VISEM models.In case of Standard-Four-Step models one activity corresponds to exactly one activity pair.

Attribute DescriptionCode (Key) Code (any string), for example HWName Name of the activity pair, for example home - workDemandModelCode Abbreviation of the demand model the person group belongs to (any string), for

example DEFAULT.

Attribute DescriptionOrigActivityCode Code of the activity where the trip starts, for example H (home)DestActivityCode Code of the activity where the trip ends, for example W (work)OD type Direction of the activity pair in terms of the home activity

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

Attribute DescriptionCode (Key) Code (any string), for example HWHName Name of the activity chain, for example home – work – homeActivityCodes Comma-separated list of activity codes

Attribute Description

107 © PTV AG


In the VISEM demand model, the average mobility program of persons is described by activitychains. The Standard-Four-Step Model and the EVA Model allow single-element activitychains only. So an activity chain corresponds directly, i.e. 1:1, to the activity pair.

3.1.7 Demand strataThe demand stratum constitutes the basic demand object for calculating Trip generation, Tripdistribution and Mode choice. It links an activity chain with one or several person groups (inVISEM with exactly one person group). The pointers to activity chains and person groups in theStandard four-stage model are optional.The correlations between demand objects can be depicted graphically as follows (see"Correlations between different demand objects" on page 108).

Illustration 47: Correlations between different demand objects

The demand object demand stratum has the following attributes.

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


Attribute DescriptionCode (Key) Code (any string), for example HWH StudActChainCode Activity chain code (optional)DemandGroupCodes Person group codes (optional)Name Name of demand stratum, for example student-shopping or

employee+car home-shopping-homeDemandModelCode Abbreviation of the demand model, for the respective demand

stratum, for example DEFAULT

Activity Paire.g. HW

Activity Chaine.g. HW-WH

m

Demand Stratume.g. HW-WH x E+c

Standard-4-Step Modeland EVA Model:

1 : 1 (=Activity Pair)

Person Groupe.g. E+c

Person group orHousehold group

1

n

n

m

Activitye.g. Work

OrigActivity DestActivity

n

11

n n

108 © PTV AG

Chapter 3.2: Demand modeling procedure

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

3.2 Demand modeling procedureInformation on the demand within the planning area is required for the analysis oftransportation networks. Demand matrices can be determined partially through surveys. Thatis why mathematical models are used to reproduce real demand ratios, which calculate thetraffic flows between the zones of the planning area on the basis of the structure and behaviordata, the spatial utilization structure and the transport system. Another function of such amodel is the provision of prognoses and scenarios.VISUM currently offers three procedures for demand modeling.• Standard Four-Stage Model• EVA Model for Passenger Demand• Activity chain based model (VISEM)

DistribMatrixNumber Number of demand matrix to which the result of the distribution for this demand stratum is stored (optional)

DemandTimeSeriesNumber Number of demand time series for temporal distribution of demand (optional).

Attribute DescriptionOrigin Structural Property Codes Origin of the structural property codesDestination 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 originMarginal totals type destination

Type of marginal totals of the constraint on origin or destination side

Marginal totals min factor origin constantConstraints max factor origin constantConstraints min factor destination constantMarginal 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-dependant (=0).

Constraints min factor originConstraints max factor originConstraints min factor destinationConstraints max factor destination

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


109 © PTV AG


There are also the following functions available to calculate the transportation demand:• Estimate gravitation parameters (KALIBRI)• Gravity model calculation• Modal Split (standardized assessment)• Iteration

3.2.1 Standard Four-Stage Model The first three stages of the Four-Stage Model, Trip generation, Trip distribution and Modechoice, are usually carried out sequentially in the Standard Four-Stage Model successively. Asillustration 48 shows, skim matrices resulting from assignment are incorporated into the modelstages of Trip distribution and Mode choice. Due to this cyclical dependence the processcovering all four stages (including Assignment) is repeated until the result fulfils the stopcriterion, which usually is the stability of the demand matrices or the impedances in thenetwork. You can call the procedure run manually or use the Go to the Operation .(see "Go tothe operation" on page 169)

Illustration 48: Integrated four-stage demand model in VISUM

Per demand stratum

Trip generation

Trip distribution

Mode choice

production rates

zone attributes

(inhabitants,jobs)

skim matrix

utility function

utility function

skim matrix per mode

demand matrix

demand matrix

demand matrix

demand matrix

demand matrix

Assignment Assignment Assignment

production & attraction(per zone)

Per demand segment

110 © PTV AG


Moreover, the convergence speed can be improved by averaging matrices or impedancesafter the assignment by means of several iterations before using them for the next iteration ofthe demand model. This can be done with the operations Method of Successive Averages overmatrices and Method of Successive Averages over attributes (see "Method of SuccessiveAverages over matrices" on page 169 and "Method of Successive Averages over attributes" onpage 169).As variant of the classical four-stage model Mode choice can be calculated in several stepsinstead of one step (Nested Logit). You can optionally add a departure time after mode choice.The illustration 49 shows as an example the procedure in an extended demand model.

Illustration 49: Extended four-stage model

In the normal case carry out each of the operations Trip generation, Trip distribution and Modechoice for all demand strata of the model. For special purposes, however, they can also becarried 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, forexample in order to prepare skim matrices (e.g. setting the values on the matrix diagonal) or toadd externally predetermined demand data (e.g. through-traffic) (see "Displaying and EditingMatrices" on page 170).

3.2.1.1 Trip generationIn that stage for each zone and each demand stratum the origin and destination volumes arecalculated. These parameters are also called productions and attractions. The productionseither correspond directly to the actual origin traffic of the zone, this means, the number of tripsstarting there, or it merely reflects the attractiveness of the zone for the demand stratum andtherefore influences the probability that in the following Trip distribution trips will start in thatzone. Which of the two cases applies can be determined by a procedure parameter of Tripdistribution. The same holds for destination traffic.The productions of a demand stratum in a zone depend on its structural or demographicalindicators 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 caravailability can be used. For the production activity “Work” the number of jobs may be

111 © PTV AG


appropriate, perhaps broken down into different sectors. For such skims user-defined zoneattributes are the best. First, production Qi of zone i is calculated with the help of a formula,

whereby SGg is summed up across all structural properties. SGg(i) corresponds to the value ofSGg in zone i. The coefficient αg is a production rate that shows the number of trips perstructural property unit. They specify the production rates per demand stratum and zoneattribute 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.

If equality has not already been the outcome of the attributes and production rates used, it canbe set by means of a procedure parameter whether all productions and attractions have to bescaled so that their totals are equal. As reference values you can predetermine totalproductions, 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 networkmodel covers both the actual planning area and its surrounding subnetwork cordon zones. Ifyou only want to calculate planning area-internal trips by means of the demand model, first ofall define a filter for the zones of the planning area only. Proceed in a similar way if theproduction rates are not uniform for all zones. Break the zones down into groups ofhomogeneous production rates and insert the operation Trip generation for each of the groupsinto the process. Prior to each such operation set a filter for the zones of that group (operationRead filter (see User Manual, Chpt. 2.5.5.2, page 137)) and calculate Trip generation only forthe respective active zones.For each zone the results of trip generation are stored per demand stratum in the zoneattributes productions and attractions.

3.2.1.2 Trip distributionThe productions and attractions calculated in the operation trip generation only determine theconstraints of the total demand matrix of a demand stratum. The elements of the matrixthemselves are calculated in the operation trip distribution. On the one hand, the allocation ofa certain destination zone to a given origin zone is based on its attractiveness for the demandstratum (measured by its destination demand = attractions), on the other hand the impedanceof the trip from origin to destination zone is vital (measured by the skim matrices for journeytime, fares and other elements of generalized costs).These input data being available, a gravity model is formulated and solved (see "Gravity modelcalculation" on page 157).

( )∑=g

igSGgiQ α

∑ ∑=i j

jZiQ

112 © PTV AG


3.2.1.3 Mode choiceThe operation Mode choice breaks down the total demand (total demand matrix) into theindividual transport modes per demand stratum (for example PrT, PuT) based on mode-specific impedance skims (for journey time, costs, etc.).First of all for each mode m the utility is calculated as a linear combination of the impedanceparameters.

The following applies:

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

whereby Tij is the total number of trips of the demand stratum in the relation i-j, Tijm is thenumber 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 segmentNo mode choice will be calculated for demand strata referring directly to a matrix with demandsegment(s).For demand strata whose demand matrix is not related to any demand segment it isdetermined per mode to which demand matrix the demand allocated to that mode has to beadded in mode choice.

Notes: • Origin and destination traffic of the individual zones have to be available per demand

stratum as zone attributes productions and attractions.• To each demand stratum for which Trip distribution is to be calculated a demand matrix

has to be allocated into which the results are stored.• The parameters for the gravity model can be estimated beforehand (see "Estimate

gravitation parameters (KALIBRI)" on page 156).

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

∑=g

ijmgcgijmU β

ijTijmpijmTk

Uce

Uce

ijmpijk

ijm

=

⋅

⋅=

∑

113 © PTV AG


3.2.1.4 Nested Mode ChoiceFor nested mode choice, the total demand (total demand matrix) per demand stratum isdistributed to the transport modes defined in the network (for example car PrT, bus PuT), usingmode-specific skims of several stages (illustration 50).

Illustration 50: Modeling through decision tree

For the Logit model (mode choice), the decision model determines the utility of a leaf node asusual 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 - alsofor each nest node.For each leaf node or nest node, the calculated result can be saved to an existing skim matrixfor further analyses (Ortúzar 2001, pages 228-235).

3.2.1.5 Time-of-day choiceBy trip distribution or mode choice, demand matrices can be calculated which are used bydemand segments for assignments (see "Trip distribution" on page 112 and "Mode choice" onpage 113). In addition to the demand matrix further entries may be required for an assignment.A demand segment can refer to a time series for an analysis time interval dependentassignment.

114 © PTV AG


With operation Time-of-Day Choice, a demand matrix of a demand segment can be spreadover the time intervals of a standard time series. This standard time series can then be usedas demand time series in PuT assignments or in the dynamic PrT assignments.

3.2.2 EVA Model for Passenger DemandThe EVA Model developed by Lohse at Dresden Technical University constitutes an alternativeapproach to the first three stages of the classical traffic planning model (Lohse 1997). Themodel differs from the above-described Standard-4-Step Model (see "Standard Four-StageModel" on page 110) by the following features.• If trip generation and trip distribution are calculated independently, i.e. one after the other

and above all separately for each activity pair as in the Standard-4-Step Model, it oftenhappens that differences occur between the origin and destination traffic of the zones. TheEVA model links generation and distribution by an explicit constraints step to make up forthe differences.

• In the EVA Model trip distribution and mode choice are performed simultaneously, i.e. byapplying a one-stage discrete choice model to three-dimensional utility matrices indexedaccording to origin zone, destination zone and mode.

3.2.2.1 EVA Data modelThe data model for EVA also comprises the relevant demand object types (see "Demandobjects" on page 103) for other models such as the additional demand object types structuralproperty. Compared to the standard-4-stage model, these demand objects have someadditional attributes in the EVA model. These attributes have an effect on EVA tripgeneration(see "EVA trip generation" on page 118).

Activities and Activity pairsIn the EVA Model activities and activity pairs have the following additional attributes.

Structural propertiesStructural properties are used to measure the zone attractiveness as origin or destination of ajourney, they e.g. include sales floor areas or the number of school places. Structuralproperties 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 structuralproperties, they better reflect their role in the demand model.

Type of demand object

Attribute and range of values

Meaning

Activity IsHomeActivitybool (0,1)

The value of 1 specifies the activity representing the road user’s 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 activity2 = Destination activity is home activity3 = neither origin nor destination activity are home activity

115 © PTV AG


To each structural property SP defined in the demand model the numerical zone attributeValueStructuralProp(SP) in which the values of the structural property per zone can be filedis created automatically.

Demand strataDemand strata, too, have several additional properties, particularly in connection with theirconstraints. 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 andtherefore is referred to frequently, it is called the origin-destination type of the demand stratumitself below.

Attribute Meaning and range of values

Origin Structural Property Codes

Parameters specifying the structural potential of the demand stratum on the origin side.Range: set of structural properties

Destination Structural Property Codes

As above for destination sideRange: 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 sideRange: {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)

116 © PTV AG


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

Constraints max factor origin constant(CF OMax constant on the user interface)

As above for the upper limit on origin sideRange: bool (0, 1)

Constraints min factor destination constant(CF OMin constant on the user interface)

As above for the lower limit on destination sideRange: bool (0, 1)

Constraints max factor destination constant(CF DMax. constant on the user interface)

As above for the upper limit on destination sideRange: bool (0, 1)

Constraints min factor origin(CF OMin Constant on the user interface)

Factor for the lower limit of the productions if ConstraintMinFactorOrigConstant = 1This 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 constant on the user interface)

As above for the upper limit on origin sideRange: floating point number ≥ 0

Constraints min factor destination(CF DMin on the user interface)

As above for the lower limit on destination sideRange: floating point number ≥ 0

Constraints max factor destination(CF DMax on the user interface)

As above for the upper limit on destination sideRange: floating point number ≥ 0

Attribute Subattribute Meaning and range of values

Balance factor Productions

Demand stratum Weighting of demand stratum productionsThis value can be included in and recalculated during trip distribution.

Balance factor Attractions

Demand stratum Weighting of demand stratum attractionsThis 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 = 0This attribute can only be edited if the factor has not been determined by the selected type of constraint.Range: floating point number ≥ 0

Attribute Meaning and range of values

117 © PTV AG


3.2.2.2 EVA trip generationIn the EVA model and Standard-four-stage model, productions and attractions are calculatedsimilarly, namely based on demographic (number of inhabitants) and structural (jobs, size ofretail sales floor, ….) parameters as well as on mobility rates (taken from statistical surveys ontraffic behavior). It is performed separately for each demand stratum, which means for eachactivity pair and its major person groups.In EVA Trip generation productions and attractions normally refer to a closed time interval withregard to traffic (generally the average working day). The following model stages, EVAWeighting and EVA Trip distribution and Mode choice, too, refer to the overall period. The

Constraints max factor origin

Demand stratum As above for the upper limit on origin sideRange: floating point number ≥ 0

Constraints min factor destination

Demand stratum As above for the lower limit on destination sideRange: floating point number ≥ 0

Constraints max factor destination

Demand stratum As above for the upper limit on destination sideRange: floating point number ≥ 0

Number of persons Person group Number of inhabitants of the person group in zoneRange: integer ≥ 0

Structural property value

Structural property

Value taken by the structural property in zoneRange: floating point number ≥ 0

Mobility rate Demand stratumPerson 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 stratumStructural 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 stratumStructural property

As above for destination sideRange: floating point number ≥ 0

Study area factor home Demand stratumPerson 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 stratumStructural 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 stratumStructural property

As above for destination sideRange: floating point number ≥ 0


118 © PTV AG


demand matrices available at the end of the model chain only can be combined with anempirically determined or standardized daily time series (illustration 51) to get the shares ofdemand for the individual times of the day. The daily time series depend on the demandstratum.

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

The following table shows the allocation of activities, activity pairs, structural properties andperson groups on demand strata. Thereby the abbreviations used stand for the following: H:Home; W: Work; C: Child care facility, B: School; D: Service; O: Shopping; P: Private/leisure;S: Miscellaneous.

From/To H A C B D E F S

H HW HC HS HF HP HR HO

A WH WO

C CH

B SH

D FH

E INH

F RH

S OH OW OO

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

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

HW P Employees

HC P Young children

HS P Pupils, apprentices, students

HF P Employees

HP P Inhabitants

119 © PTV AG


Thus, for the demand strata HW and WH only the Employees person group (which could bebroken down into further subgroups) is relevant, whereas for the demand strata HO and OHgenerally all person groups are relevant . The number of persons of all person groups in eachzone make up an important part of input attributes for the trip generation of a certain demandstratum. Further structural properties measure the intensity of the activities at the origin or

HR P Inhabitants

HO P Inhabitants

WO S Jobs

WH S Jobs

CH S Jobs / capacity

SH S Jobs / capacity

FH S Jobs

INH S Jobs / sales floor

RH S Jobs / capacity

OH S Other jobs

OW S Other jobs

OO S Other jobs

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

HW S Jobs

HC S Jobs / capacity

HS S Jobs / capacity

HF S Jobs

HP S Jobs / sales floor

HR S Jobs / capacity

HO S Other jobs

WO S Other jobs

WH P Employees

CH P Young children

SH P Pupils, apprentices, students

FH P Employees

INH P Inhabitants

RH P Inhabitants

OH P Inhabitants

OW S Jobs

OO S Other jobs

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

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

120 © PTV AG


destination. An example of the allocation of certain structural properties to individual demandstrata is illustrated by Table 38.The person groups specified here can be broken down into further subgroups according toother 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 andperson.

In most cases, the MRpc values are known from national surveys on traffic behavior and areassumed to be constant for all zones of the study area. If the individual zones feature differentspecific traffic demands, for example distinguishing between urban and rural areas, they canbe used, too. Then MRepc specifies the particular demand of the person group or referenceperson 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 doso empirical studies or available historical values can be referred to. Here, too, a differentiationaccording to zones is possible. The structural potential of the zone results from the value of thestructural 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 EVAModel usually serves the calculation of study area-internal traffic (incoming and outgoing trafficas 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 (ordestination) zones.Example: The origin traffic of the demand stratum of Home-Work (HW) results from the numberof persons of the person group of Employees (EP) and the mobility rate MRET,WA. In a zone Ron the edge of a study area, however, part of the employees will commute to destination zonesoutside the study area. It is not available for a later trip distribution and mode choice. In thatcase, the study area factor UR,ET,WA is below 1, conveying that only that share of trips remainswithin the study area. For a zone Z in the center, however, all trips of the demand stratum liewithin the study area. Therefore the following applies: UZ,ET,WA = 1. Study area factors do notonly depend on the zone but also on the demand stratum and the person group. It is moreprobable that employees with car (E+c) commute over great distances – and therefore todestinations outside the study area than those without car (E-c). If you differentiate these twoperson groups in the model, then would typically be UR,EoP,WA > UR,EmP,WA. And in analogyhereto would be UR,KK,WK > UR,EmP,WA, because child care facilities are rather found in theproximity of homes than jobs.As the mobility rate of a person group the production rate of a structural property, too, can havepartial impacts in the study area only. So, for example, the structural potential of the demandstratum HW is determined by the number of jobs (structural property J) and the relatedproduction rate. On the edge of the study area part of the jobs are taken by employees livingoutside the study area. Therefore, these jobs are not available as potential destinations of HW

.pcMRpgrouppersonofpersonsofNumber

pgroupofpersonsbyDStrintripsofNumber=

121 © PTV AG


trips of the study area. Therefore, in that case, too, the total structural potential is multiplied bya study area factor VR,B,WA < 1.

In the trip generation stage (Table 39, Table 40 and Table 41) from the structural data andvalues mentioned for all demand strata c, the productions Qic and attractions Zjc or the upper

limits Qicmax and Zjc

max of these demands are calculated.

The approach depends on the origin-destination type of the activity pair of the demand stratum.It specifies whether the activity pair affects the home activity of the road user as origin ordestination. 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 activityThe calculation specifications can be taken from Table 39, Table 40 and Table 41. For thetypes 1 and 2 calculation starts with the home trips (of number of persons, mobility rate, studyarea factor) which independently from the travel direction always occur in the origin zone. Fortype 1 the number of trips corresponds exactly to the production, for type 2 to the attraction ofthe respective zone. For type 1 the total production (of all zones) is distributed onto thedestination zones, in proportion to their potentials (taken from structural properties, productionrates and study area factors). Type 2 is treated equally. The total attraction is distributedproportionally to the potentials onto the origin zones. For type 3 total volume is equallycalculated on the basis of the total home trips. However, the sizes of the road users’ originzones 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 theone 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 thetrips calculated in the model.Example: if the number of employed inhabitants and jobs per zone is known, hardconstraints will be applicable to the demand stratum Home – Work (HW), since everyemployed person necessarily has to commute to work and each job has to be destinationof commutation.

• Weak constraintsTraffic demand does not only depend on the spatial structure but also on the convenienceof the location and the resulting “competitive conditions“. In these cases traffic demandsresulting from trip generation are like upper limits. With Trip distribution and Mode choice itturns 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 productionrate for example. It is conceivable that there may be overabundance of sales floor so thatthe shopping facilities are not used to their full potential. Therefore, the attraction calculatedby trip generation from the potential only constitutes an upper limit for real destinationtraffic. Therefore, the constraint is hard on the destination side, whereas weak on the originside, because each road user has to shop (somewhere).

122 © PTV AG


• Elastic constraintsElastic constraints are a generalization of weak constraints. Additionally to upper limitslower limits are equally known, for the demand stratum Home - Shopping (HP), forexample, from sales statistics. In this case, the structural potential of the sales floordetermines an interval for the attraction of the respective zone.

• Open constraintsThe potential of the structural properties merely represents the attractiveness of the zoneas an origin or destination of a demand stratum. Production or attraction, however, are notlinked to any constraint.The attractiveness of some destinations in recreational traffic can even be measured bymeans of their attributes if capacity impacts do not play a role. For example, the structuralpotential of a nearby recreational area can be determined by its forest. During tripdistribution this attractiveness is to impact as potential of the destination zone, but noconstraints are linked herewith because there is neither a minimum number of personsseeking recreation nor do visitors go to other places, because the "capacity" of the forest isfully exhausted.

In Table 39, Table 40 and Table 41 the calculation formulas are listed up separately for thecases for which they differ.

Step 1 Home trips H

Step 2 Production Q, Qmax

Step 3 Total volume V

Table 39: Trip generation in EVA model: OD type 1

∑∈

⋅⋅=⋅⋅=

Ppepcepepcec

epcepepcepcuBPMRH

uBPMRH

HQ icic =

∑ ∑

∑

= ∈⋅⋅

==

n

1 SsscvsSGscER

cVcf

m

1iic=cV Q

llll

123 © PTV AG


Step 4 Attraction Z, Zmax

Step 1 Home trips H

Step 2 Attraction Z, Zmax





∑

∑

∑

∑

∈⋅⋅=

≤≤∈

⋅⋅=

∈⋅⋅=≤

∈⋅⋅⋅=

SsjscvjsSGjscERpot

jc )d

jcjcjcjcjc;Ss

jscvjsSGmaxjscERjc)c

SsjscvjsSGmax

jscERmaxjcjc )b

SsjscvjsSGjscERcfjc )a

Z

ZZZZZZ

ZZ

Z

∑∈

⋅⋅=⋅⋅=

Ppepcepepcec

epcepepcepcuBPMRH

uBPMRH

HZ jcjc =

∑ ∑

∑

= ∈⋅⋅

=

=

m

1 SsscvsSGscER

cVcf

n

1jjc=cV Z

llll

∑

∑

∑

∑

∈⋅⋅=

≤≤∈

⋅⋅=

∈⋅⋅=≤

∈⋅⋅⋅=

SsiscvisSGiscERpot

ic)d

icicicicic;

SsiscvisSGmax

iscERic

)c

SsiscvisSGmax

iscERmaxicic )b

SsiscvisSGiscERcfic )a

Q

QQQQQQ

QQ

Q

124 © PTV AG


Step 1 Home trips H



Attraction Z, Zmax


e Index of a zone producing trips (origin zone)

i Index of a zone being origin of trips

j Index of a zone being destination of trips

s Index of a structural property

p Index of a person group

c Index of a demand stratum

m Number of zones in study area

MRepc Mobility rate of person group p per time interval

ERisc Production rate of structural property s per time interval

BPep Number of persons per person group p

SG Structural property

uepc Factor of trips realized study area-internally

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)

∑∈

⋅⋅=⋅⋅=

Ppepcepepcec

epcepepcepcuBPMRH

uBPMRH

∑=

m

1eec=cV H

cV

SsscvsSGscER

SsiscvisSGiscER

icQ ⋅

∈⋅⋅

∈⋅⋅

=∑ ∑

∑

llll

cV

SsscvsSGscER

SsjscvjsSGjscER

jcZ ⋅

∈⋅⋅

∈⋅⋅

=∑ ∑

∑

llll

125 © PTV AG


When analyzing the passenger demand flows it turns out that certain activity chains dominatein the course of a day. So, for example, the chain of H – W - P – H occurs more often than thechain of H – P – W – H. With this, imbalances in the respective demand stratum pairs arise (forexample 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 demandstrata, this sum does generally not correspond to the total attraction. This, however, should bethe case for a period considered “closed with regard to traffic”. Hence, in the EVA model, theproduction 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 demandstrata. This procedure is called balancing (see "EVA Trip Distribution and Mode Choice" onpage 135).Balancing can either be performed after trip generation or trip distribution and mode choice. Ittakes place after Trip generation if the following two 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.Balancing after Trip generation takes place in three steps.1. Calculation of total production and total attraction for all demand strata except ca.

; 2. Calculation of the demand to be compensated of all zones i.

;

Zjc Attraction (expected value)

Qicmax Maximum possible production

Zjcmax Maximum possible attraction

Factor for upper or lower limit of production

Factor for upper or lower limit of attraction

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 for the calculation of the zones traffic volume into consideration

ΔQic*, ΔZjc

* Ancillary parameters for balancing (see below)

icQ,icQ

jcZ,jcZ

∑∑ ==j

jZi

iQV

∑≠

=

accicQ*

iQ ∑≠

=

accicZ*

iZ

}*iQ*

iZ,0max{*iQ −=Δ }*

iZ*iQ,0max{*

iZ −=Δ

126 © PTV AG


3. Correction of traffic volume in ca, whereby and are "preliminary" values takenfrom the formulas in Table 39, Table 40 and Table 41.

The following example will illustrate the method. For simplification it is limited to five demandstrata covering all origin-destination types.

The model covers 18 zones, 10 of which belong to the actual study area (type 1) and 8 zonesform a cordon around them (type 2). The zones of type 1 feature study area factors of 1.0,those of type 2 of 0.9. The relevant zone attributes are set as follows.

Activity Person group

No. Code OD type Origin Destination Origin zone

1 HW 1 Housing Work Employees

2 HO 1 Housing Miscellaneous Inhabitants

3 WH 2 Work Housing Employees

4 OH 2 Miscellaneous Housing Inhabitants

5 OO 3 Miscellaneous Miscellaneous Inhabitants

Relevant structural potential

No. Code OD type Origin zone Destination zone

1 HW 1 Like home Jobs

2 HO 1 Like home Jobs in tertiary sector and inhabitants

3 WH 2 Jobs Like home

4 OH 2 Jobs in tertiary sector and inhabitants

Like home

5 OO 3 Jobs in tertiary sector and inhabitants

Jobs in tertiary sector and inhabitants

Zone Type Inhabitants Employees Jobs Jobs tertiary

1 1 7.000 3.000 2.000 1.100

2 1 10.500 5.500 7.000 4.500

3 1 7.000 3.000 2.000 1.300

4 1 5.000 2.000 1.700 1.000

5 1 3.000 1.200 2.500 1.600

aicQ~ aicZ~

QicaQica

1 1Vca

------- ΔQl*

l∑⋅⎝ ⎠⎛ ⎞–⋅ ΔZi

*+=

ZicaZica

1 1Vca

------- ΔZl*

l∑⋅⎝ ⎠⎛ ⎞–⋅ ΔQi

*+=

127 © PTV AG


Depending on demand stratum and zone type the following mobility rates are applicable (tripsper person in relevant person group).

The production rates of the structural properties equally depend on demand stratum and zonetype.

All demand strata feature hard constraints. This results in the productions and attractions of thedemand strata displayed in the following table, from the formulas in Table 39, Table 40 andTable 41. For clarification the respective step of the calculation process is indicated on top ofeach column.• H = Home trips

6 1 2.000 900 1.600 1.000

7 1 500 200 2.000 1.200

8 1 5.000 2.000 1.000 600

9 1 7.000 3.100 2.500 1.400

10 1 5.000 2.000 1.500 1.000

11 2 3.500 1.200 1.000 600

12 2 3.000 1.100 1.000 600

13 2 2.500 1.000 1.000 600

14 2 1.500 700 500 100

15 2 1.500 600 500 100

16 2 2.000 900 1.000 600

17 2 2.000 800 500 300

18 2 2.000 800 500 300

Zone type HW HO WH OH OO

1 0.7800 0.9000 0.6200 0.9000 0.6000

2 0.8100 0.9000 0.6400 0.9000 0.6000

Demand stratum Structural property Zone type 1 Zone type 2

HW 1.00 1.00

HO Inhabitants 0.50 0.50

Jobs in tertiary sector 0.50 0.50

WH 1.00 1.00

OH Inhabitants 0.50 0.50


OO Inhabitants 0.50 0.50


Zone Type Inhabitants Employees Jobs Jobs tertiary

128 © PTV AG


• Q = Production• Z = Attraction• QP = Structural potential origin• ZP = Structural potential destination

Demand stratum HW

Home Origin Destination

Person groups or structural property

Employees

Like home Jobs

Calculation step 1 2 3 4

Zone Zone Type U Q ZP Z

1 1 2.340 2.340 2.000 1.578

2 1 4.290 4.290 7.000 5.523

3 1 2.340 2.340 2.000 1.578

4 1 1.560 1.560 1.700 1.341

5 1 936 936 2.500 1.972

6 1 702 702 1.600 1.262

7 1 156 156 2.000 1.578

8 1 1.560 1.560 1.000 789

9 1 2.418 2.418 2.500 1.972

10 1 1.560 1.560 1.500 1.183

11 2 875 875 900 710

12 2 802 802 900 710

13 2 729 729 900 710

14 2 510 510 450 355

15 2 437 437 450 355

16 2 656 656 900 710

17 2 583 583 450 355

18 2 583 583 450 355

Total 23.038 23.038 29.200 23.038

Demand stratum HO

Home Origin Destination


Inhab. Like home


Calculation step 1 2 3.1 3.2 4 5

Zone Zone Type U Q ZP Inh. ZP Jobs - tert

ZP Total Z

1 1 6.300 6.300 3.500 550 4.050 5.796

129 © PTV AG


2 1 9.450 9.450 5.250 2.250 7.500 10.733

3 1 6.300 6.300 3.500 650 4.150 5.939

4 1 4.500 4.500 2.500 500 3.000 4.293

5 1 2.700 2.700 1.500 800 2.300 3.292

6 1 1.800 1.800 1000 500 1.500 2.147

7 1 450 450 250 600 850 1.216

8 1 4.500 4.500 2.500 300 2.800 4.007

9 1 6.300 6.300 3.500 700 4.200 6.011

10 1 4.500 4.500 2.500 500 3.000 4.293

11 2 2.835 2.835 1.575 270 1.845 2.640

12 2 2.430 2.430 1.350 270 1.620 2.318

13 2 2.025 2.025 1.125 270 1.395 1.996

14 2 1.215 1.251 675 45 720 1.030

15 2 1.215 1.251 675 45 720 1.030

16 2 1.620 1.620 900 270 1.170 1.674

17 2 1.620 1.620 900 135 1.035 1.481

18 2 1.620 1.620 900 135 1.035 1.481

Total 61.380 61.380 34.100 8.790 42,890 61.380

Demand stratum WH

Home Destination Origin


Like home Jobs

Calculation step 1 2 3 4

Zone Zone Type U Z QP Q

1 1 1.860 1.860 2.000 1.253

2 1 3.410 3.410 7.000 4.384

3 1 1.860 1.860 2.000 1.253

4 1 1.240 1.240 1.700 1.065

5 1 744 744 2.500 1.566

6 1 558 558 1.600 1.002

7 1 124 124 2.000 1.253

8 1 1.240 1.240 1.000 626

9 1 1.922 1.922 2.500 1.566

10 1 1.240 1.240 1.500 939

11 2 691 691 900 564

12 2 634 634 900 564

13 2 576 576 900 564

130 © PTV AG


14 2 403 403 450 282

15 2 346 346 450 282

16 2 518 518 900 564

17 2 461 461 450 282

18 2 461 461 450 282

Total 18.288 18.288 29.200 18.288

Demand stratum OH

Home Destination

Origin


Inhab. Like home


Calculation step 1 2 3.1 3.2 4 5

Zone Zone Type U Z QP Inh. QP Jobs tert

QP Total Q

1 1 6.300 6.300 3.500 550 4.050 5.796

2 1 9.450 9.450 5.250 2.250 7.500 10.733

3 1 6.300 6.300 3.500 650 4.150 5.939

4 1 4.500 4.500 2.500 500 3.000 4.293

5 1 2.700 2.700 1.500 800 2.300 3.292

6 1 1.800 1.800 1.000 500 1.500 2.147

7 1 450 450 250 600 850 1.216

8 1 4.500 4.500 2.500 300 2.800 4.007

9 1 6.300 6.300 3.500 700 4.200 6.011

10 1 4.500 4.500 2.500 500 3.000 4.293

11 2 2.835 2.835 1.575 270 1.845 2.640

12 2 2.430 2.430 1.350 270 1.620 2.318

13 2 2.025 2.025 1.125 270 1.395 1.996

14 2 1.215 1.215 675 45 720 1.030

15 2 1.215 1.215 675 45 720 1.030

16 2 1.620 1.620 900 270 1.170 1.674

17 2 1.620 1.620 900 135 1.035 1.481

18 2 1.620 1.620 900 135 1.035 1.481

Total 61.380 61.380 34.100 8.790 42,890 61.380

Demand stratum OO

Home Origin

131 © PTV AG




Calculation step 2.1 2.2 2.3 2

Zone Zone Type U QP Inh. QP Jobs tert

QP Total Q

1 1 4.200 3.500 550 4.050 3.864

2 1 6.300 5.250 2.250 7.500 7.156

3 1 4.200 3.500 650 4.150 3.959

4 1 3.000 2.500 500 3.000 2.862

5 1 1.800 1.500 800 2.300 2.194

6 1 1.200 1.000 500 1.500 1.431

7 1 300 250 600 850 811

8 1 3.000 2.500 300 2.800 2.671

9 1 4.200 3.500 700 4.200 4.007

10 1 3.000 2.500 500 3.000 2.862

11 2 1.890 1.575 270 1.845 1.760

12 2 1.620 1.350 270 1.620 1.546

13 2 1.350 1.125 270 1.395 1.331

14 2 810 675 45 720 687

15 2 810 675 45 720 687

16 2 1.080 900 270 1.170 1.116

17 2 1.080 900 135 1.035 987

18 2 1.080 900 135 1.035 987

Total 40.920 34.100 8.790 42,890 40.920

Demand stratum OO

Destination



Calculation step 3.1 3.2 3.3 3

Zone Zone Type ZP Inh. ZP Jobs - tert ZP Total Z

1 1 3.500 550 4.050 3.864

2 1 5.250 2.250 7.500 7.156

3 1 3.500 650 4.150 3.959

4 1 2.500 500 3.000 2.862

5 1 1.500 800 2.300 2.194

6 1 1.000 500 1.500 1.431

7 1 250 600 850 811

132 © PTV AG


Since all demand strata feature hard constraints, balancing can be performed immediatelyafter trip generation. First of all the total origin and destination traffic of each zone and of thedemand strata HW, HO, WH, OW is calculated and the resulting differences are compensatedin the OO demand stratum.

8 1 2.500 300 2.800 2.671

9 1 3.500 700 4.200 4.007

10 1 2.500 500 3.000 2.862

11 2 1.575 270 1.845 1.760

12 2 1.350 270 1.620 1.546

13 2 1.125 270 1.395 1.331

14 2 675 45 720 687

15 2 675 45 720 687

16 2 900 270 1.170 1.116

17 2 900 135 1.035 987

18 2 900 135 1.035 987

Total 34.100 8.790 42,890 40.920

Note: Note that neither total origin and nor total destination traffic of this demand stratumchange.

Total HW+HO+WH+OH Differences

Zone Q Z Q Z

1 16.800 14.422 2.378 0

2 26.600 31.373 0 4.773

3 16.800 14.709 2.091 0

4 11.800 10.993 807 0

5 7.080 10.121 0 3.041

6 4.860 6.558 0 1.698

7 1.180 5.263 0 4.083

8 11.800 9.429 2.371 0

9 16.940 15.559 1.381 0

10 11.800 10.710 1.090 0

11 7.236 6.555 681 0

12 6.296 5.911 385 0

13 5.355 5.267 88 0

14 3.344 2.698 646 0

15 3.213 2.698 515 0

16 4.415 4.623 0 208

133 © PTV AG


The results of operation EVA trip generation are stored in zone attributes.

17 4.284 3.599 685 0

18 4.284 3.599 685 0

Total 164.086 164.086 13.804 13.804

OO before balancing OO after balancing

Zone Q Z Q Z

1 3.864 3.864 2.561 4.938

2 7.156 7.156 9.515 4.742

3 3.959 3.959 2.624 4.715

4 2.862 2.862 1.897 2.704

5 2.194 2.194 4.495 1.454

6 1.431 1.431 2.646 948

7 811 811 4.621 537

8 2.671 2.671 1.770 4,141

9 4.007 4.007 2.655 4.036

10 2.862 2.862 1.897 2.987

11 1.760 1.760 1.166 1.848

12 1.546 1.546 1.024 1.409

13 1.331 1.331 882 970

14 687 687 455 1.101

15 687 687 455 971

16 1.116 1.116 948 740

17 987 987 654 1.339

18 987 987 654 1.339

Total 40.920 40.920 40.920 40.920


HomeTrips Demand stratum Home trips for demand stratumRange: floating point number

ProductionsTarget Demand stratum Productions for demand stratum, before taking account of constraintsRange: floating point number

AttractionsTarget Demand stratum Same for attractionsRange: floating point number

134 © PTV AG


3.2.2.3 EVA Trip Distribution and Mode ChoiceIn gravity models, trip distribution or destination choice is made according to the bilinearapproach (for example Kirchhoff 1970), using various evaluation or utility functions Wij.

Hereby Tij is the number of trips from i to j, Wij is the cost function for the trip from i to j, Qi isthe production of zone i and Zj is the attraction of zone j. The factors fqi, fzj are calculated sothat productions and attractions are kept as marginal sums.The EVA model generalizes this approach of a simultaneous trip distribution and mode choiceto a trilinear model.

Here, index k is the mode (means of transport) and Wijk assesses the costs for the trip from i toj by mode k. For each demand stratum c there is a separate equation system to be solvedindependently. For more clarity index c has been dropped for all variables in the problemformulations above.For the trilinear case, besides origin and destination traffic, the total number VKk of trips withmode k is required. There are two possibilities.

Productions Demand stratum Productions for demand stratum after taking account of constraints and balancingNoteThis 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 attractionsRange: floating point number


n)1,...,=j m;1,...,=i( j zfiqfijWijT ⋅⋅=

jZ=m

1iijTjzfiqf

m

1=iijW

iQ=n

1jijTjzfiqf

n

1=jijW

∑∑

∑∑

==⋅⋅

==⋅⋅

p)1,...,=k n;1,...,=j m;1,...,=i( kafjzfiqfijkWijkT ⋅⋅⋅=

kVK=m

1i

n

1jijkT

m

1=i

n

1jkafjzfiqfijkW

jZ=m

1i

p

1kijkT

m

1=i

p

1kkafjzfiqfijkW

iQ=n

1j

p

1kijkT

n

1=j

p

1kkafjzfiqfijkW

∑ ∑∑ ∑

∑ ∑∑ ∑

∑ ∑∑ ∑

= ==

=⋅⋅⋅

= ==

=⋅⋅⋅

= ==

=⋅⋅⋅

135 © PTV AG


• If EVA trip distribution and mode choice for the analysis case is performed, which meanswithout having run a precalculation for the same study area, specify the modal split as inputdata.

• If, however, a forecast case is calculated, the modal split of the analysis case can be re-used. You thus assume that the modal split may change on single relations, but modal splitof the whole model (including all relations), however, remains unchanged.

The problem formulation is applicable in case of hard constraints. For weak, elastic or openconstraints equations will be replaced by inequations in the side conditions or a side conditionwill 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 informationgain minimization. Both ways lead to the same result.Minimizing the gain of information has the target that the deviations from a priori assessmentsof trip relations which would lead to the actually desired trips road users have to experience areas minor as possible, but which have become necessary due to the constraints of the system.The demand matrix T can be interpreted as the solution to the convex optimization task

with taking account of the constraints. The solution is the trilinear equation system previouslydetermined.The parameter I represents the information gained through the replacement of distribution wijk(solely determined by the weighting matrix) by distribution pijk (additionally derived frommarginal 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 calledassessment types. In the EVA model the different assessments of each assessment type aretransformed 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:

whereby

here Mijk stands for the availability of mode k on OD pairs (i,j) and Cijk stands for the capacityutilization 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-definedassessment types.

Minimumijkwijkp

ld ijk

ijkp= I →⎟⎟

⎠

⎞

⎜⎜

⎝

⎛∑

∑rsl

rslWijkW

= ijk w ; VijkT

= ijkp

Wijk Mijk Cijk Pijk⋅ ⋅=

Pijk fa' ca'ijk( ) fa'' ca''ijk( )–[ ] fa''' ca'''ijk( ) fa caijk( )a A∈∏⋅ ⋅=

136 © PTV AG


Mijk and Cijk are defined independently from the demand stratum as follows:

For demand strata of the origin-destination type 3 (which are calculated accounting for thehome zone), the assessment type External weighting matrix is used to produce a specificweighting between zones and modes. This weighting has an immediate impact on the totalproduct, since it is not part of the scaling using home zones, as in the formula for Mijk. In allother 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 thegravity model (cf. chap. 5.1.4.17) can be taken, but additionally the EVA1, EVA2, Schiller andBox-Tukey functions (see "Gravity model calculation" on page 157), too.

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 iCijk = 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 jCijk = ck(i) for all j, i.e. value of zone attribute ck set for source zone i

Type 3 without accounting for home zoneMijk = 1 for all i,j,kCijk = ck(i) • ck(j)including accounting for home zone

Cijk = ck(i) • ck(j)

whereby hn stands for the home trips of zone n, represents the product matrix from the top, but the predefined assessment type External weighting matrix is not included in the product:

EVA1

where EVA2

Schiller

Mijk

mk n( )n∑ hn Pnik Pjnk⋅ ⋅ ⋅

hnn∑----------------------------------------------------------------=

P

Pijk fa' ca'ijk( ) fa'' ca''ijk( )–[ ] fa caijk( )a A∈∏⋅=

( ) )x()x1(xf ϕ−+= )cxbexp(1a)x(

−+=ϕ

( )ab

cx1xf

−

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡⎟⎠⎞

⎜⎝⎛+=

( )a

bx1

1xf

⎟⎠⎞

⎜⎝⎛+

=

137 © PTV AG


In practice particularly the functions EVA1 and EVA2 have proved to be suitable. The EVA1functions are monotonously falling with f(w) ≤ 1 for w ≥ 0. In illustration 52 some of them havebeen illustrated. Their parameters can be interpreted geometrically.

The related elasticity functions are determined by

The elasticity function is defined as thelimit of the quotient of the relative variation of the function f and the relative variation of theimpedance w.It is obvious that the elasticity functions first take values near zero for low impedances, then fora limited range in which the “impedance sensitivity“ is at its highest take various values, but allfar from zero and for high impedances “approximate“ the limit of -E.

Logit

Kirchhoff

BoxCox

Box-Tukey

where Combined

TModel

None f(x) = x

a Parameter marking the horizontal asymptote of function ι(w), thus influencing the degree of approximation of the function f(w) to the w asymptote.

b Parameter influencing the degree of approximation to the horizontal F(w)=1 in the proximity of low assessment

c Parameter influencing the slope of the function f(w)

b/c Position of the inflection point WP=F/G of function φ(w) where the function φ(w) features the greatest rise or the highest "impedance sensitivity"

( ) ( )xcexf ⋅=

( ) cxxf =

( )⎟⎟

⎠

⎞

⎜⎜

⎝

⎛ −⋅

=b

1xcexf

b

( ) ( )αxcexf ⋅= ⎪⎩

⎪⎨⎧

=+

>⎟⎠⎞⎜

⎝⎛ −+=

0b),1xln(

0b,b/1b)1x(α

( ) ( )xcebxaxf ⋅⋅⋅=

( )axcbx

1xf⋅+

=

.)wGFexp(1)wGFexp(G)w1ln(

w11

)wGFexp(1wE)w(f ⎥

⎦

⎤⎢⎣

⎡⋅−+⋅−⋅

⋅+++

⋅⋅−+

⋅−=ε

)w(fw

dw)w(df

wh

)w(f)w(f)hw(f

0hlim)w(f ⋅=−+

→=ε

138 © PTV AG


Thus, this curve very much differs from the constant or linear elasticity functions of simplepower and exponential functions. Therefore, this type of function allows the adaptation tovarious basic weighting situations (person groups, trip purposes, means of transport etc.). Inthe range of low assessment or utility the weighting probability should be almost one, dropfurther in the clearly noticeable range of assessment and utility which is relevant for therespective 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 roadusers when choosing the destination or the means of transport (here mainly the random modelwith WP = 1 is applicable).

Illustration 52: EVA1 function in dependence of impedance w

The EVA2 function has the following parameters.

a, b ... Exponents whose product determines the asymptotic behavior for high impedance values. For b > 1 the curve is similar to that of the EVA function (1).

00,10,20,30,40,50,60,70,80,9

11,1

0 10 20 30 40 50 60 70 80 90 100110120

f(w)

f1(E=2; F=5; G=0,24) f2(E=4; F=6; G=0,08)f3(E=0,6; F=6; G=0,06) f4(E=20; F=12;G=0,08)

-30-25-20-15-10

-50

0 10 20 30 40 50 60 70 80 90 100110 120

eps(w)

139 © PTV AG


The illustration 53 shows the influence of a and b on the progression of the function. The twoother parameters are both kept constant.

Illustration 53: EVA2 function in dependence of the parameters a and b

The Schiller function is a special case of the EVA2 function, however, with one parameter less.As the first applications in practice have shown, the function can also be adapted sufficientlywell enough to observed data, too. Due to the lower number of parameters the calibration effortis by far lower than for EVA2.

c ... Scale parameter for impedance values.

applies.α2/1)c(f =

EVA2 Function (a variable)

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,00 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

Assessment x

Util

ity f(

x)

a = 0a = 1a = 2a = 3

EVA2 Function (b variable)

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

Assessment x

Util

ity f(

x)

b = 1b = 3b = 5b = 7

140 © PTV AG


Problem solution 1: The trilinear FURNESS methodThe mostly investigated method for solving bilinear problems in technical literature is namedafter K. P. Furness (Furness 1962, 1965). However, in fact, Bregman had already applied thismethod in the thirties (Bregman 1967a, 1967b). It can be generalized and transferred directlyto the trilinear case.After you have specified start values for the trilinear FURNESS method

during iteration step p (p=1,2,…), the system calculates approximations for fqi, fzj and fak asfollows.

(i = 1,…,m)

(j = 1,…,n)

(k = 1,…,K).For convergence of the method (towards the solution of the trilinear problem), the condition forunique solvability of the optimization problem is necessary and sufficient, i.e. existence of amatrix 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 (the matrix that corresponds to the random model) can be chosenas a feasible solution. For this special case A. W. Evans provided a convergence proof thatalso allows for a (however rough) estimation of the convergence rate (Evans 1970). Thepractical experience has shown that the method quickly converges in most application cases.

Problem solution 2: The trilinear Multi methodAnother possibility to solve the problem is to set separate fixed point equations for the vectorsfqi, fzj and fak and use them to derive rules for determining successive approximations for thesevectors (Schnabel 1997). The Multi-Procedure can also be extended to the three dimensionalcase (see "Projection" on page 173). Approximations for the solution of the trilinear problemthen can be determined according to the following iteration rule.

( ) ( ) ( ) ( )K,...,1k;n,...,1j;m,...,1i11kfa1jfz1ifq ======

( )( ) ( )∑ ∑

= =⋅⋅

=+ n

1j

K

1kpkfapjfzijkW

iQ1pifq

( )( ) ( )∑ ∑

= =⋅+⋅

=+ m

1i

K

1kpkfa1pifqijkW

jZ1pjfz

( )( ) ( )∑ ∑

= =+⋅+⋅

=+ m

1i

n

1j1pjfz1pifqijkW

kVK1pkfa

VkfajZiQ

ijkT⋅⋅

=

( ) ( )K,...,1k;n,...,1j;m,...,1iijkW1ijkT ====

141 © PTV AG


(p = 1, 2,…)with

Strictly speaking the method presented solves the problem with hard constraints only. If someconstraints are weak or elastic, there will be an optimization problem with inequations as sideconditions instead of equations. At the example of weak constraints it is illustrated how theproblem and correspondingly its solution alters (according to Schiller 2004). It is assumed thata demand stratum shows weak constraints on the destination side, which means attraction

( ) ( ) ( )( )

( )( )

( )( )

( )∑ ∑ ∑= = =

⋅⋅⋅⋅=+ m

1r

n

1s

K

1tprstT

Vpkaapka

pjzzpjz

piqqpiqpijkT1pijkT

( )( )∑ ∑

= =

= n

1s

K

1tpistT

iQpiq

( )( ) ( ) ( )[ ]

( )∑ ∑

∑ ∑

= =⋅

= =+⋅

= n

1s

K

1tpistT2

n

1s

K

1tptapszpistT

piqq

( )( )∑ ∑

= =

= m

1r

K

1tprjtT

jZpjz

( )( ) ( ) ( )[ ]

( )∑ ∑

∑ ∑

= =⋅

= =+⋅

= m

1r

K

1tprjtT2

m

1r

K

1tptaprqprjtT

pjzz

( )( )∑ ∑

= =

= m

1r

n

1sprskT

kVKpka

( )( ) ( ) ( )[ ]

( )∑ ∑

∑ ∑

= =⋅

= =+⋅

= m

1r

n

1sprskT2

m

1r

n

1spszprqprskT

pkaa

142 © PTV AG


calculated by Trip generation constitutes an upper limit. Thus, the trilinear problem changesinto

under the constraints

The procedure for multi-problem solving is mostly identical with the constraint equationmethod, except that zj(p) and zzj(p) are calculated differently.

If some demand strata do not feature hard constraints, not only has the method to be adaptedbut also balancing has to be made up.

In that case first of all the trilinear problem is solved for all demand strata except for thebalancing one. This results in the total productions and attractions of the zones covering thesedemand strata and all modes. According to the formula for calculating productions andattractions (see "EVA trip generation" on page 118), the productions and attractions of thebalancing demand stratum are modified. Finally VISUM runs trip distribution and mode choicefor this last demand stratum, too.The proceeding assumes that differences have to be balanced within the framework of the totalvolume. This is only true if all modes are exchangeable, which means if they can be usedalternatively in a closed trip chain. If at least one mode cannot be exchanged, a second phasebegins after the total balancing in which calculations are performed for each non-exchangeablemode separately and for all exchangeable modes jointly. Hereby, the productions andattractions 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 demandstratum, and based on that modified demand Trip distribution and Mode choice are calculatedfor the last time. For non-exchangeable modes this last step corresponds to a simple modechoice.

Note: Differences in marginal sums can only be balanced after trip generation if all demandstrata feature hard constraints.

kfajfzifqijkWijkT ⋅⋅⋅=

∑∑

∑∑

∑∑

=

≤

=

i jkVKijkT

i k

maxjZijkT

j kiQijkT

( ) ( ) ( ) ( )

( ) ( )

( ) ( ) ( )( )

( ) ⎪⎭

⎪⎬

⎫

⎪⎩

⎪⎨

⎧

⋅

+⋅

−=

=⎪⎭

⎪⎬

⎫

⎪⎩

⎪⎨

⎧

−=

∑∑

pjZ2i k

pkapiqpijkT

;1pjfz

1minpjzz

10jfz;pjZ

maxjZ

;1pjfz

1minpjz

143 © PTV AG


The implementation of the EVA model for trip distribution and mode choice has beenestablished in two separate operations. EVA Weighting uses skim matrices to calculate theweighting matrices Wijk (one weighting matrix each per demand stratum). During EVA tripdistribution and Mode choice, the equation systems for determining the demand matrices areset up according to the constraints of the demand strata and solved by applying one of theabove-described methods. The result of the operation is one demand matrix per demandstratum and mode. You can also display the balance factors for productions and attractions fqiand fzj, that result from the equation system. The balance factor for mode choice fak iscalculated for analysis, but not for forecast scenarios.

3.2.3 Activity chain based model (VISEM)VISEM is a disaggregated, behavior-oriented demand model which allows the planner toinclude all kinds of data relating to socio-demography and traffic policy issues. VISEMcalculates three logical work units.1. Trip generation (calculating the home trip)2. Trip distribution (determining the trip destination)3. Mode choiceThese three logical units are not processed separately in succession by VISEM, but areinterlocked. Especially steps 2 and 3, Trip distribution and Mode choice are carried outsimultaneous in a single procedure. In all three work units two important concepts have beenimplemented for VISEM: Calculation on the basis of groups with homogeneous behavior andactivity chains.

3.2.3.1 VISEM Data modelThe VISEM model is based on the assumption that external activities cause mobility. In thefollowing examples previously defined activities are already being used (see "Activities, ActivityPairs, Activity Chains" on page 106).An activity chain describes a sequence of typical activities during a person's day. An examplewould be: Home – Work – Shopping – Home (HWOH). Such a sequence of activity pairsimplies trips, in this example here three different trips: HW, WO, OH. The average mobilityprogram of persons is described by activity chains for VISEM.You can find the demand object activity chain attributes in the general description of thedemand objects (see "Activities, Activity Pairs, Activity Chains" on page 106).Some changes in the demand objects, which are especially necessary for the VISEM model,are described below.

Changes to activities in the VISEM modelEach activity from the activity chain, apart from the home activity, has to be assigned to exactlyone structural property, whose value flows in as target potential into the trip distribution.The following table shows examples for activities and respective structural properties.

Note: In a VISUM-VISEM demand model, a demand stratum is specified by exactly oneperson 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.

144 © PTV AG


You can specify whether a possible destination-binding can be considered for trip distribution,per activity. If desired, a constraint for the destination side (for example hard, weak, elastic,open) can be defined analog to the EVA demand model using two real-valued factorsConstraintMinFactorDest and ConstraintMaxFactorDest. Depending on the constraint onorigin and destination side, the double-sided coupled trip distribution is calculated for eachactivity transfer.This results in the following new attributes:

Changes to activity pairs in the VISEM modelVISEM offers a hourly calculation of the demand. This calculation requires as input,proportional time series which are defined separately per activity pair and person group. This results in the following new attribute:

Changes to person groups in the VISEM modelThe result matrix of the VISEM calculations are saved per person group. In addition to the totalresult matrix, a demand matrix is calculated per destination activity (as a result of tripdistribution) and per mode (as a result of mode choice) for each person group.This results in the following new attributes:

Activity Structural property Structural property value = target potential

Work ('W') Jobs Number of jobs

Shopping ('O') Shopping possibilities Retail sales floor

Recreation ('R') Recreational facilities Number of mentions of the zone as recreation destination in a household survey

School ('S') School places Number of school places (up to 18 years)

University ('B') University places Number of university places


Attribute and range of values Meaning

Activity StructuralPropertiesCodesRange: set of structural properties

Reference to the activity relevant structural propert(ies)

Activity CouplingDestinationRange: 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 CouplingDestination = 1. For home activity, both factors are always = 1.0.


Attribute and range of values Subattribute Meaning

Activity pairs TimeSeriesNoRange: set of standard time series (see "Time series" on page 105)

Person group Reference to a standard time series, which has to be proportional

145 © PTV AG


3.2.3.2 Tour-based Model - Trip GenerationTrip generation uses a list of group-specific activity chains, which for example, can bedetermined from the sample of the KONTIV 89 (EMNID 1991) by applying a PTV companyoptimization procedure for activity chains. For each activity chain probabilities of your dailypractice have to be specified for each person group. The following table (to calculate theprobabilities, these values must be divided by 100) contains examples of activity chainpercentages for each person group.


Attribute and range of values Subattribute Meaning

Person group DistribMatrixNumberRange: set of demand matrices

- Reference to total result matrix of trip distribution

Person group Activity matrix numberRange: set of demand matrices

Activity Reference to trip purpose-specific result matrix of trip distribution

Person group Mode choice matrix numberRange: set of demand matrices

Mode Reference to result matrix of mode choice

E+c E-c NE+c NE-c Appren Stud Pas PPup Child

HWH 74.25 62.60 8.18 2.82 33.48 11.08 1.92 0.0 0.00

HSH 0.00 0.00 0.00 0.00 47.57 0.00 0.00 0.00 0.00

HPH 17.42 25.94 60.60 62.93 12.37 23.91 12.99 9.08 0.00

HRH 27.03 25.32 52.50 39.74 38.08 37.33 40.12 38.67 0.00

HPH 0.00 0.00 0.00 0.00 0.00 0.00 0.00 74.99 0.00

HSH 0.00 0.00 0.00 0.00 0.00 45.19 0.00 0.00 0.00

HOH 0.90 1.82 0.96 0.47 0.00 0.00 80.48 0.00 0.00

HWWH 3.12 0.85 0.13 0.06 0.52 0.16 0.11 0.00 0.00

HWOH 4.67 7.05 0.96 0.33 1.79 0.80 0.37 0.00 0.00

HWRH 1.64 1.46 0.18 0.02 0.86 1.56 0.09 0.00 0.00

HWOH 0.08 0.04 0.00 0.00 0.00 0.00 0.00 0.00 0.00

HSWH 0.00 0.00 0.00 0.00 0.16 0.00 0.00 0.00 0.00

HSSH 0.00 0.00 0.00 0.00 0.11 0.00 0.00 0.00 0.00

HSPH 0.00 0.00 0.00 0.00 0.97 0.00 0.00 0.00 0.00

HSRPH 0.00 0.00 0.00 0.00 0.00 0.23 0.00 0.00 0.00

HSRRH 0.00 0.00 0.00 0.00 0.00 0.55 0.00 0.00 0.00

HSRSH 0.00 0.00 0.00 0.00 0.00 0.76 0.00 0.00 0.00

HSSOH 0.00 0.00 0.00 0.00 0.00 0.17 0.00 0.00 0.00

HSSSH 0.00 0.00 0.00 0.00 0.00 0.12 0.00 0.00 0.00

HOWWH 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

Table 42: List of the activity chains: mobility rates per person group in %

146 © PTV AG


The sum of the probabilities of a person group is often greater than 1.0 (or 100 %), because aperson 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 groupthey belong to. Trip generation, i.e. determining the absolute number of activity chains and thustrips that starting from any of the individual zones. In VISEM trip generation is calculated bymultiplying the inhabitants of each person group with the probabilities of all activity chains.This means that in VISEM trip generation (the number of trips created with each activity in theactivity chain) is determined together with the number of inhabitants and person groupdistribution. The result is saved in the zone attribute Home trips for each demand strata.

Example of trip distribution in VISEM2000 employees with a car (E+c) live in zone 1. After the activity chain distribution above, runthe activity chain HWOH per day with 4.67 % probability. This is why there are 2000 • 4.67 %= 93.4 chains of the type HWOH. Consequently, home trips for the demand stratum E+c xHWOH add up to 93.4. The 2000 persons in this activity chain produce a total of 3 • 93.4 = 280.2 trips, namely 93.4HW trips and just as many for WO and OH.

3.2.3.3 VISEM Trip distribution/Mode choice combinedFor each changeover of an activity chain, both a total demand matrix and a demand matrix permode are calculated. For each person group, the results are output in aggregated format,separated by destination activity and mode.

Trip distribution: route links through destination choice according to activitiesDepending on the destination activity of a trip, VISEM assigns it to a destination zone. Thisdestination 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, sothat the greater the run time or distance to a destination zone, the less its utility.

HOWPH 0.01 0.04 0.00 0.00 0.00 0.00 0.00 0.00 0.00

HOWRH 0.01 0.00 0.00 0.00 0.00 0.00 0.03 0.00 0.00

HOWOH 0.00 0.00 0.00 0.00 0.00 0.00 0.12 0.00 0.00

HOPPH 0.00 0.00 0.00 0.00 0.00 0.00 0.25 0.00 0.00

HOPRH 0.00 0.00 0.00 0.03 0.00 0.00 0.14 0.00 0.00

HOPOH 0.00 0.00 0.00 0.00 0.00 0.00 0.04 0.00 0.00

HPRRH 0.00 0.00 0.00 0.01 0.00 0.00 0.17 0.00 0.00

HOROH 0.00 0.00 0.00 0.00 0.00 0.00 0.11 0.00 0.00

HOOOH 0.00 0.00 0.00 0.00 0.00 0.00 0.03 0.00 0.00

E+c E-c NE+c NE-c Appren Stud Pas PPup Child

Table 42: List of the activity chains: mobility rates per person group in %

147 © PTV AG


The utility matrix may also include the log sum of mode-specific use. In this way, specificskims (e.g. PrT journey time or PuT number of transfers) are included in the total utility withtheir 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 activityThese parameters can be estimated beforehand (see "Estimate gravitation parameters(KALIBRI)" on page 156)

This is how a multitude of trip chains is created through each activity chain. The result of tripdistribution is not only a total traffic matrix, but also a set of all route chains.With the destination choice model, VISEM needs a target potential Zj for each activity. Thetarget potential specifies the quantitative attractiveness of a zone. This target potential for eachzone j, corresponds to the value of the structural property (see "VISEM Data model" onpage 144) that belongs to the activity.The utility function f(uij) is pivotal in the destination choice model. It specifies the probability Pijwith which one of the zones j is selected as destination zone (from all destination alternatives)of origin zone i.

where

whereby uij describes the utility relation ij and the utility function f(uij) (e.g. of the type Logit) can

consequently be defined as . All other evaluation functions of the EVA demandmodel can also be used as utility functions in VISEM (see "EVA Trip Distribution and ModeChoice" on page 135).In this case, the choice of parameter c for every activity is pivotal for destination choice. cstands for the influence of utility on the destinations of the respective activity. If c = 0, then theutility uij has no influence on the choice of destination. The larger c is, the larger is the impactof utility uij on the choice of the destination (see "Gravity model calculation" on page 157).

You need to define function parameters for each combination of person groups and destinationactivity.To give you a better idea of what the three main model elements of destination choice, namelydestination potential, utility function and utility matrix, stand for, we will continue with theexample we used for trip generation (see "Example of trip distribution in VISEM" on page 147).

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

k Index of zones (with k = the smallest zone number and B = the number of zones)

Fij Qi Pij⋅=

PijZj f uij( )⋅

Zk f uik( )⋅k 1=

B∏------------------------------------------=

f uij( ) ecuij=

148 © PTV AG


Example of trip generation

A Logit utility function ( with parameter c = 0.4) is used to represent thechangeovers 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 potentialdestination zones, containing jobs. VISEM distributes these 93.4 trips to the destination zones,according to the previously described destination choice model. To make it easier, let us assume that zone 2 is the only zone with jobs, which therefore has apositive destination potential for the activity work. Expressed in numbers this would beapproximately Z1 = 0, Z2 = 100, Z3 = 0. The VISEM trip distribution formulas produce thefollowing 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.

After the activity work, based on zone 2, the probability for the choice of shopping destinationsis calculated for the subsequent trips WO. It is assumed, that the destination potentials for theactivity "Shopping" are defined as follows: Z1 = 0, Z2 = 50, Z3 = 50. Based on travel times anddistances, the utility defined for changeover WO, with the relation 2-2, is twice as high as thechangeover with the relation 2-3, thus approximately u22 = 2 and u23 = 1. The VISEM tripdistribution formulas produce the following results: P21 = 0, P22 ≈ 0.6 and P23 ≈ 0.4, andtherefore F21 = 0, F22 ≈ 56.0 and F23 ≈ 37.4. 40 % of the trips thus lead to zone 3 and 60 % tozone 2 (i.e. trips within the cell).Here, multiplication of the destination probability of the work and shopping destinations takesplace 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 thedestination of the last trip of the chain.This results in the following transition matrices.

• Matrix F1 for the first activity transfer (Destination activity W)

• Matrix F2 for the second activity transfer (Destination activity O)

Note: The definition of the utility function in this case does not influence the calculation.

Zone 93.4 1 2 3

93.4 Total 0 93.4 0

1 93.4 0 93.4 0

2 0 0 0 0

3 0 0 0 0

Zone 93.4 1 2 3

93.4 Total 0 56.0 37.4

1 0 0 0 0

2 93.4 0 56.0 37.4

f uij( ) ecuij=

149 © PTV AG


• Matrix F3 for the third activity transfer (Destination activity H)

Summed up, the following total demand matrix applies FG.

Summary of this destination choice example• HW: 100 % leave zone 1 with destination zone 2• WO: 60 % remain in zone 2 and 40 % leave zone 2 to zone 3• OH: 100 % return to zone 1.The corresponding route chains are as follows:• 1-2-2-1: 93.4 • 100 % • 60 % • 100 % = 56.0• 1-2-2-1: 93.4 • 100 % • 40 % • 100 % = 37.4The following route chains have been created:• 56.0 route chains 1-2-2-1• 37.4 route chains 1-2-3-1

VISEM allows specific utility matrices to be imported for each activity. Combinations ofdistances and journey times can be used as a basic parameter in utility matrices.

3 0 0 0 0

Zone 93.4 1 2 3

93.4 Total 93.4 0 0

1 0 0 0 0

2 56.0 56.0 0 0

3 37.4 37.4 0 0

Zone 280.2 1 2 3

280.2 Total 93.4 149.4 37.4

1 93.4 0 93.4 0

2 149.4 56.0 56.0 37.4

3 37.4 37.4 0 0

Notes: The following behavioral aspects should be taken into consideration when you definethe 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 functionfor 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 witha low absolute value, rather than for example activity Shopping.

Zone 93.4 1 2 3

93.4 Total 0 56.0 37.4

150 © PTV AG


If, however, the absolute value of the destination potential of an activity is very important, as forexample for the number of jobs, this can flow into the calculation via the Destination-sidedattraction option. If there are about 6000 jobs in the study area, with 1000 jobs, the zone hasa relative destination potential of 1000/6000 = 1/6 for the activity Work. If a demand stratumhas a total of 3000 home trips, the absolute destination potential of the zone for this demandstratum, nominated on the total home trips = 3000 • 1/6 = 500. This absolute value is used inthe doubly coupled gravity model, as constraint on destination side for this demand stratum(see "Gravity model calculation" on page 157).The trip distribution results are saved in aggregated format in a total demand matrix per persongroup and additionally in a matrix per destination activity.

Mode choice: discrete distribution modelThe VISEM demand model has a behavior-oriented concept, which models the followingaspects of the decision-making of road users.• The socioeconomic position and the mode availability of the person making the decision

(by differentiating according to person groups)• Different attributes of all modes (through the utility model)• Freedom of choice restrictions within trip chains (by definition of exchangeable and non-

exchangeable modes)This decision problem is illustrated in a discrete distribution model, which specifies theprobability 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-vehicletime, access and egress times, fare, etc.). If required, you can define several utilities perdestination activity.This model has the following functional form.

where

Note: The absolute value of a destination potential is first of all irrelevant, because it onlyflows into the destination choice model comparatively to the sum of destination potentials ofall zones. So for example, destination potential jobs = 1000 in a zone does not necessarilymean, that VISEM leads 1000 trips with destination activity to this zone. In fact, thedestination traffic depends on the product of destination potential and utility function value inrelation to the other zones.

i, j Indices of the traffic zones

m Index of modes (M = total number)

Pmij

Probability of selecting mode m for trip from i to j

umij Utility when choosing mode m for trip from i to j

Pijm f uij

m( )

f uijk( )

k 1=

M∑------------------------------=

151 © PTV AG


can e.g. be a Logit utility function and thus be defined as . As an

alternative, all available types of evaluation functions can be used from the EVA demandmethod as a utility function for the VISEM mode choice (see "EVA Trip Distribution and ModeChoice" on page 135).As a base parameter for the utility matrices any distance combinations and mode specificskims can be used, such as travel times, access and egress times, and fares.Last but not least, we would like to explain the importance of the route chain concept for modechoice.In VISUM the modes are divided into the following groups:• exchangeable modes (generally walk, passenger and public transport)• non-exchangeable modes (car, bike)VISEM calculates a discrete distribution model (for example Logit) when first calculating thetrip of each route link (for a person group) and chooses one from all modes. If the first mode isa non-exchangeable mode, the entire trip chain is maintained independent of the attributes ofthis mode of the successive trip. If an exchangeable mode was selected for the first trip, modechoice is carried out for the remaining chain trips, however, only within the exchangeablemodes.

Example of mode choiceWe will continue with the example from the trip distribution (see "Example of trip generation" onpage 149) and will determine the matrices for each activity transfer for the three modes Car(C), PuT (X) and Walk (W). Only mode P cannot be exchanged. The set of exchangeablemodes X and W in short is also designated with A. A Logit utility function ( with parameter c =

0.4) is used again to represent the changeovers from and to the individual

activities. The utility matrices um for each mode m are provided by

• uP

• uO

Zone 1 2 3

1 3 3 3

2 3 3 3

3 3 3 3

Zone 1 2 3

1 2 1 1

2 1 2 2

3 1 2 2

f uijm( ) f uij

m( ) ecuijm=

f uijm( ) ecuij

m=

152 © PTV AG


• uF

After analyzing the formula above, the following probability matrices apply.

• PP

• PO

• PF

• PA = PO + PF

Interesting are also the probabilities for modes X and W within the exchangeable modes.

• PAO = PO / PA

Zone 1 2 3

1 1 1 1

2 1 1 1

3 1 1 1

Zone 1 2 3

1 0.472 0.526 0.526

2 0.526 0.472 0.472

3 0.526 0.472 0.472

Zone 1 2 3

1 0.316 0.237 0.237

2 0.237 0.316 0.316

3 0.237 0.316 0.316

Zone 1 2 3

1 0.212 0.237 0.237

2 0.237 0.212 0.212

3 0.237 0.212 0.212

Zone 1 2 3

1 0.528 0.474 0.474

2 0.474 0.528 0.528

3 0.474 0.528 0.528

Zone 1 2 3

1 0.598 0.5 0.5

2 0.5 0.598 0.598

153 © PTV AG


• PAF = PF / PA

The matrix of the first non-exchangeable mode Car for all activity transfers is calculated. Thematrix for the first activity transfer is the product of PP with the total demand matrix F1 of the firsttransfer.

• Total demand matrix F1 for the first activity transfer (Destination activity W)

• Matrix FP1 for mode C and the first activity transfer (Destination activity W)

With the next activity changeover, these 49.12 trips will be distributed across zones 2 and 3according to the distribution probabilities (P22 = 0.6 or P23 = 0.4).

• Matrix FP2 for mode C and the second activity transfer (Destination activity O)

Finally, the trips have to end back at the last activity transfer in their origin zone 1.

3 0.5 0.598 0.598

Zone 1 2 3

1 0.402 0.5 0.5

2 0.5 0.402 0.402

3 0.5 0.402 0.402

Zone 93.4 1 2 3

93.4 Total 0 93.4 0

1 93.4 0 93.4 0

2 0 0 0 0

3 0 0 0 0

Zone 49.12 1 2 3

49.12 Total 0 49.12 0

1 49.12 0 49.12 0

2 0 0 0 0

3 0 0 0 0

Zone 49.12 1 2 3

49.12 Total 0 29.47 19.65

1 0 0 0 0

2 49.12 0 29.47 19.65

3 10 0 0 0

Zone 1 2 3

154 © PTV AG


• Matrix FP3 for mode C and the third activity transfer (Destination activity H)

Summed up, the following Car total demand matrix applies: FPG

To determine the total demand matrix for non-exchangeable modes, this Car matrix issubtracted from the total demand matrix FG (from trip distribution).

• FG

The difference first results in the total demand matrix for all non-exchangeable modes.

• FA

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 theprobabilities PAO and PAF.

Zone 49.12 1 2 3

49.12 Total 49.12 0 0

1 0 0 0 0

2 29.47 29.47 0 0

3 19.65 19.65 0 0

Zone 147.36 1 2 3

147.36 Total 49.12 88.59 19.65

1 49.12 0 49.12 0

2 88.59 29.47 29.47 19.65

3 19.65 19.65 0 0

Zone 280.2 1 2 3

280.2 Total 93.4 149.4 37.4

1 93.4 0 93.4 0

2 149.4 56.0 56.0 37.4

3 37.4 37.4 0 0

Zone 132.84 1 2 3

132.84 Total 44.28 70.81 17.75

1 44.28 0 44.28 0

2 70.81 26.53 26.53 17.75

3 17.75 17.75 0 0

155 © PTV AG


• PuT total demand matrix FO

• Walk total demand matrix FF

Make sure that the Car total demand matrix has identical row and column sums for each zone,whereas this is not mandatory for the PuT and Walk matrices.The Mode choice results are saved in aggregated form in a demand matrix per person groupand mode.

3.2.4 Estimate gravitation parameters (KALIBRI)The Estimate gravitation parameters function (short KALIBRI) allows you to calibrate twodifferent utility functions (determine parameters a, b and c) for the gravity model used for tripdistribution.

1.where

2.where

The KALIBRI function adjusts these utility functions to a given trip length distribution.Then the Trip distribution function calculates the traffic flow Fij (from zone i to zone j) with theaid of the gravity model and known data, namely the source traffic Qi (of zone i), destination

Zone 70.75 1 2 3

70.75 Total 22.14 38.00 10.61

1 22.14 0 22.14 0

2 39.74 13.27 15.86 10.61

3 8.87 8.87 0 0

Zone 62.09 1 2 3

62.09 Total 22.14 32.81 7.14

1 22.14 0 22.14 0

2 31.07 13.26 10.67 7.14

3 8.88 8.88 0 0

Uij Value of the utility (for example distance or travel time) between zone i and zone j

a,b,c Parameters to be estimated

Uij Value of the utility (for example distance or travel time) between zone i and zone j

a,c Parameters to be estimated

( ) ijUceb

ijUaijUf⋅

⋅⋅=

( ) ijUceaijUf

⋅⋅=

156 © PTV AG


traffic Zj (of zone j) and the parameters a, b, c (or a, c) specified here (see "Gravity modelcalculation" on page 157).The KALIBRI function provides two options that allow you to estimate the parameters for thegravity model.• production distribution• doubly constrained (Multi procedure)Parameters a, b, c or a, c respectively are determined in an iterative process. The utility functionis transformed during this process; with

(2)or

(3)Within each KALIBRI iteration a temporary demand matrix is calculated (for example via Multiprocedure with option doubly-constrained gravity model). The resulting values of the utilityfunction are smoothed by linear regression until the maximum number of KALIBRI iterations isreached or the values do not change anymore. The smoothed values then describe a functionof type (2) or type (3).

3.2.5 Gravity model calculationThe Gravity model is a mathematical model for trip distribution calculation (see "Tripdistribution" on page 112 and "VISEM Trip distribution/Mode choice combined" on page 147).It is based on the assumption that the trips made in a planning area are directly proportional tothe relevant origin and destination demand in all zones and the functional values of the utilityfunction between the zones (Ortúzar 2001).The gravity model calculates a complete matrix of traffic relations Fij, using the OD pairs ofmarginal totals (origin and destination traffic of the individual zones). A consistent utility matrixof the planning region is required.The gravity model works with distribution parameters, therefore with values within the utilityfunction, which map the reaction of road users to distance or time relations. These parametersare determined by comparing the demand per OD pair arising from the model, with the counteddemand per OD pair (calibration).The capability of the models to predict future conditions (forecasting) depends on whether theymanage to predict the behavior of road users in relation to the network impedances, as well asknowledge of the model input data applicable for the future (for example future travel demand).

( ) ijUcijUlnbalnijUfln ⋅+⋅+=

( ) ijUcalnijUfln ⋅+=

General form of the distribution formula where

Logit

Kirchhoff

Fij kij Qi Zj f Uij( )⋅ ⋅ ⋅=

f Uij( ) ecUij=

f Uij( ) Uijc=

157 © PTV AG


The distribution formula is referred to an attraction or utility function, with the followingparameters.

Determining the scaling factor kij and formulating the utility function f(Uij) are essential forvarious modifications and extensions.The scaling factor kij must be chosen so that the boundary conditions of the distribution models

(4.1)

and

(4.2)

are (at least approximately) fulfilled.Retaining only the first direction of distribution, we speak of production distribution. Retainingonly the second direction of distribution, we speak of attraction distribution. Retaining bothdirections 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 .

For logical reasons, coupling for production requires that there are as many free parameters asthere are zones.This leads to the formulation

with the following secondary conditions for zone i.

BoxCox

Combined

TModel

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.

n Number of zones

f Uij( ) ec

Uijb 1–b

------------------=

f Uij( ) a Uijb e

cUij⋅ ⋅=

f Uij( ) 1Uij

b cUija+

-----------------------------=

Fijj 1=

n∑ Qi=

Fiji 1=

n∑ Zj=

kiˆ

Fij ki Qi Zj f Uij( )⋅ ⋅ ⋅=

Fijj 1=

n∑ Qi=

158 © PTV AG


From the n secondary conditions, all can thus be determined by substitution in thedistribution function:

This results in

for Qi ≠ 0

This produces a destination choice model of production distribution.

for all i, j

The destination choice model of attraction distribution is derived analogously.

for all i, j with

The adjustment of the model to reality (calibration) by variation of the free parameters is veryimportant.Since the input parameters Qi and Zj have been specified, the only free parameters that remain

besides the scaling factors ( and ) are the parameters of the utility function f(Uij).

Since for doubly constrained calculation both directions of the distribution, (4.1) and (4.2) must

be met at the same time, the following must also apply for the scaling factors and as well

as = for i = j. In practice, however, this can seldom be achieved, so a true doubly-constrained calculation can only be achieved with much more complex iteration models.As an iteration model the Matrix Editor uses the so-called Multi procedure according to Lohse(Schnabel 1980) (see "The multi-procedure according to Lohse (Schnabel 1980)" onpage 174).The general form of the utility function f(Uij) is

It is depicted for several b and c parameters in the following two figures.

kiˆ

Qi Fijj 1=

n∑ ki

ˆ Qi Zj f Uij( )⋅ ⋅ ⋅j 1=

n∑ ki

ˆ Qi Zj f Uij( )⋅j 1=

n∑⋅ ⋅= = =

kiˆ 1

Zj' f Uij'( )⋅j' 1=

n∑-------------------------------------------=

FijQi Zj f Uij( )⋅ ⋅

Zj' f Uij'( )⋅j' 1=

n∑-------------------------------------------=

FijQi Zj f Uij( )⋅ ⋅

Qi' f Ui'j( )⋅i' 1=

n∑--------------------------------------------= kj

1

Qi' f Ui'j( )⋅i' 1=

n∑--------------------------------------------=

kiˆ kj

˜

kiˆ kj

˜

kiˆ kj

˜

f Uij( ) a Uijb e

cUij⋅ ⋅=

159 © PTV AG


The following four examples show gravity models that are differently constrained and with andwithout balancing.

Example 1: Gravity model singly constrained in terms of production, with and without balancingThe effect of the location factor on the calculation of the trip distribution according to the gravitymodel depends on the type of “coupling” of the gravity model.

Notes: Choose a suitable specification for the utility functions, which means suitableparameters. Among other things, the specification depends on the trip purpose and the modeused. A trip to work is for example, on average longer than a trip for shopping. This meansthat the utility function for the trips to work, depending on the town's size, is only slightlydependent 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 demandbased on the trip purpose. This depends essentially on the requirements in terms of accuracyand the demands on the matrix to be calculated. Benchmark figures for the percentage splitbased on the trip purpose can be obtained for example from the KONTIV 89 (EMNID 1991)or local surveys.

Attractiveness with a = 1 and b = 0

0

0,10,2

0,3

0,40,5

0,6

0,7

0,80,9

1

0 2 4 6 8 10 12 14 16 18 20

Utility between zone i and zone j

f(Uij)

c = -0,01c = -0,1c = -0,3c = -0,5c = -1

Uij

Attractiveness with a = 1 and c = -0,1

0

0,2

0,40,6

0,8

1

1,2

1,41,6

1,8

2

0 5 10 15 20 25 30 35 40

Utility between zone i and zone j

f(Uij)

b = 0,1b = 0,3b = 0,5b = 0,7

Uij

160 © PTV AG


With the distribution method that includes coupling for EITHER attraction or production, thesource or destination traffic is adjusted to the marginal totals in the code file. The location factorthen only affects the "complementary" destination or origin demand. However, the followingapplies

or

whereby ki or kj are attractiveness factors of the i. or j. zones.

With the distribution method that includes coupling for attraction AND production, the impact ofthe attractiveness factor on the origin and destination traffic depends on the function commandin the code file. If for example $GQH is given as function command, the origin demand ischanged by the location factor that is listed in the same line as the factor within the code file.However,

with ki being the attractiveness factor of the i. zone.

• Input file Utility* Zone numbers 1 2 3 4* 2.66 1.75 1.99 1.50* 1 2.08 1.00 0.50 0.33 0.25* 2 2.33 0.33 0.50 1.00 0.50* 3 1.41 0.33 0.25 0.33 0.50* 4 2.08 1.00 0.50 0.33 0.25* 7.90• Input data for calculation without balancing*Zone Production Attraction Factor External 1 10.0000 50.0000 0.50000000 0 2 20.0000 10.0000 1.00000000 0 3 30.0000 20.0000 1.00000000 0 4 40.0000 20.0000 1.00000000 1

The parameters are set as follows:• Combined utility function (exponential)• Parameter a = 1, b = 0.5 and c = -1• Singly-constrained for production without balancing

• Result matrix* Zone numbers 1 2 3 4* 36.76 15.91 30.79 16.55* 1 10.00 3.11 1.45 2.80 2.64* 2 20.01 6.76 2.81 4.82 5.62* 3 30.00 9.97 3.76 7.98 8.29* 4 40.00

Zjj 1=

n∑ Qi ki⋅

i 1=

n∑= Qii 1=

n∑ Zj kj⋅

j 1=

n∑=

Qii 1=

n∑ Z'jj 1=

n∑=Zjj 1=

n∑ Qi ki⋅

i 1=

n∑+

2-----------------------------------------------------------≅

161 © PTV AG


16.92 7.89 15.19 0.00* 100.01• Input data for calculating balancing and scaling according to average value*Zone Production Attraction Factor External 1 10.0000 50.0000 0.50000000 0 2 20.0000 10.0000 1.00000000 0 3 30.0000 20.0000 0.30000000 0 4 40.0000 20.0000 1.00000000 1

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 2 3 4* 32.99 13.19 7.92 26.39* 1 8.04 2.22 0.94 0.56 4.32* 2 16.10 4.62 1.74 0.93 8.81* 3 24.16 6.95 2.38 1.57 13.26* 4 32.19 19.20 8.13 4.86 0.00* 80.49

Example 2: Gravity model singly-constrained for production, with balancing• Input file Utility* Zone numbers 1 2 3 4 5* 166,183 107,560 88,972 134,710 155,725* 1 165,571 0,001 22,700 35,183 50,387 57,300* 2 107,414 22,700 0,001 15,991 31,017 37,705* 3 90,008 35,926 16,284 0,001 15,153 22,644* 4 134,633 50,387 31,017 15,153 0,001 38,075* 5 155,524 57,169 37,558 22,644 38,152 0,001* 653,150• Input data*Zone Production Attraction 1 18990.0 18990.0 2 4960.0 4960.0 3 7110.0 7110.0 4 16080.0 16080.0 5 2300.0 2300.0

Location factor and zone property external are not specified. Default values are used.The parameters are set as follows:• Direction of the distribution according to the production distribution with boundary sum

balancing enforced by the multi procedure.

162 © PTV AG


• 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 3 4 5* 18990.000 4959.951 7109.758 16080.290 2300.000* 1 18990.000 18990.000 0.000 0.000 0.000 0.000* 2 4959.999 0.000 4959.897 0.102 0.000 0.000* 3 7110.000 0.000 0.054 7109.426 0.520 0.000* 4 16080.000 0.000 0.000 0.230 16079.770 0.000* 5 2300.000 0.000 0.000 0.000 0.000 2300.000* 49439.999

Example 3: Gravity model singly-constrained for attraction, without balancing• Input file impedances* Zone numbers 1 2 3 4 1.00 0.50 0.33 0.25 0.33 0.50 1.00 0.50 0.33 0.25 0.33 0.50 1.00 0.50 0.33 0.25• Input data for marginal totals*Zone Production Attraction 1 10 50 2 20 10 3 30 20 4 40 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 2 3 41 0.37 0.43 0.41 0.392 0.41 0.43 0.37 0.433 0.41 0.39 0.41 0.434 0.37 0.43 0.41 0.39

and so

F11 = 4.71

F11Q1 Z1 f U11( )⋅ ⋅

Qi f Ui1( )⋅i 1=

n∑------------------------------------------=

F1110 50 0 37,⋅ ⋅

10 0 37,⋅ 20 0 41,⋅ 30 0 41,⋅ 40 0 37,⋅+ + +-------------------------------------------------------------------------------------------------------------=

163 © PTV AG


The matrix is produced after the other 15 equations have been calculated.• Result matrix* Zone numbers 1 2 3 4* 50.00 10.00 19.99 19.99* 1 9.68 4.71 1.03 2.04 1.90* 2 20.47 10.58 2.06 3.64 4.19* 3 31.09 15.87 2.80 6.13 6.29* 4 38.74 18.84 4.11 8.18 7.61* 99.98

The desired values for destination demand were very well approximated, while the values fororigin demand were not reached so well. This circumstance is characteristic for suchdistribution formulas. Either the origin or the destination sums are reached close enough. Ifboth boundary sums are to be aligned as closely as possible, it is necessary to use a boundarycompensation model. The function offers doubly constrained projection (Multi-Procedure) (see"Projection" on page 173).

Example 4: Gravity model singly-constrained for attraction, with balancingNow the trip distribution in Example 3 (see "Example 3: Gravity model singly-constrained forattraction, without balancing" on page 163) shall be calculated using a balancing procedure(Multi-procedure).• Input file impedances* Zone numbers 1 2 3 4 1.00 0.50 0.33 0.25 0.33 0.50 1.00 0.50 0.33 0.25 0.33 0.50 1.00 0.50 0.33 0.25• Input data* ZoneNo Productions Attractions 1 10 50 2 20 10 3 30 20 4 40 20

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 2 3 4* 50.00 10.01 20.00 20.00* 1 10.01 4.87 1.06 2.11 1.97* 2 20.00 10.34 2.01 3.55 4.10* 3 30.00

164 © PTV AG


15.32 2.70 5.91 6.07* 4 40.00 19.47 4.24 8.43 7.86* 100.01

3.2.6 Modal Split (standardized assessment)

The bi-modal mode choice model uses travel time as choice variable. This procedureestimates the future travel demand by mode based on the current demand and accounting foran improved PuT offer (for example journey time) for each mode:

with

Types of demand distinguished by the mode choice model

Note: In Germany, a ”Standardized assessment“ is required by law for any public transportrail/road network construction measure. Since 2000, method B2 has to be used for theStandardized assessment. Outside of Germany or for simple cost-benefit analyses, methodB1 (1993) is recommended.

P0m

current share of mode m

P1m

future share of mode m

U0m

current utility of mode m

U1m

future utility of mode m

( )( )∑

=

−⋅

−⋅= n

1i

UUe0iP

UUe0mP:1

mP0i

1i

0m

1m

Private Transport(without measure)

Public Transport(without measure)

Impact of measure

(1) (2) (4)

Private transport(with measure)

(3) Public Transport(with measure)

(4)

165 © PTV AG


Procedure B1

public transport trips in current state

private transport trips in current state

total trips in current state

.

private transport journey time: current (0) / future (1) state

.

public transport journey time: current (0) / future (1) state

.

no. of transfers: current (0) / future (1) state

.

service frequency: current (0) / future (1) state

Remaining private transport demand

Trips which use private transport in the current and the future state.Remaining public transport demand

Trips which use public transport in the current and the future state.

(1) Demand shifted from private to public transport

Trips which use private transport in the current state but switch to public transport in the future state.

(2) Demand shifted from public to private transport

Trips which do not exist in the current state, but are generated by the public transport measure.

(3) Total sum of shifted demand

Total sum of shifted demand =

Demand shifted from private to public transport –

Demand shifted from public to private transport(4) Induced public transport demand

Trips which use public transport in the current state but switch to private transport in the future state.

0PuTT

0TPrT

0PuTT0

TPrT0TotT +=

0TPrJT 1

TPrJT

0PuTJT 1

PuTJT

0PuTNT 1

PuTNT

0PuTSF 1

PuTSF

166 © PTV AG


B1: Calculation

.

so-called share of high quality public transport: current (0) / future (1) state

public transport share in current state

public transport share in future state

Input parameters Procedure B1

g0 (constant = 1.0, cf. formula above)

g1 Standard value: 2.600

g2 Standard value: -1.700




private transport trips in future state

PuT trips in future state including induced trips

PuT trips in future state without induced trips

0PuTSR 1

PuTSR

0TotT0

PuTT0PuTp =

PuTp0PuTp1

PuTp Δ+==PuTpΔ

−

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛⋅+⋅+⋅+⋅+

+

1PuT

1PuT

1PuT1

PuT

1TPr SR5gSF4gNT3g

JT

JT2g1g

e1

1

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛⋅+⋅+⋅+⋅+

+

0PuT

0PuT

0PuT0

PuT

0TPr SR5gSF4gNT3g

JT

JT2g1g

e1

1

0TotT1

PuTp11TPrT ⋅⎟

⎠⎞⎜

⎝⎛ −=

1Ind,PuTT1

*PuTT1PuTT +=

1TPrT0

TotT1*PuTT −=

167 © PTV AG


Procedure B2

In VISUM, the Modal split calculation methods B1 and B2 are both based on timetable-basedassignment results of• current network status (without measure): Without scenario• future network status (with measure): With scenarioIn Germany, the procedure B2 has to be used for the „Standardized assessment“ which isrequired by law for any public transport rail/road network construction measure (Version 2000,by the German Federal Ministry of Transport, Construction and Housing). The input parameters of the procedures differ. Recommended standard values are listed for g1to g5. In VISUM, parameter g0 is not 1.1 (thus deviating from the German guidelines), but hasa constant value of 1. Though the B1 method is not as complex as the B2 method, it provides results of sufficientquality.The bi-modal approach uses the modal-split shares of the current state, which are available asdemand matrices for PrT and PuT.The modal split of a future state is determined by the current modal split and the changes ofthe following skims.• private transport journey time (door to door) JTPrT (tCur)• public transport journey time (door to door) JTPuT

• no. of transfers in public transport NTPuT

• public transport service frequency SFPuT

• share of high quality transit SRPuT, for example light rail as percentage of the trip length(B1). The term was extended for B2 (roadway supports degree).

induced public transport trips in future state

Input parameters Procedure B2




1Ind,PuTT

1PuTJT

r1PuTJT0

PuTJT0PuTT,1

*PuTTMIN1

Ind,PuTT⋅⎟

⎠⎞⎜

⎝⎛ −⋅⎟

⎠⎞⎜

⎝⎛

=

⎪⎪

⎩

⎪⎪

⎨

⎧<−

−

≥−=

min5JTJTif,5

JTJT

min5JTJTif,1r

1PuT

0PuT

1PuT

0PuT

1PuT

0PuT

168 © PTV AG


3.2.7 IterationIteration allows the repetition of the different steps of a procedure and therefore can be used tore-incorporate skims calculated during the assignment into previous stages.

3.2.7.1 Go to the operationThe Go to operation performs a convergence check. It is either checked if an attribute or matrixhas changed by less than a user-defined threshold during the last iteration, or if a specific user-defined attribute lies under a certain value. The second case might be useful if you add a scriptfirst that recalculates the respective value.If the convergence condition has been fulfilled, VISUM continues with the next step of theprocedure. If not, VISUM returns to the point specified as Go to target (operation or group) anditerates the procedure from there (operation) or from the next step (group). Independent of this,the convergence check is canceled as soon as a maximum number of iterations is reached.

3.2.7.2 Method of Successive Averages over matricesUsing MSA (method of successive averages), you can calculate the mean value of twomatrices (demand or skim matrices).This function is meant to improve convergence in demand models used for feedback. You canadd it prior to the Go to operation if you want to use an averaged matrix of all iterationsinstead of a matrix of the current iteration as a GoTo criterion.The operation calculates

whereby

3.2.7.3 Method of Successive Averages over attributesAs for matrices the average values of attributes can be determined by means of MSA (Methodof Successive Averages), too.This function is meant to improve convergence in demand models used for feedback. You canadd it prior to the Go to operation if you want to use an averaged matrix of all iterationsinstead of a matrix of the current iteration as a GoTo criterion.The operation calculates

A Result matrix

B Matrix of current iteration

C Matrix average of all previous iterations

i iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to operations aretriggered it always uses the innermost loop as point of reference.During an operation you can exchange the two weightings. However, make sure that one ofthe weightings is always 1/(i+1) and the other is i/(i+1).

A 1i 1+----------- B⋅ i

i 1+----------- C⋅+=

169 © PTV AG


whereby

3.3 Displaying and Editing MatricesVISUM provides various options for displaying and editing matrices or using them forcalculations.

VISUM offers both simple and more complex operations for editing and calculating matrices.Most operations can be performed directly in the Matrix editor(see User Manual, Chpt. 3,page 635), others are available as procedures (see User Manual, Chpt. 4, page 813).

A newly calculated attribute value

B Attribute value of current iteration

C Averaged attribute value of all previous iterations

i iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to operations aretriggered it always uses the innermost loop as point of reference.During an operation you can exchange the two weightings. However, make sure that one ofthe weightings is always 1/(i+1) and the other is i/(i+1).

A 1i 1+----------- B⋅ i

i 1+----------- C⋅+=

Functions used to display and analyze matrices

Highlighting matrix sections in color

Showing matrix values in an aggregated form

Filtering matrix values

Displaying matrix values as a histogram

Comparing two matrices

Functions for copying / replacing matrix values Matrix window

Procedure

Edit individual matrix values interactively x

Set values conditionally x x*

Form constant matrix x x*

Transpose x x

Reflect upper or lower triangle x x

Set diagonal x x*

Copy diagonal to Clipboard Paste diagonal from Clipboard

x*

170 © PTV AG

Chapter 3.3: Displaying and Editing Matrices

* Not a procedure of its own, but possible via Combination of matrices and vectors

3.3.1 Displaying matrices in tabular formMatrices can be clearly arranged in a table. In VISUM you can edit the layout of the datadisplayed in the matrix window in order to enhance the overview (see User Manual, Chpt. 3.3,page 727):• You can open several matrices in a window so that the corresponding values of the

matrices are positioned side by side.• In addition to the matrix values, it is possible to display the row and column headers as well

as the row and columns totals.• You can classify the matrix values and display the values of different classes in different

font and background colors.• You can filter the matrix values so that only the rows and columns of your choice are

displayed.• The matrix values can be visualized in an aggregated form without changing the values

themselves.

Arithmetic operations on matrices Matrix window

Procedure

Round x

Add / subtract matrices x x*

Multiply / divide matrices (elementwise) x

Form reciprocal (elementwise) x x

Raise to power (elementwise) x

Take logarithm (elementwise) x x

Exponential function (elementwise) x x

Forming maximum or minimum x x

Symmetrize matrix (calculate average values pairwise from top and bottom triangle)

x x

Combination of matrices and vectors x x

Projection: various procedures x

Projection of aggregated areas x

Calculate matrix using marginal totals, i.e. trip distribution (see "Gravity model calculation" on page 157)

x

Generate main zone matrix, using zone matrix (aggregate) - and generate zone matrix, using main zone matrix (disaggregate)

x x

Functions for structural changes to matrices

Extend matrix (include new OD pairs in matrix for arithmetic operations)

Aggregate (summarize rows/columns of a matrix)

Split/Extend (rows/columns of a matrix into/to several ones)

Form partial matrix (non-symmetric aggregation)

171 © PTV AG


• You can change the alignment of the values and the number of the displayed decimalplaces.

3.3.2 Matrix values displayed as histogramThis function allows you classify the values of one or several matrices and to display them ascolumn chart. You define intervals for the classification of the matrix values. You can determinethe intervals interactively or import them from a file (see User Manual, Chpt. 3.3.11, page 752).It is also possible to classify the matrix by using a comparison matrix that must include identicalzones. 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 thisallocation.In addition to the histogram a list is displayed showing the number and the percentage of ODpairs for both, each interval and cumulative for all intervals. If the matrix is changed, the resultswill be updated automatically.This function serves for analyses of existing data for further matrix processing steps, forexample aggregating data (see "Aggregating matrix objects" on page 177). The intervals canbe stored and used for other applications.

3.3.3 Transpose, reflect upper or lower triangle, apply mean valueThe Transpose function allows lines and columns of a matrix to be interchanged, which meansthat the values of the rows become the values of the columns and vice versa. The resultingmatrix consequently contains the values of the opposite direction of the input matrix, withunchanged values in the diagonal. This function is used, for example, to generate a matrix ofthe outgoing traffic from a matrix of the incoming traffic.The function offers the option of copying the matrix section below the diagonal into the uppertriangle. The function offers the option of copying the matrix section above the diagonal into thelower triangle.

3.3.4 Copy, paste and apply diagonal

The functions Copy diagonal into clipboard and Paste diagonal from clipboard enable theexchange of diagonal values between two matrices. For example, you can set a matrix valueoutside the diagonal to zero by copying the diagonal, setting all matrix values to zero andreinserting the diagonal.The function offers the option of setting the values of the diagonal with a new value, with thematrix values remaining unchanged for all relations FromZoneNo ≠ ToZoneNo.

3.3.5 RoundWith the Round function you round all matrix values to a specified precision. The matrix valuesare rounded up or down so that the new value is a multiple of the value rounded. Therefore, itis possible to round up to 01. or 0.25, for example.

Note: The diagonal of a matrix runs from top left to bottom right (FromZoneNo = ToZoneNo).In demand matrices the diagonal represents the trips within the cell.

172 © PTV AG


3.3.6 Form reciprocal, raise to power, take logarithm, exponential functionThe function offers the possibility of transferring the reciprocal of any given matrix value intothe matrix.The function offers the possibility of giving an exponent for all matrix values and transferringthe result in each case as the new matrix value.The function offers the possibility of determining the logarithm for each matrix value andtransferring the result in each case as the new matrix value.The Exponential function offers the possibility of using each matrix value as exponent for e (e= 2.71828183) and transferring the result in each case as the new matrix value.

3.3.7 Maximum or minimum formationThe formation of a maximum or minimum results from the comparison of each value in theprocessed matrix with a user-defined value or the matrix value of the same relation in anothermatrix.The result matrix then contains the following values for each relation.• The greater of the two values at maximum formation• The smaller of the two values at minimum formationMaximum or minimum formation is mostly used for symmetrization of a matrix, often inconnection with Transposing (see "Transpose, reflect upper or lower triangle, apply meanvalue" on page 172).

3.3.8 Make symmetrical: Mean value upper / lower triangleThe Make symmetrical function calculates the mean value from the matrix values by elementin the upper and lower triangle and replaces them by this mean value (see User Manual, Chpt.3.5.12, page 787).

3.3.9 Calculate the combination of matrices and vectorsValues which result from a combination of other matrices and vectors can be assigned to amatrix . The values of individual input matrices and vectors can be transformed by element,multiplied by a factor and then added (see User Manual, Chpt. 3.5.13.1, page 788).

3.3.10 ProjectionThe functionality is primarily used if origin or destination total values of a zone are to bemultiplied by a particular value, or a particular expected value is to be attained, which can benecessary in some circumstances after origin-destination studies. Matrices collected are oftenjust random samples and must be projected to census values.The matrix values can be projected per row (singly constrained projection regarding thegeneration), per column (singly constrained projection regarding the production) or both rowsand columns (doubly constrained projection).The complexity of the doubly constrained projection is illustrated by the example below.The aim of this example is to project the origin and destination demand in the following way.

Note: This function allows you to add exponential or BoxCox-transformed complex terms.

173 © PTV AG


• zone 1 by 10 %• zone 2 by 20 %

Table 43: Basic matrix

Line by line multiplication, therefore for purely singly constrained projection of the demandregarding production originating from zone 1 by 10% and zone 2 by 20%, produces thefollowing matrix.

While the origin traffic has been increased correctly, the destination traffic has not.For the doubly-constrained projection, the Matrix editor uses an iterative process, also called aMulti-procedure. In an iterative (stepwise) progression, this process searches for the solutionthat best achieves the expected values (see "The multi-procedure according to Lohse(Schnabel 1980)" on page 174). The Matrix Editor thus provides the following solution which correctly projects the origin anddestination traffic.

Table 44: Result matrix

The multi-procedure according to Lohse (Schnabel 1980)With the multi-procedure new traffic flows are calculated in each iteration step Fij (Schnabel1980).The iteration formula applied is as followsFij(n+1) = Fij(n) • qi(n) • zj(n) • f(n)

with

Zone 1 2 Origin traffic

1 20 30 50

2 40 50 90

Destination traffic 60 80 140


1 22 33 55

2 48 60 108



1 21 34 55

2 45 62 107


qi n( )Qip

FijZjp

Zj n( )-------------⋅

j∑---------------------------------=

174 © PTV AG


This iterative calculation is done repeatedly until the following conditions are met for allboundary values (origin and destination expected values).

for all zones i

for all zones j

The threshold ε suggested by Lohse was used. It states that

or

GF: Quality factorWhen activating the calibration process, you can set the following parameters for this multi-procedure.

3.3.11 Converting zone and main zone matrix into each otherWhen aggregating a zone matrix and a main zone matrix, you add the matrix values of zonesthat belong to the same main zone. This applies both to OD demand and skim matrices. Thetotal 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 intoseveral matrix values for the individual zones and add them to a zone matrix. The values can

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

Parameters DescriptionMaximum number of iterative steps

1..9999 (as required); the default is 10

Quality factor 1..99 (as required); the default is quality factor = 3The higher the quality factor, the longer the computing time and the higher the precision of the calculations.

zi n( )Zjp

FijQip

Qi n( )--------------⋅

i∑----------------------------------=

f n( )Gp

G n( )------------=

Qi n( )Qip

-------------- 1– ε≤

Zj n( )Zjp

------------- 1– ε≤

ε 1GF Qip⋅( )

-----------------------------= ε 1GF Zjp⋅( )

----------------------------=

175 © PTV AG


be equally distributed. However, you can also weight them. As weighting factors you can usethe values of one or two zone matrices or of OD zone attributes.If you select two weighting factors, the new matrix values are calculated as follows:

where

Use caseYou would like to correct a matrix or adjust it using count data. The count data available refersto a rougher zone structure than your network. In this case, you first aggregate the zonematrices, then perform a correction procedure (e.g. TFlowFuzzy) and finally disaggregate thematrix again.

3.3.12 Extending matricesYou can extend external matrices during an arithmetic operation, i.e. you can add columns androws. To do so, choose an arithmetic operation that allows you to combine external matriceswith matrices that have different OD pairs.You can use any arithmetic operation that requires a second operand, e.g. the basic ones orforming the maximum or minimum.The matrix data is calculated as follows:• The arithmetic operation is performed for the OD pairs that occur in all matrices.• If an OD pair is not listed in all matrices, a null is entered for it before the arithmetic

operation is performed. Then the arithmetic operation is performed.• For OD pairs that are not listed in any of the matrices, a default value is set in the results

matrix.

Example of extending a matrixOn the addition, the two matrices are extended. The standard value specified for new OD pairsis 99.• Matrix in Matrix window

i, j Zone indices

i, j Main zone indices related to the zone indices

Index(I), Index (J) Number of zone indices belonging to the main zone

b Output matrix (zone matrix)

a Input matrix (main zone matrix)

w Weighting factors

Note: If the denominator of a fraction is zero, weighting will be ignored.

bijwi

1 wj2⋅

wl1 wm

2⋅m Index J( )∈∑l Index I( )∈∑

----------------------------------------------------------------------------------------- aIJ⋅=

1 2 3

1 1 1 1

176 © PTV AG


• Matrix chosen as operand

• Matrix extended on addition

3.3.13 Aggregating matrix objectsThis function allows you to group several matrix objects to create one or several new objects.You can use the Aggregate function to rename zones and/or group them into larger units (e.g.districts). The number of rows and columns of a matrix is changed through aggregation.The new matrix values are calculated with the aid of the following formulas:

with

2 1 1 1

3 1 1 1

1 2 4 5

1 2 2 2 2

2 2 2 2 2

4 2 2 2 2

5 2 2 2 2

1 2 3 4 5

1 3 3 1 2 2

2 3 3 1 2 2

3 1 1 1 99 99

4 2 2 99 2 2

5 2 2 99 2 2

Arithmetic mean

Weighted mean

qi Matrix value of i. zone

gi Weighting of i. zone

n Number of columns or rows

qii 0=

n∑

n---------------------

qi gi⋅i 0=

n∑

gii 0=

n∑

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

177 © PTV AG


Example of aggregating matrix objectsThe 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 usedThe following matrix results.

Matrix values of destination zone 39 were calculated as follows:7 = (6•6+7•7+1•10+1•11)/(6+7+1+1)15 = (14•2+15•2)/(2+2)

3.3.14 Splitting (extending) matrix objectsUsing the Split function, you can subdivide zones into smaller units. The number of rows andcolumns of a matrix is changed through splitting. This function is often used for adapting overalldemand 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 origintraffic 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 candecide whether or not you want to include the expected gains (total > 1.0) or losses (total < 1.0)per split zone.

178 © PTV AG

Chapter 3.4: Matrix correction

For a skim matrix, the matrix value per split zone is generally assigned to the new zones usingthe factor 1.0, i.e. they remain unchanged.

Example of splitting matrix objectsThe zones of the following matrices are split and deleted.

Thereby the following settings are made:

This produces the following matrix:

Sum of the matrix values of all OD pairs from/to 1001..1003 = 1000.

3.4 Matrix correctionYou have different possibilities of correcting the demand matrix values with count data.• Updating demand matrix with TFlowFuzzy• Projecting PrT Path Volumes• Calibrating a PrT matrix

3.4.1 Updating demand matrix with TFlowFuzzyLike all matrix correction procedures, TFlowFuzzy is meant to adjust a demand matrix, so thatits assignment results for a supply actually match the real supply observed (source/targettraffic, passenger trips unlinked or number of boarding/alighting passengers). This procedurecan 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 onbased on census data only.

Zone number old Zone number new Factor origin traffic Factor destination traffic

100 1001 0.3 0.1

100 1002 0.5 0.2

100 1003 0.2 0.7

200 2001 0.7

200 2002 0.3

179 © PTV AG


• A matrix generated from the transport network model is to be calibrated, therefore countedvolume data are to be used.

• A matrix generated from incomplete or not reliable data is to be improved by morecomprehensive/reliable volume data counted simultaneously.

• A survey contains the journey distance distribution, but the model does not reflect the datawith the level of accuracy required.

TFlowFuzzy will solve this problem for PuT as well as for PrT. The update only affects thedemand matrix - not the time series - and always refers to total volumes (instead of volumesper time interval).The flow of information always follows the given order.

The workflow for the matrix calibration is as follows.

You can choose among the following count data:• Link volumes• Origin/destination travel demand per zone

Old matrixdata

New (AddVal)

TFlowFuzzy

New matrix

Network model

Demand matrix

Assignment TFlowFuzzy

Count data

180 © PTV AG


• Volumes of turns at nodes or main turns at main nodes (as long as they are defined)• Volumes via screenlines• PuT passenger trips• Boarding/alighting passengers at stop areas• Skim data distribution, e.g. journey distance distributionYou can also combine count data.For the update, the specified count values are compared with the volumes, which result from aprecalculated assignment of the previous demand matrix. Differences between count valuesand volumes are balanced by adjustment of the demand matrix for the assigned demandsegment. The simplest case refers to a single demand segment. The volumes from theselected network object are then taken from the assignment result of this demand result, andthe count values also only refer to this demand segment. TFlowFuzzy can also simultaneouslyupdate the demand matrices of several demand segments, if only total count values arespecified for all demand segments. Then the count data specified is distributed proportionallyto the respective demand segment share of the assignment volumes. The demand matrix foreach demand segment is then updated individually.Compared to other procedures, the outstanding quality of TFlowFuzzy is• that you can combine the following for matrix correction: origin/destination traffic, link

volumes, turns, main turns or screenlines, passenger trips unlinked and passengersboarding/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 intoaccount for calculation.

3.4.1.1 Methodological basics of TFlowFuzzySince the eighties, primarily in English-speaking countries, so-called matrix correction (ormatrix update) techniques have been used to produce a current demand matrix from an earliertravel demand matrix (base matrix) using current traffic count values. Based on research byVan Zuyten/Willumsen (1980), Bosserhoff (1985) and Rosinowski (1994) which focuses onmatrices for private transport, PTV has extended the application of these techniques to publictransport.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 representationcontaining all non-zero OD trips is more suitable.

181 © PTV AG


While it is usually assumed, that a matrix based on an earlier time is known, only partialinformation is provided for the current state. Important is the situation where there are no databased on relations (from an origin destination survey) available, but only count values atindividual positions in the network. These can be both origin / destination traffic as well as linkvolumes. We note the count values as another vector.

The trips of any OD pair provides a certain share to each traffic count. In case of boarding andalighting passengers the marginal sums of the demand matrix are known. In case of link countsthe counted volumes correspond to the sum of all (proportional) OD trips traveling on this link.In general there is a linear relation between the demand on the OD pairs and the traffic counts.A • f = vwhereby A is called flow matrix. ask is "the share of passengers on movement k, traversing links". For origin / destination traffic count values, A is especially constant, as specified withexample n = 3, m = 6.

In this case, A does not depend on the timetable. However, the supply dependent trip choiceflows into A for link volumes; the flow matrix is obtained for example, through assignment ofany matrix (for example the old demand matrix) on the supply at the time of the count. Bothtypes 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 isunderdetermined by the count values. Out of the countless matrices which match the countvalues "match", only the best is selected according to a evaluation function q, thus solvesmax q(f), so that A • f = vA combination of entropy and weighting with the proportions of the old matrix usually serves asan evaluation function; q is usually non-linear, which is why the problem is solved iteratively (forexample with Newton's method).

⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

=

⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜

⎝

⎛

M

M

M

LMOMMM

LLL

31fn2f

23f21fn1f

13f12f

03nf2nf1nf

n3f032f31fn2f23f021fn1f13f12f0

( )mv3v2v1vrv L=

⎟⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

=

⎟⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

⎟⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

321321

323123211312

001010100001010100110000001100000011

alightalightalightboardboardboard

tttttt

182 © PTV AG


In this wording of the matrix correction problem there is, however, another weakness of theclassic approach: vector v of the count values is assumed as a known parameter, free of everyuncertainty. A q maximum is only selected from the matrices which fulfill the exact secondaryconditions. The count values thus receive an inadequate weight, because each surveyprovides 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 areperceived as "strict" secondary conditions. PTV has therefore taken on the approach by Rosinowski (1994), who modeled the countvalues as fuzzy measured data according to the Fuzzy Sets Theory. If it is known that in azone, the origin traffic fluctuates up to 20 % from day to day, in other zones however about25 %, this is illustrated with the respective bandwidths. In the secondary conditions of thematrix estimation problem, there are thus Fuzzy Sets with sets of variables of differentwidths which replace strict values.

max q(f), so that A • f =

The illustration of Fuzzy Sets compared to pure limits allows the preference of central valuesto be expressed within the set of variables. This means, that values close to the mean valuesare generally preferred, but values within the margin are also accepted, if this means that amuch better q value is achieved.How can the Fuzzy Sets now be treated numerically for the solution of the optimizationproblem? The obvious trip is, to include the membership function of the individual Fuzzy Setsin the evaluation function and in comparison weighted appropriately. To be able to continueusing standard procedures of non-linear optimization, the resulting objective function must alsobe twice continuously differentiable, producing restrictions regarding the form of membershipfunctions. Especially the usually partial linear triangles or trapezoids are eliminated. Instead weuse the same mechanism as for the weighting with the original matrix, to support the choice ofcentral values from the set of values. As a comparison, here the evaluation function of theweighted entropy maximization.

If is already set as a demand from the original matrix, the maximization of q benefitsmatrices which slightly differ from the original matrix. The principle can be transferred to thenew optimization problemmax q(f, s, s‘), so thatA • f + s = vA • f - s‘ = vs ≥ 0s‘ ≥ 0

where are maximum or minimum of the set of variables of the Fuzzy Sets. If the slack

variable s, s‘ is included in the weighted entropy maximization , matrices are favoredthat fulfill A • f = v "best". Doubling the equation appears to be a disadvantage, because this has

sv~

v

( ) ∑ ∑= =

⎟⎟

⎠

⎞

⎜⎜

⎝

⎛−⋅−=

n

1i

n

1jij

ij

ijij f

f

flnffq

fij

v,v

0ss =′=

183 © PTV AG


a direct effect on the calculation time of the runtime determining Gauss method within theNewton iteration. Symmetries in the resulting equation system however, still only allow to solvea 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 andtherefore the degree of freedom for the evaluation (here: entropy maximization), so thatgenerally 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 exampleA Fuzzy set is generally defined as a set of possible values (set of variables) and amembership function with values between 0 and 1, which specifies "how much an element ofthe set of values is perceived as related to the fuzzy set". If the membership function is 0, theelement does not belong to the unclear set. For a value of 1, element "total" belongs to the setand interim values express the quality of approximation. If for example, you want to express thevalue "approximately 4" as a fuzzy set, the set of variables could contain the interval [3;5] andthe membership function rises from value 0 to the interval margins to a maximum of 4.

To make bandwidth modeling in TFlowFuzzy more manageable and operation easier, it isassumed that the membership function has a very special form. From value 1, which isassumed by the survey count values, it drops symmetrically to both sides. It thus creates atriangle, which is determined through the following values.

1

0

3 4 5

Membershipfunction

1

0

z

Membershipfunction

z-α*s z+α*s

184 © PTV AG


Values z, s and α are entries for TFlowFuzzy (see User Manual, Chpt. 3.7.1, page 792). z ands are specified individually for each count value (link volume, origin / destination traffic, turnvolume or main turn volume, as long as a main node is defined), whereas α is a globalparameter for the procedure.

3.4.1.2 Numeric example for TFlowFuzzyA calculation example is used to illustrate the matrix correction procedure. A PuT service isdefined in the very simple network with four zones shown here.

The link bars show the assignment result for the following matrix, which we assume wereobtained 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 4*Zone 1 Total = 300 0 100 100 100*Zone 2 Total = 300 100 0 100 100*Zone 3 Total = 300 100 100 0 100*Zone 4 Total = 300 100 100 100 0

Counts have since been completed on all links of the network, and the following volumesobtained.

z the count value itself, where the membership function assumes its maximum

s the distance between the count value, where the membership function drops to value 0

α a predefined scaling factor (α > 0)

185 © PTV AG


The counted values for this example are based on the assumption that the demand matrix hassince changed as follows.$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 4*Zone 1 Total = 350 0 150 100 100*Zone 2 Total = 330 150 0 100 80*Zone 3 Total = 300 100 100 0 100*Zone 4 Total = 280 100 80 100 0

The counted values from the figure are loaded into VISUM LinkAddValues. Additionally, foreach 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 surveydate to another. This fuzzy value can be accepted as it is or obtained empirically by countingthe same OD relations on different dates.TFlowFuzzy now calculates a new matrix, which on the one hand exhibits to a very high degreesimilar ratios between the number of trips in the individual OD relations as in the old matrix (bymaximizing the weighted entropy), and on the other hand, during assignment matches thecounted values from the new survey within the specified bandwidth.

In the above example TFlowFuzzy, with a random sample accuracy of 5 %, calculates thefollowing matrix, which matches the assumed "ideal solution" very well.$VN 4 1 2 3 4* 346 331 298 281* 1: 346 0 148 99 99* 2: 331 148 0 100 83* 3: 298 99 100 0 99

±

186 © PTV AG


* 4: 281 99 83 99 0* 1256

3.4.2 Projecting PrT Path VolumesThe Projection of routes command adjusts the demand matrix of a PrT transport system to thecounted data of particular links. Thereby all movements Fij that use a selected link for a PrTdemand 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 usedtrips are saved along with their volumes.The update only affects the demand matrix - not the time series - and always refers to totalvolumes (instead of loads per analysis time interval).

3.4.3 Calibrating a PrT matrixThe Cali procedure provides a calibration function that uses count data to calculate projectionfactors - 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 procedureThe projection of the matrix corresponds to the Increase factor model with justification, knownin traffic planning. By comparing the calculated volume with the count data, the counted crosssections supply information on "adjustment factors" which need to be taken into account. Hereit has to be taken into account that an origin/destination relation can traverse several countedcross 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 andbalanced.

• 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 meanadjustment 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 projectionThe Fij matrix of the last assignment serves as the basic matrix.


1 20 30 50

187 © PTV AG


If the traffic of Zone 1 is to be increased by 10 % and the traffic of Zone 2 by 20 %, the followingmatrix (for a projection of the origin only) will result:

It is clear that, although the origin traffic increased by the required amount, the destinationtraffic 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), isused for origin and destination projection, as in an iterative process it searches for that onesolution that is best used to reach the target values (see "The multi-procedure according toLohse (Schnabel 1980)" on page 174).For the above example the following solution is found:

2 40 50 90



1 22 33 55

2 48 60 108



1 21 34 55

2 45 62 107


188 © PTV AG

4 Impact models

An impact model contains all methods to calculate the impact of traffic. It calculates results onthe basis of data and thus represents the computation kernel of the application. Componentsof 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 ofthe impact models for users, operators and the environment.

Subjects• The types of impact models• Impedance functions• Paths in PrT and PuT• Skims / indicators

4.1 The types of impact modelsA transport supply system has diverse impacts which may vary because of measures. Impactsalways refer to those actively or passively involved in traffic, for example the users or operatorsof the transport supply system, to the general public or the environment. The impact models inVISUM are differentiated according to those involved and each comprises all methods oncalculating the effects on one of the roles mentioned.

4.1.1 The user modelUsers of infrastructure for private transport are mostly car drivers and their passengers, butalso non-motorized travelers such as cyclists and pedestrians. Users of public transport arepublic transport passengers. Objective of the user model is to determine the impacts of atransport supply system on travelers. Important skim data for evaluating the transport supplyare the journey time and traveling expenses between two zones. To evaluate a public transportsupply, additional skim data such as number of transfers, transfer wait time and servicefrequency must be considered.To determine these user-specific skims, the OD trips of travelers are modeled. A user choosesa route for his trip which appears convenient to him. If in addition to the route, the user alsoselects the departure time of his trip, one speaks of a connection independent of the mode. Inaddition to the spatial course, a connection thus comprises the entire temporal course: Inpublic transport especially the departure and arrival times at the boarding stop, at the transferstops and at the destination stop and in private transport the selected departure time, thearrival time and the transit time for each location along the route. If the temporal progression ofthe 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 takeplace 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.

189 © PTV AG

Chapter 4: Impact models

Methods to model the travel behavior are based upon search algorithms which determineroutes or connections between an origin and a destination. Procedures used as searchalgorithms are those which determine the best, meaning those which determine paths with thelowest impedance or a set of sufficient paths. Impedance can consist of times, distances, andcosts. Depending on the search algorithm used, the paths found represent routes orconnections. The trips by OD pair are distributed among the paths found. This combination ofpath search and trip distribution is called assignment. Private transport assignment assignsvehicle trips; public transport assignment assigns passenger trips.For every route or connection between two zones skims can be calculated which describe theservice quality of the route/connection. In addition to this, an assignment produces trafficvolumes for links and turns, and in PuT projects also for stops and stop points plus all objectsof the PuT line hierarchy from the transport system down to the level of individual service trips.In contrast to a quality skim such as, for example, journey time, the volume is only an indirectskim which by itself is not suited for evaluating the transport supply system. The volume israther 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 impactThus, the volume resulting from the user impact model serves as a basis for the proceduresprovided 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 bythe search algorithm and by the procedure used for distributing demand. These assignmentprocedures are a central part of VISUM. There are PrT models and PuT models.• PrT (see "User Model PrT" on page 195)• PuT (see "User Model PuT" on page 407)

4.1.2 The operator modelTransport supply operators are PuT transport companies and transport associations, in abroader sense these also include the PuT contractors of the operators. To offer public transportservice, PuT operators develop line networks and timetables from which the user can thenchoose connections.To estimate the impacts on PuT operators, the so-called operator model is used to determineindicators which describe the operational and financial requirements for offering publictransport supply on the one hand and on the other hand the expected revenues (see "Operatormodel PuT" on page 489). The PuT operator model comprises the following methods.• Line blocking which determines the number of required vehicles• Determining operational costs• Estimating revenues• Line costing which distributes the operational costs and revenues over PuT linesCompared 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 thegeneral public, rather than on the impacts on the operators themselves, which is why in generala different operator model has to be used for PrT. Here the economical analysis (EWS) impactmodel is available in VISUM. This model comprises methods on economical return ofinvestment analysis according to recommendations for economic feasibility studies published

190 © PTV AG

Chapter 4.2: Impedance functions

by the German FGSV (Road Traffic Research Association in Germany in 1997 (see "Economicassessment according to EWS" on page 625).

4.1.3 The environmental impact modelVISUM provides three models within the environmental impact model, to calculate theenvironmental impacts - noise and pollution emissions, caused by motorized private transport(see "Environmental impact model and HBEFA" on page 613).• Noise-Emis-Rls90: Calculation of noise emission levels in accordance with the guideline

on noise reduction for roads, edition 1990 (RLS-90), without considering immissionparameters.

• Noise-Emis-Nordic: Calculation of noise emission levels in accordance with NordicCouncil of Ministers (1996).

• Pollution-Emis: Calculation of air pollution emissions in accordance with emission factorsof the Swiss Federal Office for the Environment (BAFU).

4.2 Impedance functionsAn impedance function generally measures the effort connected to a traffic process. Allinstances are summarized to this effort, which prevent participants from carrying out thisprocess and therefore create an impedance. Effort examples are especially time and costsconnected to the process. You can also enter subjective criteria in the impedance. Thus, theimpedance of a certain connection in the PuT may increase, if certain comfort criteria are notsatisfied.Impedance functions play an important role in several impact models. In the assignment, theimpedance function assigns a route or connection an effort. In PrT, especially the journey timein the loaded network flows into the impedance, but it can also be additional properties such astraveling expenses and possible toll. For dynamic assignments, it is also the discrepancybetween the departure time and the desired departure time. In PuT, in addition to the traveltime, 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 haveto finally arise from conjoint evaluation in form of a number. These different aspects which arepartially measured in different units, must therefore be recalculated and weighted against eachother. In general, weighting of the factors for different groups of assessing personnel isdifferent. For this reason, impedance functions for example can be defined at the assignmentper demand segment (see User Manual, Chpt. 5.2, page 851) and at line blocking per vehiclecombination (see User Manual, Chpt. 7.1.3.2, page 1030).In VISUM, impedance functions are used in the following contexts.• Assignment (User model): The impedance function assigns the effort to each path, thus

depending on the type of assignment, each route or connection, which the passenger hasto make, if he decides to take this path. The most natural criterion is the travel time whichhas the corresponding unit time [s]. Especially in PrT, the travel time of a link is notconstant, but depends on the volume, the coherence is described in a VD function.

• Demand models (User model): Within the framework of trip distribution, mode choice, aswell as combined procedures for trip distribution and mode choice, the impedance functionassigns an OD pair or assigns the mode choice for this relation to the effort, which has to

191 © PTV AG


be overcome for this choice. In this context we are traditionally talking about utilityfunctions. Although the supporting concept is identical, the benefit of it is, however, only thenegative impedance of the process.

• Line blocking (Operator model): The impedance function assigns each activity (service trip,empty trip, layover, etc.) in a cycle the effort which arises, if the activity is performed by thiscycle. 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 certainaspect of the effort and is weighted by a coefficient (see illustration 54). To calculate theimpedance of a traffic process, the properties of the process are first determined regardingeach aspect. Each aspect is then evaluated separately, in PrT especially by evaluating the VDfunction. This evaluation of individual aspects is then provided and summed up with theweighting factors.

Illustration 54: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min]

4.3 Paths in PrT and PuTAll assignments in VISUM in PrT as well as in PuT are path-based, meaning that possiblepaths 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

192 © PTV AG

Chapter 4.4: Skims / indicators

loaded paths. These paths are saved with the assignment result and can be analyzed after theassignment for flow bundle calculation, for example.A path first describes the exact local course of a translocation in the network model, whichmeans, 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 departuretime and thus the temporal course is added to the spatial course, we are taking about aconnection, otherwise a route. For PuT paths, in addition to departure time for a connectioncompared to the route, the information on used service trips is included.If an assignment produces routes or connections depends on the type of assignment. DynamicPrT assignments and the timetable-based PuT assignment create connections, static PrTassignments as well as the headway-based PuT assignment calculate routes. In principle, theuser can select, whether internally calculated connections should be saved as such or only asroutes, or not at all – respectively for PrT (see User Manual, Chpt. 5.1.2, page 849) and PuT(see User Manual, Chpt. 6.1.1.2, page 944). If you do not save the connections, less memoryis required, however, posterior analyses of the connections are no longer possible, even if adynamic assignment procedure was applied. Network volumes are still calculated and caneven be output differentiated according to analysis time intervals.

4.4 Skims / indicatorsA skim is a measurement taken from the traffic model. Typical examples are the mean traveltime from a zone A to a zone B, which is calculated from the travel times of all paths found, aswell 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 xijfor the skim value, refers to the relation from zone i to zone j.Skims are generally there to calculate the properties of a traffic model. In feed back modelsthey are also the input data for the demand modeling procedure, especially for trip distributionand mode choice.

4.4.1 Skim matricesSkim matrices describe properties of each relation from an origin zone A to a destination zoneB in the traffic model. Each individual skim (for example the travel time in a vehicle) is extractedfrom the path properties from A to B, which belong to a demand segment. The skim data is thenaggregated with the relative share of demand, which the path would attract, to a skim value forthe OD pair. This also applies, if there is no demand for the relation from A to B, becausedistribution does not depend on the demand.The calculation of skim matrices differs between PrT and PuT on some points. The calculationof 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 thepossibly 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 directlyfrom this path. If, however, paths from an assignment are used for skim matrix calculation, thevalue of the minimum or maximum path impedance can be output as skim value, or theweighted or unweighted mean value calculated from all paths by OD pair.

193 © PTV AG


In PuT always more than one route or connection is calculated per OD pair, and the skim valueis derived from these. In addition to the average determination, optionally weighted with thedemand 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 wellas quantiles are available as additional aggregate functions. The skim is especially directlydependent on the applied search strategy. Because not only the saved, but all paths found areincluded in skim matrix calculation, the result differs from the result subsequently derived fromthe paths. This is the case, if the demand becomes zero on some paths by an explicitlyrequested rounding and the path is therefore not saved, but used for skim matrix calculation. Ifdemand and volume rounding is switched off, such differences cannot occur.

4.4.2 Global indicatorsIn addition to the skims by OD pair and demand segment, which are available in skim matricesand are only calculated on demand, VISUM automatically calculates a specified set of globalvalues with each assignment. These are properties of the total assignment results, i.e., thetraffic model itself. Typical values are the mean travel time in the network, the total vehicleimpedance in PrT, the total journey time of all PuT passengers, as well as the number ofpassenger trips by PuT line. The global values are displayed via lists (see "Evaluation lists" onpage 684).If several assignments are carried out subsequently, the global values represent the propertiesof all paths in these assignment results. Compared to the skim matrices, these values orientatethemselves towards the loaded paths contained in the result. They are thus consistent withproperties of the saved paths.

194 © PTV AG

5 User Model PrT

The User Model PrT calculates the effect of the infrastructure for private transport on all cardrivers and passengers, but also on non-motorized road users such as cyclists andpedestrians.

Subjects• Overview of the PrT assignment procedures• Example network for the PrT assignment procedures• PrT Paths• Impedance and VD functions• Impedances at node• PrT skims• Distribution of the traffic demand to PrT connectors• Blocking back model• Convergence criteria of the assignment quality• Distribution models in the assignment• Incremental assignment• Equilibrium assignment• Linear User Cost Equilibrium (LUCE)• Equilibrium_Lohse• Assignment with ICA• Stochastic assignment• TRIBUT• Dynamic User Equilibrium (DUE)• Dynamic stochastic assignment• NCHRP 255• Assignment analysis PrT

5.1 Overview of the PrT assignment proceduresVISUM provides several assignment procedures for the PrT. There are static assignmentprocedures without explicit time modeling as well as procedures which use a time dynamictraffic flow model.• The Incremental assignment divides the demand matrix on a percentage basis into

several partial matrices. Then, these partial matrices are successively assigned to thenetwork. The route search considers the impedance which results from the traffic volumeof the previous step (see "Incremental assignment" on page 296).

• The Equilibrium assignment distributes demand according to Wardrop's first principle,which is: „Every road user selects his route in such a way, that the travel time on allalternative routes is the same, and that switching to a different route would increase

195 © PTV AG

Chapter 5: User Model PrT

personal travel time.“. The state of equilibrium is reached by multi-successive iterationbased on an incremental assignment as a starting solution. In the inner iteration step, tworoutes of a relation are brought into a state of equilibrium by shifting vehicles. The outeriteration step checks if new routes with lower impedance can be found as a result of thecurrent network state (see "Equilibrium assignment" on page 301).

• The Equilibrium assignment LUCE uses the LUCE algorithm, which was conceived byGuido Gentile. He collaborated with PTV to produce a practical implementation of themethod in VISUM. Exploiting the inexpensive information provided by the derivatives of thearc costs with respect to arc flows, LUCE achieves a very high convergence speed, whileit assigns the demand flow of each OD pair on several paths at once (see "Linear User CostEquilibrium (LUCE)" on page 312).

• The Equilibrium_Lohse assignment models the "learning process" of road-users in thenetwork. Starting with an "all or nothing assignment", drivers consecutively includeinformation gained during their last journey for the next route search (see"Equilibrium_Lohse" on page 324).

• The Assignment with ICA brings the impedances at junctions into focus. It explicitlyregards lane allocations and further details. Especially the interdependencies between theindividual turns at a node are considered. With other assignment procedures, the detailedconsideration of node impedances usually leads to an unfavorable convergence behavior.The assignment with ICA uses turn-specific volume-delay functions which are continuouslyre-calibrated by means of the ICA. This leads to a significantly improved convergencebehavior (see "Assignment with ICA" on page 332).

• The Stochastic assignment takes into account the fact that skims of individual routes(journey time, distance, and costs) that are relevant for the route choice are perceivedsubjectively 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, whichare not shown in the model. In practice, the two effects combined result in routes beingchosen 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 isdistributed across the alternatives on the basis of a distribution model (e.g. Logit) (see"Stochastic assignment" on page 342).

• The TRIBUT procedure, which was developed by the French research associationINRETS, is particularly suitable for modeling road tolls. Compared to the conventionalprocedures which are based on a constant time value, TRIBUT uses a concurrentdistributed time value. A bicriterial multipath routing is applied for searching routes, whichtakes the criteria time and costs into account. Road tolls are modeled as transport system-specific road toll value, either for each VISUM route or for link sequences between user-defined nodes (non-linear toll systems) (see "TRIBUT" on page 353).

• In co-operation with the University of Rome, VISUM provides the Dynamic UserEquilibrium (DUE). Additionally, it can regard time-varying capacities as well as road tollsand includes a departure time choice model (see "Dynamic User Equilibrium (DUE)" onpage 367).

• The Dynamic Stochastic assignment differs from all the previously named procedures asa result of the explicit modeling of the time axis. The assignment period is divided intoindividual time slices, with volume and impedance separated for each such time slice. Foreach departure time interval, the demand is distributed across the available connections (=

196 © PTV AG

Chapter 5.2: Example network for the PrT assignment procedures

route + departure time) based on an assignment model as in the case of the stochasticassignment. With this modeling, temporary overload conditions in the network aredisplayed, a varying choice of routes results in the course of the day, and possibly also ashift of departure time with respect to the desired time (see "Dynamic stochasticassignment" on page 396).

For each of the mentioned assignment procedures any number of demand matrices can beselected 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 assignedsimultaneously.

Abbreviations which are used together with the User Model PrT, shows the Table 45.

5.2 Example network for the PrT assignment proceduresThe way the PrT assignment procedures work is described with the example illustrated inillustration 55. The example analyzes the relation between traffic zone A-Village and trafficzone X-City. The following assumptions apply:• Access and egress times are not considered, that is, they are set to 0 minutes.• Turn penalties are not considered.• Capacity and demand refer to one hour.• Traffic demand between A-Village and X-City consists of 2,000 car trips (car.fma matrix)

during the peak hour.• To explain simultaneous assignment of multiple demand matrices 200 additional HGV trips

(hveh.fma matrix) are considered. One HGV corresponds to two car units.

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]

R Impedance = f (tCur)

q Volume of a network object [car units/time interval] = sum of volumes of all PrT transport systems including basic volume (preloaded volume)

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.

F Demand matrix which contains the demand for all OD pairs.

Table 45: Abbreviations used in the User model PrT.

q qi PCUi⋅( )i 1=

NumTSys∑ qpreloadedVolume+=

197 © PTV AG


• On federal roads (link type 20) there is a speed limit of 80 km/h for HGVs.The example network contains three routes which connect A-Village and X-City. The routesrun 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 – 40Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 kmlong. It is the fastest route because the federal road can be traversed at a speed of 100 km/hif there is free traffic flow. Route 3 which is also 30 km long is an alternative route which only makes sense if the federalroad is congested.

Illustration 55: Example network

LinkNo

From Node

To Node Type Length [m] Capacity [car units/h] v0-PrT [km/h]

1 10 11 20 Federal road 5000 1200 100

2 11 20 20 Federal road 5000 1200 100

3 20 21 20 Federal road 5000 1200 100

4 20 40 90 Rail track 10000 0 0

5 21 30 20 Federal road 5000 1200 100

6 30 31 20 Federal road 5000 1200 100

7 31 40 20 Federal road 5000 1200 100

8 11 41 30 Country road 16000 800 80

Table 46: Example network

11

21

20

10

12

41

40

3130

village A

city X

1

2 9

6 5

8

11

7 3

10

198 © PTV AG

Chapter 5.3: PrT Paths

The example network from Table 46 can be found in the directory...\VISUM115\Examples\Example_net.• Version file: Example.ver• Assignment parameters file: Auto.par

5.3 PrT PathsAll assignments in VISUM in the PrT as well as in the PuT are route based. This means thatpossible paths in the assignment are calculated for each origin-destination relation and loadedwith a demand share. All other results, especially the different network object volumes and theskim matrices are derived from these loaded paths. Paths are therefore the central result of theassignment procedure.Table 47 displays the PrT paths provided by an equilibrium assignment in Example.ver, in link-based display.

9 40 41 30 Country road 5000 800 80

10 10 12 40 Other roads 10000 500 60

11 12 21 40 Other roads 5000 500 60

LinkNo

From Node


Table 46: Example network

Origin zone Destination zone

Path index Index Link From node To node

100 200 1

1 1 10 11

2 2 11 20

3 3 20 21

4 5 21 30

5 6 30 31

6 7 31 40

100 200 2

1 1 10 11

2 8 11 41

3 9 41 40

100 200 3

1 10 10 12

2 11 12 21

3 5 21 30

4 6 30 31

Table 47: Link-based PrT paths of a PrT assignment

199 © PTV AG


For private transport, you can edit paths manually, because paths are available as networkobjects here (see "Paths" on page 40).

5.4 Impedance and VD functionsSubjects• Impedance of a PrT route• Predefined VD functions• Example of the calculation of the link impedance• User-defined VD functions

5.4.1 Impedance of a PrT routeAll assignment procedures are based on a short-route algorithm that determines lowimpedance routes. The impedance of a PrT route is volume-dependent and consists of thefollowing impedances:• Impedances of used links (see "Impedances of links" on page 201)• Impedances of used turns, which are also called 'node impedance' (see "Impedances at

node" on page 210)• Impedances of the used connectors (see "Impedances of connectors" on page 201)• Impedances of the used main turns (see "Impedances of main turns" on page 202)The route choices of travelers depend on objective and subjective factors. The route choice isparticularly determined by the following skims:• The anticipated travel time for the route• Route length• Possible road tollsIn addition to this, a multitude of other factors can influence route choice. One can imagine, forexample, that road users who know their way around will choose other routes than people whodo not know the area and who mainly orient themselves according to the sign-posted trafficnetwork. Impedance is therefore defined for each transport system and can be customized bythe user. By default, it depends on the following variables:• 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 [-]

5 7 31 40

Origin zone Destination zone

Path index Index Link From node To node

Table 47: Link-based PrT paths of a PrT assignment

200 © 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 indirectnumerical attributes of the network objects links, turns, connectors and main turns, for thedefinition of the impedance of a route (see User Manual, Chpt. 5.2.2, page 867).When composing the impedance summands, it can be differentiated between two basiccomponents:• 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 withincreasing traffic volume, all assignment procedures are in turn based on the assumption thattravel times of network objects are a monotone incremental function of traffic volume. Thus, incase of increased traffic in the network the effect of deterrence to alternative routes can bemodeled (see "Predefined VD functions" on page 202).Because the variables have different units (seconds, meters, money units), impedance cannotbe written in a universally applicable unit. For a combination of the variables, travel time, androad 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 linksFor every PrT-transport system of a link, a TSys-specific travel time (t0_TSys) for free flow isdefined 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 timedepending on the current traffic volume (see "Predefined VD functions" on page 202).

Impedances of turns (Impedances at node)VISUM calculates turn impedances for every turn permitted at a node. A turn impedanceincludes an impedance time penalty t0 which increases in dependence on volume andcapacity. Because the turns are positioned at the node, the impedances at turns are oftendescribed as impedances at node (see "Impedances at node" on page 210).

Impedances of connectorsConnector impedances are regarded as follows:• Absolute connectors are regarded as being volume-dependent. This means, that the TSys-

specific connector time (t0_TSys) does not represent actual impedance which is volume-independent.

• For connectors defined by percentage, they are regarded as volume-dependent, if theoption Connector weights apply to total trips (MPA off) is active. This means, that withincreasing volume the actual connector time tCur_TSys will exceed the connector timet0_TSys of each connector (see "Predefined VD functions" on page 202). With a high value

201 © PTV AG


for parameter b in the VD function and usage of the equilibrium assignment, a relativelyexact distribution of traffic onto the connectors can be achieved.

Impedances of main turnsJust like turn impedances, in VISUM main turn impedances are calculated for each main turnpermitted at a main node based on the volume and selectively a VD function, TModel or ICA.

Preloaded volumeWhen impedances are determined, preloaded volumes can be considered. Preloaded volumescan be either user-defined additional values or volume values which result from theassignment of a different matrix.

5.4.2 Predefined VD functionsTravel times for PrT are determined by the saturation of links and turns which result from thetraffic volume and the capacity of these network objects. Due to this, PrT travel times vary incontrast to PuT journey times, and can only be anticipated to a certain degree before a trip. ThePrT travel time of a route between two zones consists of the following components:• Access and egress times• Travel time on links• Turn time at intersectionsFor free traffic flow, the travel time t0 of a link can be determined from the link length and thefree-flow speed v0. For turns at an intersection, the turn time t0 is specified directly. In loadednetworks, the link travel time and the turn time is determined by a so-called volume-delayfunction (or VD function). This capacity restraint function describes the correlation between thecurrent traffic volume q, and the capacity qMax. The result of the VD function is the travel timein the loaded network tCur. VISUM provides several function types for the volume-delayfunctions:1. the BPR function from the Traffic Assignment Manual of the United States Bureau of Public

Roads (illustration 56)2. a modified BPR function with a different parameter b for the saturated and unsaturated

state (Table 50)3. a modified BPR function, for which an additional supplement d per vehicle can be specified

in the saturated state (Table 51)4. the INRETS function of the French Institut National de Recherche sur les Transports et leur

Sécurité (illustration 57)5. a constant function where the capacity does not influence travel time (tCur = t0)

Note: The impedance of turns and connectors in contrast to links only depends on thevariable tCur and possibly on the AddValue. Because the impedance of a connector is notcapacity-dependent, the following applies to the access and egress impedance: tCur = t0. Theproportional distribution of traffic demand onto different connectors is, however, reachedthrough 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 totaland the demand to be assigned in the current assignment, e.g. Vol(car-business) + Vol(car-private) + Demand(HGV) = 100% Connector capacity.

202 © PTV AG


6. and several functions for turning processes (i.e. t0 is added, not multiplied) as well asfunction type linear bottleneck which are used by turn type

7. the function ICA-Turn, which is used by lane for precise calculation of turn impedances andcapacities via Intersection Capacity Analysis

8. another modified BPR function (LOHSE) with a linear rise in the oversaturated section, inaccordance with the queuing theories, in order to achieve more realistic times in theoversaturated section and a better performance in assignments since small changes to thevolume do not result in disproportionate travel time changes. The function is monotonic,continuous, and differentiable even where sat = satcrit

Table 48 shows the variables used in the descriptions of the VD functions.

The parameters mentioned in Table 49 apply to all VD functions. Function-specific parametersare listed with the respective VD function.

Note: In addition to the volume-delay functions provided in VISUM, you can also specifyuser-defined VD functions (see "User-defined VD functions" on page 209).

sat

Volume/capacity ratio

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]

q Current volume = sum of volumes of all PrT transport systems including preloaded volume [car units/time interval]

qmax Capacity [car units/time unit]

Table 48: Variables used in VD functions

a, b ,c User-defined parametersa ∈ [0.00;∞), b ∈ {0.00...10.00}, c ∈ [0.00;∞)

Table 49: Parameters for all VD functions

cmaxqqsat

•=

q qi PkwEi⋅( )i 1=

NumTSys∑ qpreloadedVolume+=

203 © PTV AG


Illustration 56: 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 50: VD function type BPR2: modified BPR

satcrit satcrit = 1

a, b, c, d a ∈ [0.00;∞), b ∈ {0.00 ...10.00}, c ∈ [0.00;∞), d ∈ {0.00...100.00}

Table 51: VD function type BPR2: modified BPR

with

a, c a ∈ [1.1;100), c ∈ [0.00;100)

Table 52: VD function type CONICAL (Spiess)

Volume-delay graph for a=1 and c=1, tCur = t0 • f(q/qMax)

0

1

2

3

4

5

6

7

8

9

10

0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6

q / qMax

f(q/q

Max

) b = 2b = 3b = 4b = 5

204 © PTV AG


A marginal-cost version of the CONICAL function, proposed by Spiess to calculate a systemoptimum instead of user optimum in equilibrium assignment.

The function models queuing at entry legs whose inflow is restricted by ramp metering signals.

with

a, c a ∈ [1.1;100), c ∈ [0.00;100)

Table 53: VD function type CONICAL_MARGINAL

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 54: VD function type EXPONENTIAL

satcrit satcrit = 1

q current volume = sum of volumes of all PrT demand segments [car units/time unit] including basic volume (preloaded volume)

a user-defined parameter a ∈ {0.00..1.10}

c user-defined capacity parameter c ∈ [0;∞)

Table 55: VD function type INRETS

q qi PkwEi⋅( )i 1=

NumDSeg∑ qpreloadedVolume+=

205 © PTV AG


Illustration 57: VD function type INRETS

The impedance functions listed in Table 56 are particularly suited to the modeling of turnimpedances. 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 a, b, c, d ∈ [0.00…100.00}, f ∈ {0.00...10.00}. The value of parameter f of VD function types SIGMOIDAL_MMF_NODES and SIGMOIDAL_MMF_LINKS ranges from 0..100.

Table 56: VD function types LOGISTIC, QUADRATIC, SIGMOIDAL_MMF_NODES,SIGMOIDAL_MMF_LINKS

AKCELIK

Table 57: VD function type AKCELIK

Volume-delay graph for c=1, tCur = t0 • f(sat)

0

1

2

3

4

5

6

7

8

9

10

0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1,1 1,2 1,3 1,4 1,5 1,6

sat

f(sat

)

a = 0,0a = 0,2a = 0,4a = 0,6a = 0,8

206 © PTV AG


The function describes delays at nodes witha = duration in hoursb = family parameterd = capacity of lane per hour

AKCELIK2

a = duration in hoursb = family parameterd = 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 58: VD function type AKCELIK2

a, b, t0 Attributes of the particular (main) turna: Final A for assignment with ICAb: Final B for assignment with ICAt0: Final t0 for assignment with ICAThese are calculated attributes, which cannot be edited by the user.

satcrit satcrit = 1.1

b‘ b‘ = 3b (thus more steeply compared to sat ≤ satcrit)

a‘ a‘ =

t0‘ t0‘ =

a‘ and t0‘ These values have been selected, so that both branches are differentiatedly linked together for sat = satcrit.

Table 59: VD function type ICA-Turn (illustration 100, query 2: Is the turn share T below p2?“)

Table 57: VD function type AKCELIK

tcur sat( )t0 a satb⋅+ sat s≤ atcrit

t0' a' s⋅ atb'+ sat s> atcrit⎩⎪⎨⎪⎧

=

a3--- satcrit

b b'–⋅

t0 a satcritb⋅ a' satcrit

b'⋅–+

207 © PTV AG


Illustration 58: VD function type LOHSE

Some projects may require non-standard VD functions, e.g. because they include further linkattributes or because the conversion of volumes to passenger car units (PCUs) is project-specific. In this case, you can add your own functions to the pre-defined volume-delayfunctions (see "User-defined VD functions" on page 209).

satcrit satcrit ∈ [0.00;10]

a [(a + 1) • t0] represents tCur with sat = 1a ∈ [0.00;1000]

b Determines the value of the increasing rise up to sat = satcritb ∈ [0.00;10]

c Scaling parameter for the determination of the dimensions of q and qmaxc ∈ [0.00;100]

Table 60: VD function type LOHSE

Linear bottleneck

This function type stems from Metropolis and should not be used in static assignments, as it rises strongly when reaching the saturation while the previously augmenting VolCapRatio is unaccounted for.

Table 61: VD function type Linear Bottleneck

LOHSE

0,0

5,0

10,0

15,0

20,0

25,0

30,0

35,0

40,0

45,0

0,00

0,10

0,20

0,30

0,40

0,50

0,60

0,70

0,80

0,90

1,00

1,10

1,20

1,30

1,40

1,50

1,60

1,70

1,80

1,90

2,00

2,10

2,20

2,30

2,40

2,50

sat

tcur

b=2b=3b=4b=5

208 © PTV AG


5.4.3 Example of the calculation of the link impedanceTable 62 to Table 65 show an example in which link impedance consists of the current traveltime and road toll. For HGV transport systems which have a higher "value of time" the influenceof road tolls on link impedance is less than for car transport systems.

5.4.4 User-defined VD functionsYou can set up user-defined VD functions for the following use cases:• To include further attributes for links, turns and connectors in the calculation • To calculate PCUs in a non-standard way

Link length 10000 m

Permitted maximum speed v0 car 130 km/h

Permitted maximum speed v0 HGV 100 km/h

Road toll for cars 1 €

Road toll for HGV 5 €

Capacity 3000 car units/h

Car volume 1000 cars/h = 1000 car units/h

HGV volume 100 HGV/h = 200 car units/h

Value of time VOTcar 18 €/h = 0.005 €/s

Value of time VOTHGV 36 €/h = 0.010 €/s

VD function according to BPR with a = 1, b = 2, c = 1

Table 62: Input data of the calculation of the link impedance

Car travel time in unloaded network t0 car = 10000 • 3.6 / 130 = 277s

Car travel time in loaded network tCur car = 277 • (1+(1200/3000)²) = 321s

Car speed in loaded network vCur car = 10000 • 3.6 / 321 = 112 km/h

Table 63: Car travel times and speeds

HGV travel time in unloaded network t0 HGV = 10000 • 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 64: 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 65: Calculation of link impedance for HGV and car

209 © PTV AG


• To define separate volume-delay functions for different transport systems Volume-delay functions are very often evaluated within the assignment methods, socomputational efficiency is a key consideration. Therefore VISUM adopts a compiled ratherthan an interpreted approach to user-defined volume-delay functions. Users program theirfunctional forms as a dynamic-link library (DLL) following a given template. All such *.dll filesneed to be copied into the following project directory, which is created during the installationand which VISUM scans at start-up. %APPDATA%\VISUM115\Data\UserDefVDF (see UserManual, Chpt. 5.2.1.6, page 858).

5.5 Impedances at nodeIntersections are modeled as nodes or as main nodes in VISUM. Intersections of roads and/orrailway tracks are bottlenecks in an urban transport network. At the intersections, conflictpoints have to be passed in succession by the non-compatible traffic flows. The order in whichthe flows traverse the conflicting areas depends on the type of control:To choose the route within an assignment procedure, the impedance on alternative routes isdecisive, which results in the sum of impedances of all traversed network objects. Thebottleneck effect of a node is thus displayed for all variants of the traffic control by theimpedance of the turn used. The impedance of turns usually corresponds exactly to the traveltime 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 differentcompromises between data entry and computing time on the one hand and accuracy and real-life situations on the other.• Turns VD functions (see "Impedance of turns from Turns VD function" on page 212)• Nodes VD functions (see "Impedance of turns from Nodes VD function" on page 212)• Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the

Highway Capacity Manual (ICA)" on page 213)• To use ICA during assignment, select method Node impedance calculation (ICA).• Alternatively you can – based on an assignment result – select method From previous

assignment with ICA.Comparing advantages and disadvantages in Table 66 is to help you choose the appropriatecalculation model for your project.

Note: A *.bmp file with identical file name which is stored in the same folder will be displayedfor VDF selection.

Model Advantage Disadvantage

Turns VD functions (see "Impedance of turns from Turns VD function" on page 212)

• Little input complexity (per turn merely capacity and t0)

• Calculation fast• Assignment fast convergence

• Time required for the turning movement only takes the turning volume into account, not the amount of possible conflicting volumes (separable cost functions)

Table 66: Advantages and disadvantages of the node impedance model

210 © PTV AG

Chapter 5.5: Impedances at node

Due to the reasons mentioned we recommend the following for the selection.• For comprehensive models, modeling with VD functions for turns or nodes is appropriate.

ICA cannot be recommended here, because the input complexity for the detailed supply ofnodes with geometry and control data is usually too high. Furthermore, the result after eachacceptable computing time due to the slow convergence of the assignment still containsapproximation 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 theperformance of one or more nodes of an existing assignment result. This is how you candetermine which aspects of the node contribute to a high impedance. It is thereforesufficient to only model those nodes completely which have to be analyzed. Within an assignment we only restrictedly recommend ICA, due to the known convergenceproblems and just for small scale studies with several 100 nodes. With an equilibrium assignment, best results can be achieved with either theEquilibrium_Lohse method (see "Equilibrium_Lohse" on page 324) or the From

Nodes VD functions (see "Impedance of turns from Nodes VD function" on page 212)

• Input complexity only slightly larger than for turn VD functions (additionally capacity and t0 for the node itself as well as designating subordinated links)

• Calculation fast• For subordinate turns at two-way

stop nodes, the time required due to its own volume increases by an additional penalty, which depends on the total volume/capacity ratio of the node and therefore on the volumes of conflict flows.

• Assignment convergence slower due to the inseparable penalty

• Compared to ICA, taking conflicting volumes into account is extremely simpler due to the fixed penalty

Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the Highway Capacity Manual (ICA)" on page 213)

• Impedance calculation precisely considers lane allocation and signal control. Special turn pockets for example, are capacity-increasing and dependent on the entered signal timing, protected and permitted turns are calculated correctly

• Input complexity considerably higher: Instead of capacity and t0, model the lane allocation at the node and - where available - the signal control in detail

• Calculation more time consuming• Assignment convergence slow due to

the inseparable impedance model, sometimes without additional measures not at all

Node impedance calculation by lane turn (see "Assignment with ICA" on page 332)

• Convergence is reached by regular adjustment of the Turns VDFs to the wait times and capacities calculated by ICA.

• The HCM 2000 method used for ICA regards the lane allocation and conflicting turn flows in detail.

• Increased efforts required for the comprehensive modeling of geometry and control at the nodes to be regarded.

• Comparably computation time-consuming.

Model Advantage Disadvantage

Table 66: Advantages and disadvantages of the node impedance model

211 © PTV AG


previous assignment with ICA method(see "Assignment with ICA" on page 332), sincethese are more robust towards impedance variations.

In most cases you will globally decide on a calculation model. You can however also combinedifferent calculation methods within a network, (for example, Turns VD functions as standardmodel and ICA simply for very important nodes with complex lane allocation or large conflictingflows).All calculation models are based on turn volumes in car units per hour, which are determinedthrough the user's settings, either from the assigned volume or from counted data via a factor.

5.5.1 Impedance of turns from Turns VD functionIn the simplest calculation model tCur, the time requirement of a turning vehicle is calculatedfrom 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" onpage 202) as VD functions or select a user-defined functional form (see "User-defined VDfunctions" on page 209). Typical Turn VD functions make up the sum (not the product) of t0 anda saturation-dependent term. An example for this is, are the VD functions Akcelik, Exponential,Constant, Logistic, Quadratic and TMODEL_Nodes.The attributes mentioned in Table 67 are considered for the calculation.

5.5.2 Impedance of turns from Nodes VD functionIn this model, turn delays are calculated in two steps. First, a node delay is calculated byapplying a VD function to the vol/cap ratio of the node. Each turn penalty is the sum of nodedelay and the turn-specific time (calculated with VD function set for turns). Node delay only hasan affect on turns from a non-prioritized approach. This approach links have to be marked withthe attribute TModelSpecial (see User Manual, Chpt. 2.39, page 492).The attributes mentioned in Table 68 are considered for the calculation.

Network object

Attribute Description / Effect

Turn Capacity PrT

The capacity of the turn in PCUs/hour

Turn t0 PrT The time required for a turning movement in unloaded state

Turn Type Usually specifies the direction of the turn

Table 67: Attributes for the impedance calculation from Turns VD function

Network object


Turn Capacity PrT

The capacity of the turns in PCUs/hour

Turn t0 PrT The time required for a turning movement in unloaded state

Turn Type Usually specifies the turning direction

Node Capacity PrT

The total capacity of the node in PCUs/hour

Table 68: Attributes for the impedance calculation from Node VD function

212 © PTV AG


Turn time penalties are calculated according to the following formula:vol(n) = Σvol(t)delay(n) = vdf (cap(n), vol(n))delay(t) = vdf (cap(t), vol(t))IF n has no link with TModelSpecial = 1, THENtCur(t) = delay(t) + delay(n) for all turns t via node n

IF n has at least one link with TModelSpecial = 1, THENtCur(a) = delay(t) for all turns t with a 'from link' to which TModelSpecial = 0 appliestCur(a) = delay(t) + delay(n) for all turns t with a 'from link' to which TModelSpecial = 1 applies

5.5.3 Intersection Capacity Analysis according to the Highway Capacity Manual (ICA)VD functions are usually used to model volume-dependent travel times on links (see"Impedance and VD functions" on page 200). They can also be used to model volume-dependent wait times for turns or complete nodes (see "Impedance of turns from Turns VDfunction" on page 212 and "Impedance of turns from Nodes VD function" on page 212).By contrast the Highway Capacity Manual (HCM) published by the US TransportationResearch Board contains internationally recognized guidelines on calculating the level ofservice and other performance indicators for intersections, based on the detailed junctiongeometry and various control strategies. VISUM computes performance indicators such ascapacity, delays or LOS either according to the guidelines defined in the operation model HCM2000 or according to HCM 2010 guidelines.

For intersection points of the same level, the calculation differentiates between the followingcontrol types (attribute control type at node):• Uncontrolled nodes (see "Uncontrolled nodes" on page 214)• Signalized intersections (see "Signalized nodes (HCM 2000 Chapter 16)" on page 214)• Static priority rules using the traffic signs StVO 306 or 301 (German road traffic regulations)

for the main road and StVO 205 or 206 for the subordinate road (see "Two-Way Stops(HCM 2000 Chapter 17)" on page 234)

• All-Way stops (only for North America) (see "All-Way stop (HCM 2000 Chapter 17)" onpage 243)

Node t0 PrT The additional time required for a non-prioritized turning movement (all the same) in unloaded state

Network object


Table 68: Attributes for the impedance calculation from Node VD function

Note: In the following the implementation of the HCM 2000 in VISUM is described. For mostof the control types (except for signalized nodes), the HCM 2010 differs from the HCM 2000in only a few aspects. The deviating portions are highlighted in the text. Since the HCM isprovided in English only, certain English expressions and descriptions have not beentranslated in the German VISUM manual for a better traceability in the original document.

213 © PTV AG


• RoundaboutsVISUM 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 GeometricDesign of Roundabouts", is based on the empirical study of numerous roundabouts and thestatistical adjustment of a model which estimates capacities in dependency of the geometry(see "Roundabouts according to the TRL/Kimber 2010 method" on page 254).

• The method described in the Highway Capacity Manual 2010, chapter 21 (see"Roundabouts according to the HCM 2010 method" on page 250).

The method according to TRL/Kimber has the advantage of taking comprehensive empiricalresults on the influence of geometry on the permeability of a roundabout into consideration andhas been successfully implemented for nearly three decades.The method according to HCM is recommended, if in theory you prefer consistency for allcontrol 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 onlyobtained through driving behavior studies in Great Britain.

5.5.3.1 Uncontrolled nodesFor uncontrolled nodes the impedance of a turn is calculated using a VD function from the nodevolume (= Sum of turn volumes) and the node capacity, therefore exactly like calculating themodel Nodes VD function (see "Impedance of turns from Nodes VD function" on page 212),however without a term for each turn.The VISUM attributes listed in Table 69 are considered for the calculation.

5.5.3.2 Signalized nodes (HCM 2000 Chapter 16)

Notes: Throughout the model description, special provision for right or left turns relates toright-hand traffic. For VISUM models with left-hand traffic the roles of right and left turns arereversed (see User Manual, Chpt. 1.4.1, page 58).U-turns are never considered in HCM 2000. In VISUM it is possible to treat U-turns as far leftturns through the corresponding setting in the procedure parameters for intersectionimpedance analysis (in left-hand traffic accordingly as far right turns). This calculation is thenno longer HCM conform. HCM 2010 regards U-turns at two-way stop nodes. Here, theprocessing is performed according to HCM 2010 in VISUM. Other control types areprocessed according to HCM 2000.

Network object


Node Capacity PrT The total capacity of the node in PCUs/hour

Node t0 PrT The time required in a turning movement (all equal) in unloaded state

Table 69: Attributes for the calculation regarding uncontrolled nodes

Note: In the HCM 2010, signalized nodes are described in chapter 18.

214 © PTV AG


The basic flow chart for performing capacity analyses for signalized intersections is displayedin illustration 59. You input the intersection geometry, volumes (counts or adjusted demandmodel volumes), and signal timing. The intersection geometry is deconstructed into lane (orsignal) groups, which are the basic unit of analysis in the HCM method.A lane (or signal) group is a group of one or more lanes on an intersection approach having thesame green stage. For example, if an approach has just one pocketed exclusive left turn andone shared through and right turn, then there are usually two lane groups – the left and theshared through/right.

The volumes are then adjusted via peak hour factors, etc. For each lane group, the saturationflow rate (SFR), or capacity, is calculated based on the number of lanes and variousadjustment factors such as lane widths, signal timing, and pedestrian volumes. Havingcalculated the demand and the capacity for each lane group, various performance measurescan be calculated. These include, for example, the v/c ratio, the average amount of controldelay by vehicle, the Level of Service, and the queues.

Illustration 59: Capacity analysis process for signalized nodes

If you use the HCM 2000 or HCM 2010 operations model for signalized nodes, the VISUMattributes in Table 70 will have an effect. Make sure that they are set to realistic values prior torunning the analysis.

Note: According to HCM 2010, the lane allocation follows different rules. Here, shared lanesalways form a separate lane group. For more details, please refer to HCM 2010, page 18-33.

Note: For HCM 2010, the corresponding flow diagram can be found in HCM 2010, page 18-32.

I nputsGe om etryV olum es

S ig nal tim in g

La ne G roups & Dem and Adj

L an e Gro uping sP ea k h our fa ctor

S aturation F low Ra te (Capa city)

Ba sicsA djus tm en t Fa ctors

C apac ity AnalysisV /C Ra tio

A verage DelayL evel o f S ervice

Qu eue s

215 © PTV AG


Alternatively to the calculation method according to HCM, you can apply one of the followingmethods:• ICU1• ICU2• Circular 212 Planning• Circular 212 OperationsThese methods differ from HCM 2000 in only two aspects:• Definition of the ideal saturation flow rate• Calculation of the final saturation v/s (volume/saturation flow rate) for the node• Determination of the Level of Service (LOS)The steps 6, 9 and 13 below describe the calculation variants in detail.

Note: VISUM supports the connection of external RBC controls. These are no fixed timecontrols. HCM 2010 provides a calculation method for those controls. This method has beenimplemented in VISUM. For the description of this method, please refer to HCM 2010, page31-10 et seqq.

Network object Attribute Description / Effect

Link ICAArrivalType Level of platooning in traffic arriving at the ToNode, subsequently used in the steps 10 + 14a

Link ICAUpstreamAdj Adjustment factor for upstream filtering / metering, used in the steps 10b + 14b

Link ShareHGV Proportion of heavy goods vehicles, used in step 6b. One value applies to all turns originating from the link

Link Space required per car unit

Used in step 6 for the calculation of the number of vehicles that fit on a pocket lane

Link Slope Used in step 6

Node ICAPHFVolAdj Initial volume adjustment to peak period; volumes are multiplied with both node and turn adjustment factors

Node ICALossTime Used in step 9 Only needed for signal group-based signal control or if no signal control is modeled. For other types of signal control the value is inferred automatically.

Node ICASCActualCoordinated

Indicates whether the SC is coordinated

Node ICAIsCBD Is the node located in the Central Business District?, used in Step 6e

Node Sneakers Number of vehicles which can line up in the node area during a cycle. The value in [veh] applies to all movements at the node The cycle time is used for the minimum capacity calculation for each movement.

Node SC number Points to the signal control

Geometry All Geometry data of lanes, lane turns and crosswalks

Table 70: Input attributes for signalized nodes

216 © PTV AG


Turn ICAPHFVolAdj Initial volume adjustment to peak period; volumes are multiplied by both node and turn adjustment factors

Turn LaneWidth Lane width, used in step 6a

Turns ICA preset saturation flow rate

Overwrites optionally the global saturation flow rate in the procedure parameters. Can be overwritten by the specific lane value of this attribute, if applicable.

Signal Control All Definition of signal groups, stages (where applicable), and signal timing

SCJ Used intergreen method Is used in step 9 for loss time calculations

Signal group ICA loss time adjustment Is added to the actual green time. The actual green time and ICA loss time adjustment sum up to the green time on which all computations are based.

Leg ICA bus blockage Adjustment factor for the saturation flow rate for consideration of bus stops.

Leg ICA parking Adjustment factor for the saturation flow rate for consideration of parking events.

Leg Bicycle volume Number of bicyclists per hour for the determination of the adjustment factor for the saturation flow rate.

Lane Number of vehicles User-defined number of vehicles ≥ 0.0 the pocket accommodates. This attribute is only regarded if the attribute Use number of vehicles is true and if the global procedure parameter 'Regard pocket length for saturation flow rate calculation' is active.

Lane Use number of vehicles Decision, whether NumVehicles of the lane shall be used. If this attribute is not true, the number of vehicles is determined from the pocket length and the attribute Space required per car unit.

Lane Length Lane length if pockets are concerned. This attribute is only regarded if the attribute Use number of vehicles is not true and if the global procedure parameter 'Regard pocket length for saturation flow rate calculation' is active. The number of vehicles is calculated from the length of the pocket and the attribute Space required per car unit.

Lane ICA preset saturation flow rate

Saturation flow rate for the lane after consideration of all adjustment factors. Use this attribute to set the saturation flow rate directly, if the HCM-based adjustment factors do not reflect the actual circumstances of the lane. This value overwrites the procedure parameter value and also turn-related values, if applicable.

Lane ICA use preset saturation flow rate

Decision, whether the internally calculated saturation flow rate shall be replaced by the ICA preset saturation flow rate value.



217 © PTV AG


Output is possible through the attributes listed in Table 71.

Lane ICA user-defined utilization share

Utilization share of the lane within a multi-lane group. The sum of the input shares is automatically scaled to 100%, thus you can enter relative weights per lane. This value is used in step 6.

Lane ICA use user-defined utilization share

Decision, whether the internally calculated utilization share shall be replaced by the ICA user-defined utilization share value.

Crosswalk Pedestrian volume Number of pedestrians per hour for the determination of the adjustment factor for the saturation flow rate.

Notes: The link attribute Turn on red is not regarded for calculation.The value Width of lanes is not regarded for calculation. Instead, the value Lane width ofturns is regarded.

Network object


Node VolDesign [Veh] PrT… The volume in [veh/h] passed into the HCM calculation, as defined in the procedure parameters

Node VolDesign [PCU] PrT… The volume in [PCU/h] passed into the HCM calculation, as defined in the procedure parameters

Node DesignVolCapRatio PrT The volume/capacity ratio based on the above design volume

Node TurntCurMax/Mean/Tot Sum, average, max of turn tCur. Now obsolete, since available as indirect attributes, but retained for backward compatibility.

Node LOS

Node LOSAvgDelay

Turns VolDesign [Veh] PrT… The volume in [veh/h] passed into the HCM calculation, as defined in the procedure parameters

Turn VolDesign [PCU] PrT… The volume in [PCU/h] passed into the HCM calculation, as defined in the procedure parameters

Turn ICAFinalSatFlowRate After all adjustments

Turn ICAFinalVol After all adjustments

Turn ICAFinalCap Effective capacity, taking into account all opposing flows etc.

Turn ICABackOfQueueForDefPerc Percentile of queue length. Specify in the procedure parameters which percentile is calculated.

Turn tCur-PrTSys TSys-specific travel time tCur in loaded network

Turn LOS Level of service of the turn

Table 71: Output attributes for signalized nodes



218 © PTV AG


step 1: Lane volume calculation from the movement volumesThis 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 theinput movement volumes into account. The implemented method is the same as in the All-Waystop method (see "All-Way stop (HCM 2000 Chapter 17)" on page 243). You can overwrite alane's utilization share within its lane group, if applicable (lane attribute ICAUtilShare).Here, HCM 2010 and HCM 2000 differ significantly. According to HCM 2010, the calculation ismuch more complex. In HCM 2010, lane volume calculation is an iterative process taking thesaturation flow rates into account. For a description, please refer to HCM 2010, pages 31-30 to31-37.

step 2: Volume adjustments by means of peak hour factorsThe input lane volumes are adjusted to represent the peak hour volumes through the peakhour factor (phf). The phf is defined as:vi = vg / PHF

where

step 3: Calculation of de facto lane groups left/though/rightDe facto lane groups are shared lanes with 100% of their volume making one movement. Forexample, if a lane group is a shared left and through lane, and 100% of the lane volume ismaking a left movement, then the lane group is converted to a de facto exclusive left lanegroup.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 singleturning direction is used actually.

step 4: Calculation of the types of left turnsThe type of left turn needs to be determined in order to calculate the left turn adjustment factor.The left turn type is set as follows:1. Fully controlled if all turns of an approach are conflict free during their green times.2. Fully secured if the left turns are conflict free during green time.

Turn ICACalculatedFollowUpTime Follow-up time used when calculating

Turn ICA back of queue for defined percentile

Percentile of queue length

Turn ICA average back of queue Average queue length

Turn ICACalculatedCriticalGap Critical gap used when calculating

vi adjusted volume for lane group ivg unadjusted (input) volume for lane group g

PHF peak hour factor (0 to 1.0)

Network object


Table 71: Output attributes for signalized nodes

219 © PTV AG


3. Fully secured + permitted if during green time left turns are first fully secured and thenpermitted.

4. Permitted + fully secured if during green time left turns are first permitted and then fullysecured.

5. Without left turn stage, all other cases.

step 5: Proportions of left turning and right turning vehicles calculation by lane groupThe proportion of right and left turn volume by lane group needs to be calculated.PLT = vLT / vi

PRT = vRT / vi

where

In HCM 2010, the iterative method mentioned in step 1 is used for the calculation of the turningmovement proportions on shared lanes. For the description in detail, please refer to HCM2010, page 31-30 et seqq.

step 6: Saturation flow rate calculation by lane groupThe saturation flow rate is the amount of traffic that can make the movement under theprevailing geometric and signal timing conditions. The saturation flow rate starts with anoptimum capacity, which usually is 1,900 vehicles per hour per lane (vphpl) for HCM 2000 andHCM 2010. For the computation variants ICU1 and ICU2, the ideal saturation flow rate is 1,600 vehiclesper hour per lane instead. For the Circular 212 variant, it is taken from the table below:

This number decreases due to various factors. The SFR is defined as:si = (so)(N) • (fw)(fHV)(fg)(fp)(fa)(fbb)(fLu)(fRT)(fLT)(fLpb)(fRpb)

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

Method 2 stages 3 stages 4+ stages

Planning 1,500 1,425 1,375

Operations 1,800 1,720 1,650

si saturation flow rate of lane group i

so ideal saturation flow rate per lane (usually 1,900 vphpl)

N number of lanes in lane group

fw factor for lane width adjustment

fHV HGV adjustment factor

220 © PTV AG


First the description of the main calculation is described and then the various SFR adjustmentfactors are calculated.If an ICAIdealSatFlowRate is specified for a turn, it will replace the final result of step 5. Alladjustment calculations are then bypassed.The calculations according to HCM 2000 or HCM 2010 are similar. The set of factors takingeffect on the saturation flow rate is the same. Merely the calculations of the factors fw (HCM2010, page 18-36), fLpb and fRpb differ. The latter are calculated by means of the iterativemethod, 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 calculatedby the number of vehicles which can be accommodated there. The number n of vehicles canbe set by lane. Alternatively, it results from the division of the pocket lane length by the spaceneeded per PCU.The alternative calculation method using lane length data is only applied, if the lane groupconsists of one or more straight through lane(s) and exactly one pocket lane. The pocket lanemust be of a straight through lane or a through-left type or a through-right type lane. If theseconditions 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 apocket, where there is space for n vehicles, then is as follows:

Here, so is the ideal saturation flow rate, n is the number of vehicles which can beaccommodated on the pocket, gi is the effective green time and sf is the resulting saturationflow rate of the lane group.For shared lanes, the calculation is more complex. Taking a through lane with only straightturns and a shared left/straight pocket, then the resulting saturation flow rate sf is as follows:

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

sf so min son 3600⋅

gi-------------------,

⎩ ⎭⎨ ⎬⎧ ⎫

+=

sfsST sLT⋅

vLTvLT vST⋅-------------------- sST⋅

vSTvLT vST+---------------------- sLT⋅+

--------------------------------------------------------------------------=

221 © PTV AG


Here, vLT and vST are the volumes of the left and the straight turns, sLT is the ideal saturationflow rate of the left turn - therefore 1,900 vphpl - and sST is the ideal saturation flow rate of thethrough lanes which results from the first equation.

step 7: Calculation of actual green timesThe 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 + liwhere

step 8: Capacity calculation per lane groupRelated to the SFR is the capacity. The saturation flow rate is the capacity if the movement has100 % of the green time (this means, the signal is always green for the movement). Thecapacity, however, accounts for the fact that the movement must share the signal with theother movements at the intersection, and therefore scales the SFR by the percent of greentime in the cycle. The capacity of a lane group is then defined as follows: ci = si • (gi / C)

where

step 9: Calculation of the critical vol/cap ratio for the entire intersectionThe critical v/c ratio of nodes is defined below. The HCM method is concerned with the criticallane group for each signal stage. The critical lane group is the lane group with the largestvolume/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 thedescription 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 willbe determined at all. Per signal group, the loss time results from the amber time and allred timetotal minus loss time adjustment.

where

gi effective green time per lane group

Gi green time per lane group

li loss time adjustment per signal group

ci capacity i

si saturation flow rate i

C cycle time

gi / C green ratio i

Xc critical saturation (v/c ratio) per intersection

(v/s)ci volume/capacity ratios for all critical lane groups

( )LC

C

icisvcX

−= ∑

222 © PTV AG


Below is an example calculation of critical lane group per signal stage with overlap.For computation variant ICU1, Xc is defined as follows:

For computation variant ICU2, Xc is defined as follows:

step 10: Mean total delay per lane groupIn addition to calculating the critical v/c per intersection, the mean delay per vehicle iscalculated by the HCM method. The mean total delay is defined below.di = dUiPF + dIi + dRi

where

In HCM 2010, the equation looks likewise. However, factor PF has been implemented in factordUi. For the description of the calculation procedure, please refer to HCM 2010, page 18-45.

where

step 10a: Calculation of the uniform delay for each lane groupThe uniform delay is the delay expected given a uniform distribution for arrivals and nosaturation. It is calculated as follows:

C cycle time

L loss time total of the signal groups of all critical lane groups

di mean delay per vehicle for lane group

dUi uniform delay

dIi inkremental delay (stochastic)

dRi delay residual demand

PF permanent adjustment factor for coordination quality (see "Signal coordination (Signal offset optimization)" on page 262)

fPA lookup value (HCM attachment 16 – 12) based on arrival type

RP lookup value (HCM attachment 16 – 12) based on arrival type

Xcvs--⎝ ⎠

⎛ ⎞cii∑ L

C----+=

Xcvs--⎝ ⎠

⎛ ⎞cii∑ 1 1

CL----⎝ ⎠

⎛ ⎞ 1–------------------+⋅=

( )( )( )Cig1

PAfCigpR1PF

−

−=

( )( ) ( )[ ]1,iXminCig1

2Cig1C5.0Uid−

−=

223 © PTV AG


where

step 10b: Calculation of the incremental delay for each lane groupThe incremental delay is the random delay that occurs since arrivals are not uniform and somecycles will overflow. It is calculated as follows:

where

step 10c: Delay calculation for the residual demand per lane groupThe residual demand delay is the result of unmet demand at the start of the analysis period. Itis only calculated if an initial unmet demand at the start of the analysis period is input (Q). It isset to 0 in the current implementation. It is calculated as follows:

where

step 11: Delay calculation for the approach The total delay per vehicle for each lane group can be aggregated to the approach and to theentire intersection with the following equations. The approach delay is calculated as theweighted delay for each lane group.

dUi uniform delay for lane group i

gi effective (actual) green time

Xi = v/c volume/capacity ratio

dIi incremental (random) delay for lane group i

ci capacity for lane group i

Xi = v/c volume/capacity ratio

T duration of analysis period (hr) (default 0.25 for 15 min)

ki lookup value (HCM attachment 16 – 13) based on the controller type

Ii upstream filtering / metering adjustment factor (set to 1 for isolated intersection)

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


ui delay parameter for lane group (default 0)

ti duration of unmet demand in T for lane group (default 0)

( ) ( ) ⎥⎦

⎤⎢⎣

⎡+−+−=

TiciXiIik821iX1iXT900Iid

( )Tic

itiu1biQ1800Rid +

=

224 © PTV AG


where

step 12: Delay calculation for the intersection The intersection delay is calculated as the weighted delay for each approach.

where

step 13: Level of Service calculationFor the computation variant HCM 2000, the level of service is defined as a value which isbased on the mean delay of the node.

In HCM 2010, the level of service is automatically classified as F, if v/c (volume/capacity ratio)exceeds the value 1.For the variants ICU 1, ICU2, and Circular 212, the level of service is defined through thesaturation v/s (volume/saturation flow rate) of the node:

dA mean delay per vehicle for approach A

di delay for lane group i

vi volume for lane group i

di mean delay per vehicle for intersection I

dA delay for approach

VA volume for approach

LOS Mean delay/vehicle

A 0 – 10 sec.

B 10 – 20 sec.

C 20 – 35 sec.

D 35 – 55 sec.

E 55 – 80 sec.

F 80 + sec.

LOS volume/saturation flow rate

A 0.000 - 0.600

B 0.601 - 0.700

C 0.701 - 0.800

D 0.801 - 0.900

E 0.901 - 1.000

∑∑=

iViVid

Ad

∑∑=

AVAVAd

Id

225 © PTV AG


step 14: Mean queue length calculation per lane groupQueue 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 + Q1

where

step 14a: Calculation of the number of residual vehicles after cycle 1Q1 represents the number of vehicles that arrive during the red stages and during the greenstages until the queue has dissipated.

where

where

F >1.000

Q mean queue length – maximum distance measured in vehicles the queue extends on average signal cycle

Q1 mean queue length for uniform arrival with progression adjustment

Q2 incremental term associated with random arrival and overflow to next cycle

PF2 progression factor 2

vi volume of lane group i per lane

C cycle time

gi effective green time of lane group i

Xi volume/capacity ratio of lane group i

PF2 progression factor 2

vi volume per lane of lane group i

C cycle time

gi effective green time lane group i

LOS volume/saturation flow rate

( ) ⎥⎦

⎤⎢⎣

⎡−

⎟⎠

⎞⎜⎝

⎛ −=

Cig

iX,1min1

Cig1

3600Civ

2PF1Q

⎥⎥⎦

⎤

⎢⎢⎣

⎡⎟⎟⎠

⎞⎜⎜⎝

⎛−⎟

⎠⎞

⎜⎝⎛ −

⎟⎟⎠

⎞⎜⎜⎝

⎛−⎟

⎠

⎞⎜⎝

⎛ −

=

isiv

pR1Cig1

isiv1

Cig

pR1

2PF

226 © PTV AG


step 14b: Calculate second-term of queued vehicles, estimate for mean overflow queue

where

k = 0.12 I • (sigi / 3600)0.7 for fixed time signal

k = 0.10 I • (sigi / 3600)0.6 for demand-actuated signal

step 15: Calcualtion of the queue length percentileAfter calculating the mean back of queue, the percentile of the back of queue is calculated asfollows:

where

si saturation flow rate for lane group i

RP platoon ratio – based on lookup table for arrival type

T analysis period (usually 0.25 for 15 minutes)

k adjustment factor for early arrival

Qb initial queue at start of period (default 0)

ci capacity for lane group i

i upstream filtering factor (set to 1 for isolated intersection)

Q average queue length

percentile pre-timed signal actuated signal

70% P1 P2 P3 P1 P2 P3

85% 1.2 0.1 5 1.1 0.1 40

90% 1.4 0.3 5 1.3 0.3 30

95% 1.5 0.5 5 1.4 0.4 20

98% 1.6 1.0 5 1.5 0.6 18

1.7 1.5 5 1.7 1.0 13

( ) ( )( ) ( ) ( )( )( ) ⎥

⎥

⎦

⎤

⎢⎢

⎣

⎡+++−++−= 2Tic

bkQ16Tic

ikX82TicbQ1iXTicbQ1iXTic25.02Q

⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜

⎝

⎛ −

+= 3PQ

e2P1PQ%Q

227 © PTV AG


Saturation flow rate adjustment factorsWe now return to the calculation of the saturation flow rate (see "Saturation flow ratecalculation by lane group" on page 220) which involves several adjustment factors.

Step 6 a: Calculate lane width adjustment factor

where

This method differs in HCM 2010. For a description, please refer to HCM 2010, page 18-36.

Step 6b: Calculate heavy goods vehicle factor

where

Step 6c: Calculate approach grade adjustment factor

where

Step 6d: Calculate parking adjustment factorfP is calculated as follows:

where

fw lane width adjustment factor

H mean lane width (≥ 8) (ft)

fHV adjustment factor for heavy goods vehicles

%HV percentage of HGV per lane group

EP passenger car equivalent factor (2.0 / HV)

fg adjustment factor for approach grade

%G approach grade as percentage (-6 % bis +10 %)

fp parking adjustment factor (1.0 if no parking, else ≥ 0.050)


Nm number of parking maneuvers per hour (only for right turn lane groups) (0 to 180)

( )30

12W1wf−

+=

( )1TEHV%100100

HVf−+

=

200G%1gf −=

N3600

mN181.0Nf

−−=

228 © PTV AG


In VISUM, enter fP which is calculated by the formula, as attribute ICA parking directly at thenode 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

Step 6f: Calculate bus stop blocking factor

where

In VISUM, enter fbb which is calculated by the formula, as attribute ICA bus blockage directlyat the node leg.

Step 6g: Calculate lane utilization adjustment factor

where

For this adjustment factor, an HCM lookup-table is regarded (HCM 2000: table 10-23 on page10-26; HCM 2010: table 18-30 on page 18-77). Alternatively, lane attribute values can be used(ICA user-defined utilization share and ICA use user-defined utilization share).

Step 6h: Calculate right turn adjustment factor

where

fa adjustment factor for position

CBD indicates a central business district

fbb bus stop blocking adjustment factor (≥ 0.05)


NB number of bus stop events per hour (does not apply to left turn lane groups) (0 to 250)

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)

N3600

BN4.14Nbbf

−=

( )N1gvgvLuf =

fRT

1.0 - (0.35)PRT for single lane approach

OR0.85 for exclusive right turn laneOR1.0 - (0.15)PRT for shared right turn lane⎩

⎪⎪⎪⎨⎪⎪⎪⎧

=

229 © PTV AG


The calculation according to HCM 2010 differs. For shared lanes, the adjustment factor is nolonger explicitly calulated. For more details, please refer to HCM 2010, page 18-38.

Step 6i: Calculate left turn adjustment factorThe left turn adjustment factor is the most complex of the factors. Here, HCM 2000 and HCM2010 differ significantly. For the description, please refer to HCM 2010, page 18-38 and pages31-30 to 31-37.The calculation is simple for protected left turns. However, if there is permitted phasing, thenthe equation is quite complex. It is as follows:

where

For permitted staging, there are five cases. When there is protected-plus-permitted staging orpermitted-plus-protected staging, the analysis is split into the protected portion and thepermitted portion. The two are analyzed separately and then combined. Essentially this meanstreating them like separate lane groups. Refer to the HCM for how to split the effective greentimes 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 below4. Shared lane with protected-plus-permitted phasing – use the equation above for protected

phasing portion and the general equation below for the permitted portion 5. Single lane approach with permitted left turns – use the general equation below The general equation for calculating fLT for permitted left turns is below. Note that this is notthe exact HCM 2000 equation since there are a few different versions depending on thesituation – shared/exclusive lane, multilane/single lane approach, etc. But the equation issimilar regardless of the situation. This general equation is the equation for an exclusive leftturn 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 anadjustment factor. The adjustment factor is based on the portion of lefts in the lane group andan equivalent factor for gap acceptance time that is based on the opposing volume. Thecalculation of the percentage of the time when lefts can make the turn is a function of theopposing volume and their green time. The equation is as follows:

fRT right turn adjustment factor (≥ 0.05)

PRT proportion of right turn volume for lane group

fLT adjustment factor for left turns

PLT proportion of left turn volume for lane group

fLT

0.95 for exclusive left turn lane (protected phasing)1

1.0 0.05 PLT+----------------------------------- for shared left turn lane (protected phasing)

see equations below for permissive phasing⎩⎪⎪⎨⎪⎪⎧

=

230 © PTV AG


fLTmin = 2 • (1 + PL) / g

gu = g - gq (if gq ≥ 0, else gu = g)

where

Note that opposing volume is calculated from the signal groups that occur during the samegreen time as the subject lane group. To calculate the opposing volume for a subject lanegroup, 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 onlyone opposing approach is allowed. If more than one opposing approach is coded, an error iswritten to the log file.

Step 6j: Calculate pedestrian adjustment factors for left and right turnsThe computation of the factors for left-turning and right-turning pedestrians and bicyclists is aconsiderably complex operation. It is performed in four steps. For the computation, the bicyclevolumes of the legs are regarded and the pedestrian volumes of the crosswalks. A traffic flowhas potential conflicts with two crosswalks on the outbound leg. These two crosswalks head forthe opposite directions.

fLT general left turn adjustment factor for permitted phasing

fLTmin minimum value for adjustment factor

g effective permitted green time for left turn lane group

gu effective permitted green time when lefts filter through opposing traffic

PL proportion of left turning vehicles in the lane

EL1 through car equivalent for permitted left turns (veh/hr/lane) (lookup table based on opposing volume)

gq effective permitted green time when lefts are blocked and opposing queue clears

go effective permitted green time for opposing traffic


volcadjusted opposing volume per lane per cycle =

No number of lanes in opposing lane group

vo adjusted opposing volume

fLUo opposing lane utilization factor (see above)

qro opposing queue ratio = max[1 - Rpo • (go / C), 0] (Rpo = lookup based on arrival type

tl loss time for left-turn lane group

fLTgug-----⎝ ⎠

⎛ ⎞ 11 PL EL1 1–( )⋅+-------------------------------------------⎝ ⎠

⎛ ⎞ fLTmin fLT 1≤ ≤( )⋅=

PL 1 N 1–( ) g⋅gu EL1 4.24+( )⁄----------------------------------------+=

gqvolc qro⋅

0.5 volc 1 qro–( ) go⁄⋅[ ]–--------------------------------------------------------------- tl–=

vo C⋅3600 No fLUo

⋅ ⋅-------------------------------------

231 © PTV AG


Step 1: Determination of the pedestrian occupancy rate OCCpedg.

The pedestrian occupancy rate OCCpedg is derived from the volume. The following applies.

Here, vpedg is the pedestrian flow rate, v1pedg and v2

pedg are the pedestrian volumes of the

crosswalks, C is the cycle time of the signal control and g1p and g2

p indicate the duration ofthe green for the pedestrians.

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 roadsIn this case, the following applies:OCCr = OCCpedg

Decisive for left turns from one-way roads is, that there is no opposite vehicle flow.• Case 2: Right turn movements with bicycle conflictsHere, straight turns of bicyclists are assumed.

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 signalcontrol, g is the effective green time of the lane group, and OCCbicg is the conflict area'soccupancy rate caused by bicyclists.• Case 3: Other left turn movementsThese are left turn movements which do not originate from a one-way road. Here, adistinction of cases is made for the values gq and gp. gq is the clearing time of the vehicle

Note: At a leg which is a channelized turn no conflicts occur between right turn movementsand pedestrians.

Note: In the HCM2000 it is implicitly assumed, that the green for the left turn movementsand 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 pedestriangreen time overlaps (or touches) the green or amber stage for vehicles, an existing conflictis assumed. In this case, the duration of the green of the pedestrian signal group is fullycharged. Otherwise it is assumed, that there is no conflict. In this case, gp = 0 is assumed.

vpedg min 5000 vped1 C

gp1

-----⋅ vped2 C

gp2

-----⋅+,⎝ ⎠⎜ ⎟⎛ ⎞

=

OCCpedgvpedg 2000⁄ falls v pedg 1000≤,

0 4, vpedg 10000⁄+ else,⎩⎨⎧

=

vbicg min 1900 vbicCg----⋅,( )=

232 © PTV AG


flow on the opposite leg, and gp is the green time for the conflicting pedestrians. Thefollowing applies

gp = max(g1p, g2

p)

• 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 waituntil the vehicle flow on the opposite leg is cleared.• Case 3b: gq < gp

The following applies

Here, OCCpedu is the occupancy rate of pedestrians after the clearance of the vehicle flowon the opposite leg, and OCCpedg is the pedestrians occupancy rate.

Step 3: Determination of the adjustment factors for pedestrians and bicyclists on permittedturns ApbT

Here, two cases are distinguished with regard to the values Nturn – which is the number oflanes 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 followingappliesApbT = 1 - 0.6 • OCCr

Step 4: Determination of the adjustment factors for the saturation flow rates for pedestriansand 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 lanegroup, 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).

OCCpedu OCCpedg 1 0 5,gqgp-----⋅⎝ ⎠

⎛ ⎞–⋅=

OCCr OCCpedu e5 3600⁄( )– v0[ ]⋅=

233 © PTV AG


5.5.3.3 Two-Way Stops (HCM 2000 Chapter 17)

The two-way stop analysis method is based on the gap acceptance theory. The basic idea isto calculate potential capacities for all movements, and then subtract capacity from thesemovements based on movement rank (priority). The calculation flow chart looks like displayedin illustration 60.

Illustration 60: Method of calculation at two-way stops

If you use the HCM 2000 operations model for two-way stop nodes, the VISUM attributes inTable 72 will have an effect. Make sure that they are set to realistic values prior to running theanalysis.

Notes: For the description of this signalization type, please refer to HCM 2010 chapter 19. Inmost instances, the calculation complies with HCM 2000. Especially the explicit U-turnhandling has been added.In VISUM, two-way nodes are modelled by the control types two-way stop and two-wayyield. In the HCM, the description refers to two-way stop nodes. Basically, the computationis the same. The only difference is the determination of wait times in step 8.

Network objects Attribute Description / Effect

Link ShareHGV HGV share is used in the steps 3 + 4. A value which applies to all turns originating from this link.

Link Slope Used in step 3

Table 72: Input attributes for the calculation of two-way stops

InputsGeometryVolumes

%HGV, Ped Vol

VolumePHF

Identify Conflicts

Gap & Follow-Up TimesBasics

Adjustment Factors

Potential MovementCapacity

Capacity AnalysisDelay, LOS, Queues

234 © PTV AG


Output is available through the same attributes as for signalized nodes (Table 71).The method works with movements (Left, Through and Right) at each approach. Eachmovement is ranked according to Table 73.

step 1: Flow rate (volumes) calculation for each movementThe 15 min peak flow rates (as calculated from the PHF adjustment) are used as the adjustedmovement volumes.

step 2: Conflicting flows for each movementIn addition to calculating the volumes for each movement, the conflicting volumes for eachmovement for each approach must be calculated.

Node ICAPHFVolAdj Initial volume adjustment to peak period volume; volumes are multiplied with both node and turn adjustment factors


Turn ICAPHFVolAdj Initial volume adjustment to peak period; volumes are multiplied with both node and turn adjustment factors

Turn Preset critical gap Optionally, you can overwrite the critical gap, used in step 3

Turn Preset follow-upp time Optionally, you can overwrite the follow-up time, used in step 4

Rank

1 Major ThroughMajor RightMinor Ped Crossing

2 Major LeftMinor RightMajor Ped CrossingMajor Left – priority to gaps in the opposing flowMinor Right – priority to gaps in the flow of the right-most lane of the major flowPedestrians – Priority to any other flow

3 Minor Through

4 Minor Left

Table 73: Ranking of movements

Note: HCM 2010 also regards U-turns on major flows. They are given rank 2. If the calculationis based on HCM 2010, the U-turn related setting in the procedure parameters will not affectthese U-turns.


Table 72: Input attributes for the calculation of two-way stops

235 © PTV AG


For right-hand traffic, the following example models the conflict flow of a left turn on a majorflow:• 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 andneed to attend a yield sign or a stop sign) + pedestrian volumes minor flow crossing

The Table 74 shows the equations for conflicting volumes.

where

There is a number of cases where the conflicting volume is adjusted:• If the major flow (right) is separated by a channelized turn and needs to attend a yield sign

or a stop sign then this flow will not be considered in the conflicting volume calculation forother 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 forthe conflicting volume.

Notes: Rank 1 movements do not have conflicting flows since they have the highest priority.Mainly, rank 1 movements are excluded from the analysis, with the exception of oneadditional evaluation (see "Calculation of the critical vol/cap ratio for the entire intersection"on page 222).According to HCM 2010, pocket lanes for left turns (rights for left-hand traffic accordingly) inthe major flow are dealt with separately.Only nodes with three or four legs are described in the HCM. In VISUM, also multi-leg nodescan be calculated. The 'Uncontrolled' rule is applied to conflicting flows between minor legswhich are not separated by a major leg.For left-hand traffic, the right-hand calculation is performed symmetrically.

Movement Conflicting flows

Major Left OT + OR* + ToP

Minor Right JT/N + 0.5JR* + FrP + ToP

Minor Through 2JL + JT + 0.5JR* + FrP + ToP + 2JLF + JTF + JRF*

Table 74: Calculation of the conflicting volumes

O Opposite directionT ThroughR RightL LeftN Number of through lanesJ Major…i Minor…F far… (for minor through/left turns the second major flow encountered )ToP Approach (to) with pedestrian crosswalkFrP Exit (from) with pedestrian crosswalk

236 © PTV AG


• For left turns from the minor flow, the right turn volume of the opposing direction does notcount for the conflicting flow, if the destination link of the two turns has more than one lane.

step 3: Critical gap calculation for each movementThe critical gap is the time an average driver would accept in order to merge with traffic.

ExampleSarah needs 4 seconds of space between vehicles to make her left turn and merge with othertraffic safely.The critical gap equation is:tcx = tcb + (tcHVPHV) + (tcGG) - tcT - t3LT

where

The other adjustment factors are:

The base values for the critical gap are calculated as shown in Table 75.

Notes: Apart from the U-turns, the HCM 2010 differs from HCM 2000 in subtle differences.For the determination of conflicting flows, please refer to HCM 2010, pages 19-9 to 19-14.The HCM does not regard bending two-way stop/yield cases. In this case, conflicting flowsare determined according to Brilon and Weinert, 2002.

tcx critical gap for movement x

tcb base critical gap (see Table 75)

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

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 75: Base values for the critical gap

⎥⎦⎤

⎢⎣⎡=

⎥⎥⎦

⎤

⎢⎢⎣

⎡=

⎥⎦⎤

⎢⎣⎡=

otherwise 0,onintersecti-T at left minor for ,7.0

LT3t

otherwise 1,through and left minor for 0.2,

right minor for,1.0cGt

streetmajor lane-four for 2, streetmajor lane-two for 1, cHVt

237 © PTV AG


step 4: Follow-up time calculation for each movement The follow-up time is the extra time needed for a second car to also take the gap.

ExampleSuppose Frank was waiting behind Sarah in the intersection. If he turns just after Sarah, hewould need a follow-up time of 2 seconds, rather than another 4 seconds to be able to mergesafely with other traffic. So, if the gap between vehicles was at least 6 seconds, both Sarah andFrank could safely make their turns.The follow-up time equation is: tfx = tfb + tfHVPHV

where

The other adjustment factors are:

Follow-up times are calculated according to Table 76.

step 5: Calculate the potential (or ideal) capacity for each movement The potential capacity is the capacity which is achieved if this movement uses all potentialgaps (i.e. no higher ranking movements take up the gaps). Furthermore, it is assumed thateach movement is made from an exclusive lane. The potential capacity is defined as follows:

with

tfx follow-up time for movement x

tfb base follow-up time (Table 76)

tfHVPHV follow-up time adjustment factor for heavy vehicles • percent heavy vehicles

Movement Base follow-up time value tfb

Major Left 2.2

Minor Right 3.3

Minor Through 4.0

Minor Left 3.5

Table 76: Follow-up times

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

⎥⎦⎤

⎢⎣⎡= streetmjaor lane-four for 1.0,

streetmajor lane-two for,9.0fHVt

( )( )⎥

⎥

⎦

⎤

⎢⎢

⎣

⎡

−−

−= 3600tv

e1

3600tvecxvpxc

fxcx

cxcx

238 © PTV AG


step 6: Calculate movement capacity taking into account impedance effects Higher ranking movements impede lower ranking movements’ capacities since vehiclesmaking higher ranked turns can use the available gap space before the lower rankedmovements. Therefore, we adjust the potential capacity by an adjustment factor to yield themovement capacity. The movement capacity equation is as follows:

where

= probability impeding vehicle movement i is not blocking subject movement

= probability impeding ped movement j is not blocking subject movement

Since the calculation depends on higher rank movement capacities the calculation proceedsfrom the top down (from rank 1 to rank 4 movements). Impeding vehicle and pedestrianmovements for each subject movement are listed in Table 77:

where

cmx movement capacity for movement x (veh/hr)

cpx potential capacity for movement x (veh/hr)

vi volume movement i

vj volume pedestrian flow j (peds/hr)

w lane width (ft), standard value 12 ft.

SP pedestrian walking speed (ft/s), standard value is 4 ft/s

Movement Rank Impeding movements

Major Through 1 None

Major Right 1 None

Major Left 2 ToP

Minor Right 2 FrP, ToP

Minor Through 3 JL, JLF, FrP, ToP

Minor Left 4 JL, JLF, OT, OR, FrP, ToP

Table 77: Impeding movements

⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜

⎝

⎛

∈

⎟⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜⎜

⎝

⎛

∈= ∏∏

movements pedestrian Impeding j

pjp

x nt Movemethan rank greater

withMovementsivippxcmxc

miciv1vip −=

Ppj 1vj

wSp-----⎝ ⎠

⎛ ⎞⋅

3600-------------------–=

239 © PTV AG


step 6a: Calculate adjustment for impeding major left turnsThere is also an adjustment factor for major left if it does not operate from an exclusive lane.The equation uses a default saturation flow rate. It is as follows:

where

step 6b: Calculate adjustment for minor left turnsIn 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. Theadjusted value is then used in conjunction with the remaining minor right and pedestrianprobabilities.

J Major…i Minor…O Opposite directionT ThroughR RightL LeftF far (for minor through/left turns the second major flow encountered )ToP Approach (to) with pedestrian crosswalkFrP Exit (from) with pedestrian crosswalk

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 themajor flow scenario.

⎥⎥⎥⎥⎥

⎦

⎤

⎢⎢⎢⎢⎢

⎣

⎡

⎟⎟⎠

⎞⎜⎜⎝

⎛+−

−−=

JR

JR

JT

JT

vJLvJL

sv

sv

pp

1

11'

pJPppIPpvIRpip4vRp

iip6.0)3iip

iip(iip65.0ip

vITpvJLFpvJLpiip

=

++

−=

=

240 © PTV AG


where

step 7: Capacities for movements that share lanes The calculations so far assume that each minor movement operates out of an exclusive lane.When there is a shared lane, a combined capacity is calculated for those movements whichshare a lane.

where

step 8: Calculate delayThe calculation of control delay is defined as follows:

where

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

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 fromthe calculation. The same applies for the two-stage gap acceptable adjustment, as well as forthe flared approach adjustment.

dx mean delay per vehicle for movement x

cmx capacity for movement (shared lane x, CSH)


vx capacity for movement (shared lane x, VSH)

∑

∑

⎟⎟⎠

⎞⎜⎜⎝

⎛=

mciviv

SHC

5T450

mxcxv

mxc3600

1mxcxv1

mxcxvT900

mxc3600

xd +

⎥⎥⎥⎥⎥⎥

⎦

⎤

⎢⎢⎢⎢⎢⎢

⎣

⎡

⎟⎟⎠

⎞⎜⎜⎝

⎛⎟⎟⎠

⎞⎜⎜⎝

⎛

+⎟⎟⎠

⎞⎜⎜⎝

⎛−+⎟⎟

⎠

⎞⎜⎜⎝

⎛−+=

241 © PTV AG


A similar formula is used for the calculation of either two-way control type (yield or stop):

Control delay per movement is aggregated to approach with a weighted (by volume) mean ofall approach movements/shared lanes. Mean approach delay is then aggregated to the entireintersection with a weighted mean as well. The equations are the same as the ones forsignalized 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 equationfor rank 1 movements when there are no left turns pockets on the major approaches. Theequation is as follows:

(5)where

This delay is then substituted by the zero delay of rank 1 movements when calculatingapproach and/or intersection delay.

step 9: Level of ServiceLevel of Service is then simply defined as displayed in Table 78 based on intersection delay.

dR1 delay rank 1 vehicles (s/veh)

N number of through lanes per direction of the major flow

pvJL probability for an adjustment factor impeding major left (5)

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)


A 0 – 10 sec.

B 10 – 15 sec.

C 15 – 25 sec.

Table 78: Allocation of a LOS to the mean delay per vehicle

d 3600cmx

------------ 900Tvx

cmx-------- 1

vxcmx-------- 1–⎝ ⎠

⎛ ⎞ 23600cmx

------------⎝ ⎠⎛ ⎞ vx

cmx--------

450T--------------------------++– 5 min

vxcmx-------- 1,×+ +=

⎪⎪⎪⎪

⎭

⎪⎪⎪⎪

⎬

⎫

⎪⎪⎪⎪

⎩

⎪⎪⎪⎪

⎨

⎧

=

>+

−

=1 N whenJLd)vJLp-(1

1 N whenRvTv

)NTv(JLd)vJLp1(

1Rd

242 © PTV AG


The intersection queue length calculation is:

where

5.5.3.4 All-Way stop (HCM 2000 Chapter 17)

The HCM 2000 All-Way stop controlled (AWSC) capacity analysis method is an iterativemethod. The model looks at all possible scenarios of a vehicle either being at an approach ornot being at an approach. Based on the input volumes the probability of each scenariooccurring is calculated as well as the mean delay. The v/c ratio is calculated for each scenariowhich in turn impacts the others. Therefore, an iterative solution is needed to find the capacityof each approach. Unlike the signalized method, which works with signal groups, or the TWSC method, whichworks with movements, the AWSC model works with lanes by approach. The basic calculation is described in the flow chart in illustration 61. The user inputsintersection geometry and volumes, along with a couple of additional attributes such as PHFand %HGV. The volumes are adjusted and allocated to the lanes. The next step is to calculatethe saturation (capacity) follow-up time adjustment factors. Then the departure follow-up times

D 25 – 35 sec.

E 35 – 50 sec.

F 50 + sec.

Note: For LOS analyses, HCM 2010 additionally takes into consideration whether thecapacity was exceeded. If this is the case, always level F of service will be allocated (HCM2010, page 19-2).

Q95x queue length 95th percentile for movement x (veh)

cmx capacity for movement (shared lane x, CSH)


vx movement volume (shared lane x, VSH)

Note: The calculations described in HCM 2010 and HCM 2000 are identical.. In HCM 2010,please refer to chapter 20. HCM 2010 additionally includes the guidelines for queue lengthcalculations (HCM 2010, page 20-17), which is missing in HCM 2000. Furthermore, thevolume/capacity ratio is regarded for the LOS calculation. In case of overload, automaticallylevel F is assigned.


Table 78: Allocation of a LOS to the mean delay per vehicle

⎟⎠⎞

⎜⎝⎛

⎥⎥⎥⎥⎥⎥

⎦

⎤

⎢⎢⎢⎢⎢⎢

⎣

⎡

⎟⎟⎠

⎞⎜⎜⎝

⎛⎟⎟⎠

⎞⎜⎜⎝

⎛

+⎟⎟⎠

⎞⎜⎜⎝

⎛−+⎟⎟

⎠

⎞⎜⎜⎝

⎛−=

3600mxc

T150mxcxv

mxc3600

21

mxcxv1

mxcxvT900x95Q

243 © PTV AG


(i.e. the mean time between departures for a lane at an approach) are calculated based on allthe combinations of the probability states. This departure follow-up time for each lane for eachapproach 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 becalculated.

Illustration 61: Calculation process for an All-Way stop node

If you use the HCM operations model for All-Way stop nodes, the following VISUM attributesin Table 79 will have an effect. Make sure that they are set to realistic values prior to runningthe analysis.

Network object


Link ShareHGV Proportion of heavy goods vehicles, used in follow-up times adjustment. A value which applies to all turns originating from this link.

Node ICAPHFVolAdj

Initial volume adjustment to peak period. Volumes are multiplied with both node and turn adjustment factors.

Geometry All Geometry information on lanes, lane turns and crosswalks

Turn ICAPHFVolAdj

Initial volume adjustment to peak period. Volumes are multiplied with both node and turn adjustment factors.

Table 79: Input attributes for an All-Way stop node


VolumePHF

Lane volumes

Base HeadwayAdjustments

Final Degree of Utilization

Service Time and Capacity

Delay and LOS

Probability States

Departure Headway

244 © PTV AG


Output is available through the same attributes as for signalized nodes (Table 70).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 inVISUM volumes are specified by movement and not by lane by movement, they are firstdisaggregated per lane according to a standard method.The next step is to calculate the follow-up time adjustment factors for each lane. Thecalculation applies as follows:hadj = hLTadj • pLT + hRTadj • pRT + hHVadj • pHV

where

The adjustment factors are listed in Table 80.

After calculating the follow-up time adjustment factor the departure follow-up time is calculatedin an iterative manner. It involves five steps.

step 1: Calculate combined probability states probability

where

This probability states calculation has a few parts. For each lane type j the P(aj) is calculated.P(aj) is calculated based on a lookup table (Table 81).

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

Number of lanes of the subject approach Adjustment factor Saturation Mean follow-up time

LT RT HV

1 0.2 0.6 1.7

2+ 0.5 -0.7 1.7

Table 80: Adjustment factors

P(i) probability for combination i

P(aj) probability of degree-of-conflict (DOC) for combination i lane type j

aj 1 or 0 depending on lane type j (see Table 81)

( ) ( )∏=j

jaPiP

245 © PTV AG


Value aj is taken from the DOC table (Table 82). This table contains all the combinations of 0and 1 per lane for each approach. For two lanes per approach it looks like displayed inTable 82 (see exhibit 17-30 in the HCM 2000 for the full table).

The combined probability states probability P(i) is then calculated for each row (i) for eachcolumn (lane type) (j). To calculate P(i) we take the product of all probabilities of each opposinglane 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 factorsAfter calculating P(i) for each case (i), an adjustment for each DOC case needs to becalculated. The adjustment accounts for serial correlation in the previous calculation due torelated conflict cases. For DOC case (Ck), the adjustment equations are:

aj Vj (volume conflicting approach) P(aj)

1 0 0

0 0 1

1 >0 Xj

0 >0 1 - Xj

Table 81: Probability states calculation of degree-of-conflicts

Notes: • If iteration 1, then Xj = (Vjhd) / 3600• If iteration > 1, then Xj = (Vjhd) / 3600• Initial value hd = 3.2 s

i DOC case (Ck) Number vehicles

Approach opposite direction

Left (subject approach)

Right (subject approach)

L1 L2 L1 L2 L1 L2

1 1 0 0 0 0 0 0 0

2 2 1 1 0 0 0 0 0

3 2 1 0 1 0 0 0 0

4 2 2 1 1 0 0 0 0

…

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

Table 82: Excerpt from the DOC table for two lanes per approach

246 © PTV AG


where

step 3: Calculate adjusted probabilityP‘(i) = P(i) + adjP(i)where

step 4: Calculate saturation follow-up timehsi = hadj + hbase

where

For each DOC case i, the base follow-up time hbase is taken from a lookup table which is basedon the particular DOC case (1 – 5) and geometry group (Table 83).

a 0.01 (or 0.00 if no serial correlation)

n number of non-zero cases (i) for each DOC case (at most n = 1 for C1, 3 for C2, 6 for C3, 27 for C4 and C5)

P‘(i) adjusted probability for case i

P(i) probability of degree-of-conflicts for case i

adjP(i) probability adjustment factor case i

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

n/)]5C(P10[a)5C(adjP

n/)]4C(P6)5C(P[a)4C(adjP

n/)]3C(P3)5C(P2)4C(P[a)3C(adjP

n/)]2C(P)5C(P3)4C(P2)3C(P[a)2C(adjP

n/)]5C(P4)4C(P3)3C(P2)2C(P[a)1C(adjP

64

38)i(P)5C(P

37

11)i(P)4C(P

10

5)i(P)3C(P

4

2)i(P)2C(P

)1(P)1C(P

−=

−=

−+=

−++=

+++=

=

=

=

=

=

∑

∑

∑

∑

247 © PTV AG


The model is generalized for 3+ lanes in order to apply it to 4+ leg intersections. The extensionis that these 4+ leg cases are geometry group 6.Table 84 shows the saturation follow-up time base values.

The DOC case is dependent on the 64 types of a 4 leg intersection. Nodes with more than 4legs are first collapsed to four legs.

Number of lanes

Subject approach

Opposing approach

Conflicting approach

Intersection type Geometry group

1 1 1 4 leg or T 1

1 1 2 4 leg or T 2

1 2 1 4 leg or T 3a / 4a

1 2 2 T 3b

1 2 2 4 leg 4b

2 1 - 2 1 - 2 4 leg or T 5

3 1* 1* 4 leg or T 5

3 3 3 4 leg or T 6

Table 83: Lookup table base follow-up time

Note: * If subject is 3 lanes and either opposing or conflicting approach is 1 lane thengeometry group 5, else geometry group 6.

DOC case 1 2 3 4 5

Number of vehicles (Sum of the [0,1] for the case)

0 12>=3

12>=3

234>=5

345>=6

Geo

met

ry g

roup

1 3.9 4.7 5.8 7.0 9.6

2 3.9 4.7 5.8 7.0 9.6

3a 4.0 4.8 5.9 7.1 9.7

3b 4.3 5.1 6.2 7.4 10.0

4a 4.0 4.8 5.9 7.1 9.7

4b 4.5 5.3 6.4 7.6 10.2

5 4.5 5.06.2

6.47.2

7.67.89.0

9.79.710.011.5

6 4.5 6.06.87.4

6.67.37.8

8.18.79.612.3

10.011.111.413.3

Table 84: Base values for the saturation follow-up time

248 © PTV AG


step 5: Calculate departure follow-up time

where

These five steps are repeated until the departure follow-up time values converge (change is <0.1). Now, the calculated departure follow-up time hd differs from the original value. Thus, thenext iteration will return a different result.Now that the departure follow-up time for each lane is calculated, service time and capacity canbe calculated. The service time is calculated as follows:t = hd - m

where

Capacity is calculated as follows: the volume of the subject lane is incremented until the degreeof utilization (vjhd)/3,600 on the subject lane ≥ 1.0. The volume of the other approaches is heldconstant. At this point, the subject lane’s volume value is taken to be the subject lane’scapacity. 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 anapproach is calculated based on lane volume weights. Intersection average delay is calculatedbased on the weighted mean by approach volumes. The equations are the same as the onesfor signalized intersections.

where

hd departure follow-up time for lane

hsi saturation follow-up time for each i in I

P‘(i) adjusted probability for each i in I

i Row of table 1

t service time

hd Departure follow-up time

m move up time (2.0 s for geometry groups 1-4 and 2.3 s for groups 5-6)

dx mean delay per vehicle for lane x

t ServiceTime


x degree of utilization Vhd / 3,600

hd Departure follow-up time

∑∈

=Ii

sih)i('Pdh

( ) ( ) 5T450xdh21x1xT900txd +⎥

⎦

⎤⎢⎣

⎡+−+−+=

249 © PTV AG


Level of Service is defined as a lookup based on intersection delay (Table 85).

The proposed extension for 4+ legs is to combine multiple lefts or rights into one left or right byadding the number of lanes together when calculating conflicting flows. For example, whenthere 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 tobe used. It probably slightly understates the delay, but it will work within the existing frameworkand will result in additional delay for additional legs.

5.5.3.5 Roundabouts according to the HCM 2010 methodFor this analysis method, please refer to HCM 2010, chapters 21 and 33. It is similar to the onefor two-way stop nodes and mainly differs from it in the following points:• Determining the conflict flows follows the geometry of the roundabout.• The standard values for gaps differ due to changed visibility conditions. Also this calculation

is performed on the basis of lanes, not on the basis of turns.• With this method it is assumed, that only one-leg and two-leg approaches exist.

Furthermore it is assumed, that also the intersection itself does not have more than twolanes.

The calculation process is illustrated by illustration 62.


A 0 – 10 s

B 10 – 15 s

C 15 – 25 s

D 25 – 35 s

E 35 – 50 s

F 50 + s

Table 85: Determining the LOS based on the mean delay per vehicle

250 © PTV AG


Illustration 62: Calculation process for roundabouts according to HCM 2010

If you use the HCM 2010 operations model for roundabout nodes, the VISUM attributes inTable 86 will have an effect. Make sure that they are set to realistic values prior to running theanalysis.

Output is available through the same attributes as for signalized nodes (Table 71).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 turnThe turn volumes are converted by multiplying them with the peak hour factors of the turns andthe node in values for the 15 minute peak.



Node ICAPHFVolAdj Factor for adjustment of initial volumes to peak volumes. Volumes are multiplied with both node and turn adjustment factors.

Turn ICAPHFVolAdj

Link Proportion bypass volume

Proportion of right turns (left-hand traffic: left turns), which use a bypass lane for the turn movement.

Lane ICACriticalGap Optionally, you can overwrite the critical gap, used in step 4 The analoguous value of the turn is not used.

Lane ICAFollowUpTime Optionally, you can overwrite the follow-up time, used in step 5 The analoguous value of the turn is not used.

Table 86: Input attributes for roundabout nodes according to HCM 2010

In p u tsV olum es

Vo lu m eIn co m ing leg s

C on fl ic ting v olume s

T im e g a p sC ri tic al g aps

F ol low -up t im es

C ap a city

Wa itin g tim eQ u eu e l en g th

251 © PTV AG


step 2: Calculating traffic flows for each lane and conflicting volumes for each approachAll calculations are based on the traffic flows and conflicting volumes at each approach. Theseflows are derived from the turn volumes (in illustration 63 for a roundabout with fourapproaches designated with v1 to v12).

Illustration 63: Approaching flows at a four-leg roundabout

For the distribution of the volumes to the lanes please refer to HCM 2010, pages 21-14 and 21-15.

ExampleThe flow from the south is the sum of turn volumes v7 + v8 + v9. The conflicting flow whichapplies to this flow is however the sum v1 + v2 + v10. This approach can be applied toroundabouts with a countless number of approaches. U-turns can also be considered in thesame 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: CapacityThe capacity of an approach depends on various factors: the number of lanes per approachand the number of lanes in the roundabout and whether a lane is a bypass lane. For each ofthe cases, predefined formulas can be used (HCM 2010, equations 21-1 to 21-7). This is thebasic formula:

c 1130e Bv–=

252 © PTV AG


Here, B equals 0.001 for one-lane and two-lane entry roads to single-lane roundabouts, and forsingle-lane approaches to two-lane roundabouts the value is 0.0007. Two-lane approaches totwo-lane roundabouts use the following values for B: 0.00075 for the inner-most (let) lane, and0.0007 for the right lane. For bypass lanes with only one conflicting exit lane the value 0.001 isused, whereas 0.0007 is used if there are two conflicting exit lanes.Users with detailed knowledge of critical gaps and follow-up times can replace these formulas.For the control type 'roundabout', critical gap and follow-up time are set by lane. Turn-relatedvalues of this attribute are not regarded. For the extended computation, the capacity is derivedfrom the following data (HCM 2010, page 33-3):

where

VISUM uses the following standard values: 4 s for the critical gap and 3 s for the follow-uptime. You can optionally overwrite both values by lane.Pedestrians have a bearing on the capacity. For a detailed description, please refer to HCM2010, pages 21-16 and 21-17.To the turns, the approach capacity is distributed in proportion to the volume. The result isstored in the turn attribute ICAFinalCapacity.

step 4: Wait timesThe mean wait time on a lane of an approach arises from the following values:

The mean delay of a turn is the volume weighted mean of the mean delay of lanes used. Theresult is saved in the turn attribute tCur.

c capacity in PCU/h

v conflicting flow in PCU/h

gapc critical gap in s

gapf follow-up time in s

d mean delay in s/PCU

c lane capacity in PCU/h

v lane volume in PCU/h

T observation period in h

c Ae Bv–=

A 3600gapf------------=

Bgapc gapf 2⁄–

3600------------------------------------=

d 3600c

------------ 900T vc-- 1– v

c-- 1–⎝ ⎠

⎛ ⎞ 23600

c------------ v

c--⋅

450T-------------------++ 5 min× v

c-- 1,+ +=

253 © PTV AG


step 5: Queue lengthsThe mean queue length on a lane of an approach arises from the following values:

where

The attribute ICAQueueLength is the maximum of the Q95 percentiles for the lanes used.

step 6: Level of Service (LOS)LOS per lane of an approach is defined as a classification of the mean delay (Table 87).

The HCM does not determine the calculation of the LOS per approach, turn or node.In thesecases VISUM calculates the LOS on the basis of the volume weighted mean delay. If thevolume exceeds the capacity, the LOS is automatically set to F.

5.5.3.6 Roundabouts according to the TRL/Kimber 2010 methodThis analysis method regards approach capacity as a function of geometry and the conflictingvolume in roundabouts. On the basis of numerous observations, this function was calibrated toBritish roundabouts.illustration 64 shows the calculation process for roundabouts according to the TRL/Kimbermethod.

Q95 95% percentile of queue length in PCU

c lane capacity in PCU/h

v lane volume in PCU/h

T observation period in h

LOS Mean Delay [s / PCU]

A 0 - 10

B >10 - 15

C >15 - 25

D >25 - 35

E >35 - 50

F >50

Table 87: LOS per lane based on the mean delay

Q95 900T vc-- 1– 1 v

c--–⎝ ⎠

⎛ ⎞ 23600

c------------ v

c--⋅

150T-------------------++ 3600

c------------⋅=

254 © PTV AG


Illustration 64: Calculation process for roundabouts according to the TRL/Kimber method

In VISUM, the geometry of the roundabout is described through leg attributes. These attributesare only important, if the node is a roundabout and if TRL/Kimber is selected as analysismethod. In all other cases, the parameters are ignored at ICA calculation. The meaning of theparameter is illustrated illustration 65, which has been taken from the DMRB guideline TD 16/93. For a better comparison with this guideline, the common English original attributes andabbreviations are specified in the tabular overviews. Another parameter describes thetemporal variability of the inflow.


VolumeIncoming legs

Conflicting volumes

Capacity

Waiting timeQueue length

255 © PTV AG


Illustration 65: Description of the node geometry for the TRL/Kimber model

Table 88 shows the additional input attributes at links for calculation according to TRL/Kimber.

Name DMRB definition Value type

Value range (Default value)

Meaning

ICA inscribed circle diameter

ICAInscribedCircleDiameter (D)

Length 10 - 200 m (40 m)

External diameter of the roundabout. For asymmetric roundabouts specify the radius related to the environment of the respective approach.

ICA entry width ICAEntryWidth (e)

Length 3 - 20 m (7 m) Width of the entry directly at roundabout

Table 88: Input attributes for calculation according to the TRL/Kimber method

256 © PTV AG


These attributes are only important, if the ToNode of the link has the controller typeroundabout, i.e. the link represents an approach to a roundabout. In all other cases theattributes are ignored. The output attributes correspond to those for signalized intersections (Table 71).

step 1: Traffic flows and conflicting volumes for each approachAll calculations are based on the traffic flows and conflicting volumes at each approach. Thesetraffic flows are derived from the turn volumes. All volumes are expressed in PCUs.

step 2: Approach capacitiesFor roundabouts with RDistanceExit = 0, the following applies:

where

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.

ICA entry radius ICAEntryRadius (r)

Length 1 - 1000 m (35 m)

Circle radius which tangentially approximates to the outer circle of the roundabout and the outer boundary of the approach.

ICA entry angle ICAEntryAngle (Φ)

Integer 0°..180° (45°) See illustration 65

ICA grade separation ICAGradeSeparation (SEP)

Length 0 - 100 m (0 m) Distance between approach and exit of the same node leg. For regular roundabouts specify 0 m. With values > 0 you describe the approaches at expanded roundabouts, where the approach is far away from the exit of the same leg.

ICAKimberHollis c-factor ICAKimberHollisC

Double

0 10 (1.0) In the queue length formula by Kimber-Hollis, the c-factor describes the variability of the inflow

Cap approach capacity in PCU/h

Name DMRB definition Value type

Value range (Default value)

Meaning

Table 88: Input attributes for calculation according to the TRL/Kimber method

Capk F f qc⋅–( ) if F f qc⋅>⋅

0 else⎩⎨⎧

=

257 © PTV AG


The remaining variable descriptions refer to the attributes of the geometry description.Different from the above mentioned, the following applies for roundabouts with RDistanceExit> 0:Cap =1.004F - 0.036SEP - 0.232 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 issaved in PCU/h in the turn attribute ICAFinalCapacity.

step 3: Queue lengthsThe queue length of an approach results from the Kimber and Hollis formula (Kimber, Hollis1979), (Kimber, Daly 1986).

where

VISUM uses the formula modified in (Kimber, Hollis 79) for increased accuracy.The mean queue length of each turn is equal to the mean queue length of its approach and isstored in the turn attribute ICAQueueLength.

qc conflicting flow in PCU/h

k 1 - 0,00347 • (Φ - 30 ) - 0,978 • [(1/r) - 0.05]

F 303 x

f 0.21 t (1 + 0.2 x)

t 1 + .5 / (1 + M)

M e(D - 60)/10

x v + (e - v) / (1 + 2 S)

S 1.6 (e - v) / L‘

L expected queue length at the end of the observation period in PC units

μ approach capacity in PCar units/h

T length of the observation period in h

L0 initial queue length(in VISUM always 0)

C Variation factor KVKimberHollisC

v approach volume in PCar units/h

ρ = v / μ = Saturation

A1 ρ–( ) μT( )2 1 L0–( )μT 2 1 C–( ) L0 ρμT+( )–+

μT 1 C–+-------------------------------------------------------------------------------------------------------------------------=

B4 L0 ρμT+( ) μT 1 C–( ) L0 ρμT+( )–( )

μT 1 C–+-----------------------------------------------------------------------------------------------=

L 12--- A2 B+ A–( )⋅=

258 © PTV AG


step 4: DelaysThe mean control-based wait time per approach results from the Kimber and Hollis formula(Kimber, Hollis 1979), (Kimber, Daly 1986).

where

The mean permitted delay of a turn is equal to the mean permitted delay of its approach and issaved in the turn attribute tCur.VISUM evaluates, like in Step 3, the increased accuracy modified formula by Kimber andHollis.

step 5: Level of Service (LOS)The concept of a LOS is not mentioned in the Kimber model. To create consistency within ICAand because the RFC (Ratio Flow to Capacity) skim was criticized as being insufficient, VISUMstill defines a LOS per approach as a classification of the mean delay (Table 89).

VISUM calculates the LOS of the entire node accordingly, on the basis of the volume weightedmean delay of all approaches.

d mean permitted delay in the observation period in h

μ Approach capacity in PCar units/h

T length of the observation period in h

L0 initial queue length (in VISUM always 0)

C Variation factor KVKimberHollisC

v approach volume in PCar units/h

ρ = v / μ = Saturation

LOS Mean Delay [s / PCU]

A 0 - 10

B >10 - 15

C >15 - 25

D >25 - 35

E >35 - 50

F >50

Table 89: LOS for calculation according to Kimber based on the mean delay

J T2--- 1 ρ–( ) 1

μ--- L0 C– 2+( )–⋅=

K 4μ--- T

2--- 1 ρ–( ) 1

2---ρTC

L0 1+μ

--------------- 1 C–( )–+=

d 12--- J2 K+ J–( )=

259 © PTV AG


5.5.4 Signal timing optimization.Within the scope of the intersection capacity analysis using ICA, you can optimize the signaltimes for individual signalized junctions in two ways:• Green time optimization (see "Green time optimization for stage-based signal controls" on

page 261) or • Cycle and Green time optimization (see "Signal cycle and green time optimization" on

page 262).Furthermore, with signal coordination you can optimize the time intervals between more thanone light signal control in the network (see "Signal coordination (Signal offset optimization)" onpage 262).

5.5.4.1 Data model for SC cycle and green time optimizationThe following network object attributes are relevant for signal timing optimization:

Optimization is controlled by the following procedure parameters (components of theprocedure parameters for intersection capacity analysis):

Network object type Attribute Description

Signal control and subordinate objects

All attributes which describe signal times

Signal times and stage distribution in the initial state

SC Reference to signal coordination groups

At cycle time optimization with procedure parameters UseCycleTimeFamily=True, only one member of the cycle time family of the coordination group is selected as a new cycle time.

SignalCoordinationGroup

CycleTimeFamily

SC ICA Maximum cycle time for optimizationICA 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 node1 = only green time optimization2 = cycle and green time optimization

Turns The attribute for the design hourly volume set in the procedure parameters

Turn volumes

Node model and subordinate objects

All geometry attributes Lane allocation at node

Procedure parameter Data type (Standard)

Description

Automatic green time optimization

Boole (False) Are the signal times always optimized within the ICA calculation? If yes, it depends on the SC attribute Optimization method which optimization method is applied to which SC.

260 © PTV AG


5.5.4.2 Green time optimization for stage-based signal controlsThe predefined cycle time applies as predefined for pure green time optimization. The followingsteps are necessary for calculating the green time split:1. Deconstruct approaches into lane groups (already calculated for capacity analysis).2. Calculate adjusted volume and saturation flow rate for each lane group (already calculated

for capacity analysis).3. For each stage in the signal timing plan, determine the critical lane group.4. Allocate green time based on critical lane group volume/saturation flow rate ratios.5. Check that the allocated green times meet all the constraints.Green time split is calculated as follows:

where

The total effective green time for a cycle is the same as the cycle time deducting all intergreensbetween consecutive stages. The intergreen between two stages is zero, if the stages sharesignal groups. Otherwise, intergreen is given by the attribute StdIntergreen of the signalcontrol.Each stage must also maintain the minimum green time, which is given by the minimum greentime attribute of the signal control. If the calculated green time for a stage is less than theminimum green time, then the green time split equation is rerun with the stage below itsminimum green time omitted. The omitted stage is assigned the minimum green time. Thatminimum green is subtracted from the total effective green time and the green time split isrecalculated.As a result of optimization, new values are assigned to the attributes GreenStart andGreenEnd of the stages.

5.5.4.3 Green time optimization for signal group-based signal controls

The optimization of signal group based signal controls results from the following steps of theprocedure for stage-based signal controls:

UseCycleTimeFamily Boole (True) At cycle time optimization with procedure parameters UseCycleTimeFamily=True, only one member of the cycle time family of the coordination group (if available) is selected as a new cycle time.

gi effective green time for stage i

(v/s)ci (v/s)ci = ratio of volume v and saturation flow rate s for critical lane group ci in stage i

Gte total effective green time for cycle

Procedure parameter Data type (Standard)

Description

( )( ) teG

icisv

cisviG

∑=

261 © PTV AG


1. Fictitious stages are generated from the current greentimes of the signal groups.2. The fictitious stage-based signal control is optimized as above (see "Green time

optimization for stage-based signal controls" on page 261).3. The signal group green times are read from the optimal stage distribution.

Step 1 - Creating fictitious stagesVISUM first defines set T of all switching points from the attributes GreenStart and GreenEndof all signal groups and sorts these in ascending order. For each interval between consecutivetime ti and ti+1 in T generate a stage which contains all signal groups which have been releasedduring [ti ; ti+1).

Step 2 – Optimization of the fictitious stage-based signal controlThe fictitious stage-based signal control is optimized as above (see "Green time optimizationfor stage-based signal controls" on page 261).

Step 3 - Extracting green timesGreen time for each signal group results from the green time of all stages which contain thesignal group. Because all of these are neighboring stages due to construction, there is only onegreen time for the signal group.

5.5.4.4 Signal cycle and green time optimizationIf you select the Signal cycle and split optimization for a node, VISUM calculates an optimalcycle time for the signal control at the node and at the same time an optimal green time split forthis cycle time. The calculation consists of the following steps:1. Set T of the permitted cycle times at the node is defined. If the procedure parameters

UseCycleTimeFamily = True and if the signal control belongs to a coordination group, onlythe cycle times of the cycle time family are permitted. Otherwise, all cycle times (integers inseconds) in the interval between the node attributes ICAMinCycletimeOpt andICAMaxCycletimeOpt are permitted.

2. For each permissible cycle time t from T the following applies:• Specify optimal greentime g*(t) for predefined cycle time t.• Via ICA calculate the total wait time at the node for g*(t).

3. As an optimal cycle time t* select the t with minimum total wait time. In addition, set theoptimal green time split g*(t*).

The ICA calculation of the total wait time at the node only provides final values, if the sum ofcritical v/s ratios is below or equal to 1. For larger sums it is always t* = max(T). If the sum ofthe minimum green time and intergreens for all stages or signal groups are larger than thecalculated t*, t* is set to the smallest t of T which is larger or equal to this sum. If no such texists, t* is set to the sum independently of T.

5.5.4.5 Signal coordination (Signal offset optimization)Signal cycle and split optimization always refers to individual signal controls. Signal offsetoptimization, however, is used to optimize the offset between the signal times of neighboringnodes in such a way, that vehicles can pass several consecutive signal controls on green. Thegeneral aim is to minimize the total wait time for all vehicles at the signal control.

262 © PTV AG


ExampleWe will demonstrate the task with the example network displayed in illustration 66.

Illustration 66: Example network for signal coordination

In the network in illustration 66 the six inner nodes have signal controls and the outer nodes areonly there to connect the four zones. Link and turn volumes result from an assignment. Laneallocation is usually selected, so that at each approach of a node, a shared lane exists for thestraight and right turns and a 100 m long pocket for left turns additionally. Additional lanes areonly located at individual approaches with an especially large traffic volume. All SC have thesame signal times (illustration 67).

Note: The method does not regard the attributes of the node geometry. Especially the stopline position per lane is not taken into consideration.

263 © PTV AG


Illustration 67: Green time split at all nodes with succeeding left turns

With a cycle time of 80 s, straight and right turns each have a green time of 30 s. Signal groupsfor 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 issufficient for all turns. Wait times can occur if neighboring SCs are badly coordinated. For thisexample we first assume an offset time of 0 s for all SC. The assignment result illustrated bylink bars results as overlapping of seven paths and one of these is highlighted in theillustration 68.

264 © PTV AG


Illustration 68: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002

This route passes the signalized nodes 7003, 8003, 8002 and 9002. Vehicles which exit node7003 in direction 8003, when exiting create a platoon, which starts at the beginning of thegreen time, thus at second 0. The travel time tCur on the link from 7003 to 8003 is 38 s. Withouttaking the platoon resolution into consideration, the peak of the platoon reaches node 8003 atsecond 38. The distribution of the actually driven speed by vehicles leads to a resolution of theoriginal compact platoon (illustration 69).

Illustration 69: Progression quality for approach West at node 8003

On the left, the diagram shows the arrival rate by cycle second. The first vehicles arrive atsecond 30. The arrival rate then steeply increases and decreases as of second 52. The signal

265 © PTV AG


group to continue the journey also has a green time between second 0 and 30. The major partof the platoon therefore reaches the node at red. The second diagram shows thecorresponding development of the queue length and the third diagram the resulting wait timein vehicle seconds dependant on the arrival second. Summing up all arrivals results in a totalwait time of 19069 vehicle seconds, correspondent to a mean value of 39.20 s per vehicle. Thisis an example for bad coordination.At node 8002 the situation is much better (illustration 70).

Illustration 70: Progression quality for approach North at node 8002

Again the platoon starts at second 0 and the travel time on the link 8003 - 8002 with tCur = 41s is similar as before, but the continuing signal group 4 for left turns at node 8002 has a greentime from second 40 to second 75. Here the main part of the platoon enters during green time,queues are distinctly shorter and the total wait time is only 1608.80 vehicle seconds (inaverage 4.37 s per vehicle).Aim of the signal coordination in this simple example would be to change the offset betweennodes 7003 and 8003 in such a way, that the platoon fully enters 8003 at green. At the sametime, however, to maintain the convenient offset between 8003 and 8002. Because aconvenient 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 bychanging the offset times.

ModelSignal coordination in VISUM can be used for optimizing SCs in a network, not only along alinear corridor, as it corresponds with the traditional optimization of green waves. This sectiondescribes how the optimization model is set up, which VISUM solves by using a standardprocedure for mixed integer linear optimization. All attributes which describe input and outputof the procedure are summarized in the following section (see "Input attributes with effect atsignal coordination" on page 269).Good coordination requires the SCs either have the same cycle times or that the cycle timesare at least in a simple ratio (for example 2:1). Furthermore, SCs have to be located close toeach other, otherwise the platoon will have broken up so heavily by the time it has reached thenext SC, that the arrivals will virtually be uniformly distributed and the wait time cannot beinfluenced through the choice of the offset. It is therefore generally not sensible to coordinateall SCs in one network. You determine which SCs should be coordinated, by defining signal

266 © PTV AG


coordination groups and assigning them SCs (see User Manual, Chpt. 2.39.14, page 539). Bydefault, 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 thecorresponding SC. Please make sure that the cycle times actually make coordination possible.Two SCs with cycle times of 60 s and 65 s can generally not be coordinated because theplatoon in each cycle takes place at a different cycle second. Suitable cycle times thereforehave a small LCM (least common multiple), for example, the family { 60 s, 80 s, 120 s } withLCM = 240 s. Signal coordination optimizes offset times for each signal coordination groupseparately and takes those SCs into consideration with cycle times belonging to the permittedcycle times of the group. SCs with deviating cycle times are ignored and logged in the error file.Important for coordination is the behavior of the vehicle platoon during the journey from one SCto another. VISUM determines platoons by analyzing the assignment results for one or moreselected PrT demand segments. From the saved paths of the assignment, VISUM determineshow many vehicles on their way first pass signal group SG1 of the SC SC1 and then signalgroup SG2 of the SC SC2. We call such a combination of two consecutive signal groups withone 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 saturationAll 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 isassumed 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 thesaturation flow rate qmax, until the volume per cycle has been exhausted. The following applies:

Here, N is the effective number of lanes for the turn. If the green time duration is insufficient anddoes not allow the volume allocated to a cycle from the assignment to exit with qmax, VISUMignores the excess volume and logs this in the error file. The platoon resolution, solely caused by different vehicle speeds, describes the platoondevelopment formula according to Robertson. This model discretely divides the time inincrements (in VISUM of 1 s) and displays the number at time t‘, at which a vehicle arrives atthe end of a path leg as a function of the number at time t < t‘, at the beginning of the path legdeparting vehicle.

where

qmax 1900PCUh

------------ N⋅=

q't βT+ F qt⋅ 1 F–( ) q't βT 1–+⋅+=

267 © PTV AG


For calculating queue lengths it is presumed that separate lanes of sufficient length exist forseparate signal groups at an approach. VISUM generally assumes "vertical" queues for signalcoordination and does therefore not consider spillback upstream over several links or have aneffect on the capacity of the turns of other signal groups.For the evaluation of the progression quality, VISUM calculates a number of skims which areused throughout literature. In the subsequent formulas CT determines the cycle time, GT thegreen time and qt the number of vehicles arriving at a node in time step t.

Platoon index = with

This size measures the "distance" of a volume profile of an equal distribution. The value variesfrom 0 (equal distribution) to 2 (for a distinct platoon). A high value means that coordination isworthwhile at this node, because the arriving vehicles are focused on part of the cycle time, sothat there is a chance of moving the green time there, by changing the offset time.

Vehicles at green = .

This size directly measures how well coordination works. It calculates which part of the volumepasses the node without stopping at the SC.

Platoon ratio =

The size also measures how well coordination works, whereas high values imply goodcoordination. Especially high values are achieved when a large share of arrivals enter at green,although the green ratio itself is smaller.Platoon ratio PR is the basis for the important ArrivalType size in waiting time calculationaccording to HCM.

q‘t 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

F with specified constants α and β

T travel time tCur on the path leg

F 11 αβT+--------------------=

qt avg–t CT∈∑

qtt CT∈∑------------------------------------------- avg

qtt CT∈∑CT

-------------------------=

100qtt GT∈∑qtt CT∈∑

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

qtt GT∈∑qtt CT∈∑

------------------------⎝ ⎠⎜ ⎟⎛ ⎞ GT

CT--------⎝ ⎠

⎛ ⎞⁄

268 © PTV AG


ArrivalType =

Queue length queuet at a signal group to cycle second t results from the difference ofcumulative inflows and exit flows.For this calculation, VISUM also calculates the delays ofvehicles with specified arrival time in the queues and hence, the mean and total wait time.

Input attributes with effect at signal coordinationSignal coordination accesses the network objects and the input attributes displayed inTable 90.

Output attributes at signal coordinationThe effect of the signal coordination lies mainly in assigning the attribute offset of thecoordinated 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 anetwork model, VISUM aggregates the values of all skims on links and saves the results as linkattributes. VISUM allocates the attributes at all approach links to signalized nodes which havea volume of > 0. All link attributes for signal coordination results are contained in the Table 91.

Note: Node geometry attributes such as the stop line position, for example, are not regardedfor signal coordination.

Network object Attributes Note

PrT paths Volume From assignment

Links, turns, main turns A freely selectable attribute

Is interpreted as travel time and will be summed up for travel time calculation per path leg

SC with all components All Signal timing, cycle time, mapping of signal groups and lane turns, selection of a reference SC that has offset = 0.

Signal coordination groups

Cycle time family and assigned SC

Grouping of the SCs to be coordinated collectively

Table 90: Input attributes with effect at signal coordination

1 if PR< 0.52 if 0.5 <= PR< 0.853 if 0.85 <= PR< 1.154 if 1.15 <= PR< 1.55 if 1.5 <= PR< 2.06 if 2.0 <= PR

⎩⎪⎪⎪⎪⎨⎪⎪⎪⎪⎧

269 © PTV AG


.

Procedure parametersAlongside the network object attributes, the procedure parameters listed in Table 92 controlsignal coordination.

Name Value type

Value range Meaning

SC Coord Veh on Green Double 0.0 .. 100.0 Number of vehicles which arrive during green time [%]

SC Coord Platoon Index Double 0.0 .. 2.0 Definition see above

SC Coord Platoon Ratio Double 0.0 .. Definition see above

SC Coord Arrival Type Integer 1 .. 6 Definition see above

SC Coord Wait Time Time period

0 s .. Total wait time [Vehicle seconds]

SC Coord Max Queue Length

Double 0.0 .. max. number of queued vehicles over all cycle seconds [Veh]

Table 91: Output attributes for signal coordination results

Note: Attribute SC Coord Arrival Type is marked as the signal coordination with the nameprefix. It is not identical to the ICA Arrival Type attribute, which is used as entry for ICAcalculation. If you want to calculate the ICA impedance with an ArrivalType whichcorresponds with the set offset time intervals, first perform the coordination analysis andcopy the SC Coord Arrival Type values to the ICA Arrival Type attribute.

Name Value range (Standard) Meaning

Automatic Analysis Boole (True) After signal coordination, the output link attributes are automatically updated.

Coordination group set Set of coordination groups (all)

Coordination is only carried out optionally for selected signal coordination groups.

Demand segments set Set of assigned PrT_DSeg (all assigned PrT_DSeg)

Path legs are optionally only determined from the assignment paths selected DSeg.

MaxSaturation Double > 0 (80%), in percent

If this saturation is exceeded on a path leg link, the path leg is ignored for coordination, because no platoon is retained with too high saturation.

MinPlatoonIndex Double > 0 (0.4) If the platoon index is below this threshold at the end of the path leg, the path leg is ignored for coordination, because the platoon is not distinct enough.

RobertsonAlpha Double > 0 (0.35) Parameter for the platoon progression formula according to Robertson

RobertsonBeta Double > 0 (0.8) Parameter for the platoon progression formula according to Robertson

Table 92: Procedure parameters for signal coordination

270 © PTV AG

Chapter 5.6: PrT skims

Problem solutionTo determine an optimal set of offset times per SC, VISUM sets up a mixed integer linearoptimization problem. The deciding variables in this problem are the differences of the offsettimes of neighboring SCs, the objective function is an in sections linearized approximation ofthe wait time in dependency thereof. Secondary conditions express that the differencesbetween the offset times of adjacent SCs along each circle in the network have to be added toan integer multiple of the cycle time.A detailed description of the method is found in Möhring, Nökel, Wünsch 2006.

5.6 PrT skimsWith the Calculate PrT skim matrix procedure the PrT skims which are listed in Table 93 canbe calculated (see User Manual, Chpt. 5.8, page 933).

TravelTimeLinkAttr numeric link attribute (AddValue1)

When calculating the path leg travel time, for each traversed link, TravelTimeLinkFac • TravelTimeLinkAttr is summed upTravelTimeLinkFac Double > 0 (1.0)

TravelTimeTurnAttr Numeric turn attribute (AddVal1)

When calculating the path leg run time, for each traversed turn, TravelTimeTurnFac • TravelTimeTurnAttr is summed upTravelTimeTurnFac Double > 0 (1.0)

TravelTimeMainTurnAttr Numeric main turn attributes (AddVal1)

When calculating the path leg run time, for each traversed turn, TravelTimeMainTurnFac • TravelTimeMainTurnAttr is summed up

TravelTimeMainTurnFac Double > 0 (1.0)

MaxCalculationTime Time period Calculation time for the solution of the optimization problem is restricted. The best solution found up to the specified time limitation, is assigned.

Name Value range (Standard) Meaning

Table 92: Procedure parameters for signal coordination

t0_PrTSys TSys-specific travel time t0 in unloaded network

tCur_PrTSys TSys-specific travel time tCur in loaded network

AddValue1...3 Sum of AddValue

Trip distance Distance covered from origin to destination

Direct distance Direct distance between origin and destination zone

Speed v0_PrTSys TSys-specific speed v0 in unloaded network

Speed vCur_PrTSys TSys-specific speed vCur in loaded network

Toll Toll of traversed links

Impedance-PrTSys TSys-specific impedance in unloaded network

AddValue-TSys Sum of TSys-AddValue data

Table 93: PrT skims

271 © PTV AG


Calculating skims is either done via the best path as regards to the set criterion or viaaggregation from the paths of an assignment result calculated beforehand. In this case you canselect one of the aggregation functions listed in Table 94.

Moreover, the set of origin-destination relations for skims can be calculated, and also restrictedlike the type of network objects which are included in the skim calculation.

5.7 Distribution of the traffic demand to PrT connectorsThe distribution of PrT origin and destination demand onto PrT connectors can be done freelyor proportionally. In the case of proportional distribution, two options are differentiated yetagain (distribution of the total demand or distribution per OD pair).• Free distribution

During route search, only the connector time is considered and traffic demand is distributedwithout further constraints onto the routes with the lowest impedance.

• Proportional distribution of total trafficBefore the route search is carried out, the share of total origin and destination traffic iscalculated for every zone whose demand is to be distributed proportionally. From this, avirtual connector capacity (= proportion • origin/destination demand) can be deduced forevery connector which modifies the impedance of the connectors during assignment insuch a way that proportional distribution is achieved. The correspondence between thedistribution of the assignment and the predefined values depends on the selectedassignment procedure and the selected VD function for connectors. A steep VD functionshould be used. In addition to this, the connector times must not be too low so that theconnector impedance has an effect on the route search. When using this option, it shouldbe noted, that the distribution may have very different effects on the individual OD pairs. Ifthe link impedance equals the displayed lengths, practically all trips from zone 1 to zone 3lead via node 2. The vast majority of trips from zone 1 to zone 2 however are made via node1.

User-defined Flexible calculation of a mean attribute value per OD pair, the linkage of attributes of different traversed network objects is also possible (see "Using user-defined PrT skims" on page 935)

Minimum impedance Skim value calculated from the path with minimum impedance

Maximum impedance Skim value calculated from the path with maximum impedance

Mean over paths Skim value calculated as a mean over all paths

Mean over path volume Skim value calculated as a mean over all paths weighted with the corresponding path volume

Table 94: Aggregation functions for the skim data calculation

Table 93: PrT skims

272 © PTV AG

Chapter 5.8: Blocking back model

Illustration 71: Example network for proportional distribution of the traffic demand

Example: Example: determination of connector capacity for proportional distribution totaltraffic (illustration 71)Zone 1 has proportional distributionZone 2 has proportional or absolute distributionZone 3 has proportional or absolute distributionTravel demand from zone 1 to zone 2: 1000 tripsTravel demand from zone 1 to zone 3: 400 tripsOrigin demand zone 1: 1400 tripsConnector zone 1 node 1: 40 % proportionConnector zone 1 node 2: 60 % proportionCapacity of connector zone 1 node 1: 40 % x 1400 = 560 tripsCapacity of connector zone 1 node 2: 60 % x 1400 = 840 tripsSteep VD function for connectors, for example BPR function with a = 1, b ³ 4, χ £ 1

• Proportional distribution of each individual relationAlternatively, the proportional distribution can be applied to each OD pair. This leads to thefollowing distribution in the example above:Example: determination of connector capacity for proportional distribution per OD pair:Zone 1 node 1 zone 2: 40 % • 1000 = 400 tripsZone 1 node 1 zone 3: 40 % • 400 = 160 tripsZone 1 node 2 zone 2: 60 % • 1000 = 600 tripsZone 1 node 2 zone 3: 60 % • 400 = 240 trips

5.8 Blocking back modelThe blocking back model (pseudo-dynamic assignment, pa) fills the gap between merely staticprocedures, which do not have any temporal reference and cannot determine congestion-related wait times, and dynamic procedures that require long computation times. Theprocedure is much faster than any dynamic assignment, requires less memory capacity and

Zone1

1

2

3 Zone2

40 %

60 %

4 Zone3

273 © PTV AG


can furthermore deliver information on congestion phenomena. The procedure can be appliedin conjunction with a static assignment in order to estimate queue lengths and wait times inoversaturated networks, and – in contrast to the dynamic-stochastic assignment - is suitablefor networks with > 50,000 links. The procedure requires little additional data for the temporaldistribution of the demand.The general idea is to re-assign route volumes that were calculated with any static assignmentat 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 linksThe original volumes of links, connectors and (main) turns resulting from the assignment arestored with the following attributes:• Volume demand PrT with base,• Volume demand DSeg• Volume demand PrTOriginal node volumes can be found in the following attribute:• Volume demand PrTThe 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 restrictingcapacity has been reached. The following rules apply in this process.1. The volume passing over a link cannot exceed the link’s PrT capacity. The amount of traffic

leaving the link counts (bottleneck at end of link).2. The queue on a link can never exceed the stocking capacity of the link.3. As soon as a queue forms on a link in some direction, no traffic can pass the link even if the

respective route does not lead across the bottleneck that is causing the congestion.The fourth rule which limits the inflow of a link, directly results from this.4. The inflow of traffic on a link is limited to the amount resulting from capacity plus stocking

capacity.

Phase 2 (precise wait time calculation)Already in phase 1, wait times are calculated from the resulting queue lengths and the durationof this phase. In the optional phase 2, more precise wait times are calculated by simulating alsothe discharge of the congestion. New traffic is not imported, but rather the traffic stored in thelocal queue lengths is distributed along the routes according to the same rules as in the firstphase. This is done in small time steps, where the capacities still limit the inflow. After eachstep, the level of congestion is stored The second stage ends, when all local congestion is zeroand thus no traffic remains in the network. This results in a series of snap shots of the level ofcongestion at different times which are then used to calculate a delay.

274 © PTV AG


5.8.1 General notes on the blocking back modelThe blocking back model is no independent assignment procedure, but it modifies the resultsof previously run assignments or of the running assignment. As an option, the blocking backmodel can be carried out together with an assignment (see User Manual, Chpt. 5.5, page 883).The blocking back model only applies to PrT transport systems. Assuming that PuT transportsystems are either not affected by any congestion or that the timetables used already regardthe wait times. PuT-caused congestion on commonly used links can be neglected or can beconsidered by a preloaded volume.Since volumes of different PrT demand segments are summed up before entering the queuelength, all volumes are invariably converted into car units.The following two operating modes are possible.• You can calculate the blocking back model post-processed following an assignment. It

therefore does not influence the route choice.• Alternatively, you can execute the blocking back model in the external iteration of an

assignment procedure. The results are then included in the link impedance and thereforein the route choice. This modus operandi is not recommended, since it significantlydowngrades the convergence of the particular assignment procedure. To take the blockingback impact on the route choice into consideration during the assignment, you shouldrather use the procedure „Assignment with ICA“ (see "Assignment with ICA" on page 332).

In either case it can be combined with the following assignment procedures: Incremental,Equilibrium, Equilibrium_Lohse, TRIBUT and any stochastic procedure. However, it cannot becombined with a dynamic assignment procedure.If an assignment has been calculated for a demand segment already, which is not to berecalculated, the blocking back model is calculated prior to the execution of the assignment ofthe already assigned demand segments. This is to ensure that the values for tcur and tw areconsistent with the current network status and to avoid that assignments with a blocking backmodel share and those without are combined.If the blocking back model is integrated in other procedures for calculation, one has todifferentiate between the successively performed procedures (Incremental assignment,Equilibrium_Lohse and the Stochastic assignment) on the one hand and the balancingassignments (Equilibrium assignment and TRIBUT procedures) on the other hand. Whencalculating the step-by-step procedures, the blocking back model always determines acorrected volume and delays after the calculation of the volume. From the rectified volume, anew value is calculated for the current travel time tiCur in iteration i, to which the wait time tiw isadded.

As new value, the arithmetic mean Ti of all former ti is used, which is also considered in thesubsequent route search.

Here, t0Cur = t0 and t0w = 0 applies.

ti takti tw

i+=

Titk

k 0=

i∑

i 1+---------------------

taktk

k 0=

i∑ tw

k+

i 1+-------------------------------------= =

275 © PTV AG


The consideration of earlier values guarantees the necessary attenuation and enforces theprocedure’s convergence. If only the current value would be taken into account whencalculating the impedances in the next iteration, the total traffic volume would shift back andforth 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 determinedduring the previous calculation of the blocking back model. In the case of convergence, it isconsistent 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 volume-delay functions but modeled by explicitly calculated wait times.

• If there is neither any congestion nor a decrease in the volume due to a flow-rate loss, tCur

= tCurNew and tw = 0 apply in any case. The impedance is unchanged compared to a

conventional assignment in this case.If the blocking back model is integrated into an equilibrium assignment, the selected procedureis calculated first and the blocking back model is calculated subsequently in an outer loop. Bothmethods are based on the fact that the volume of a link equals the total volume of all routestraversing that link. For that reason a link-related modification of the volume, as performed bythe blocking back model would have no effect.Instead, the result of the calculation of the blocking back model is used to modify the VDfunctions of each link temporarily so that identical travel times result for unchanged networkvolumes and for the changed network volumes with the original VD functions. These modifiedVD functions can then be used for another iteration of an equilibrium assignment. If thenetwork volume has not changed, an equilibrium state has been reached which regards themodified travel times tCur that result from the blocking back model. Otherwise a further iterationis carried out, that includes blocking back model and assignment. As is the case with othermethods, the modified VD functions are averaged over several iteration steps in order tosuppress the alternation of the route choice between several alternatives.The equilibrium state that is reached by this integrated calculation procedure is characterizedas 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 capacityAccording to rule 1, the traffic flow from link to link along a route is limited by the capacity of thelink and the capacity of the link's ToNode and the capacity of the turn during the blocking backmodel calculation. In the blocking back model parameters you can select individually, whetherlink 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 optionis only provided for compliance with out-dated versions. It is no longer recommended. It isrecommended to use the option 'Turn capacity' instead.

• Node capacity restricts the flow via a node (sum of all turn volumes) to the node attributeCapacity PrT. Node capacities are only regarded for traffic flows traversing a minor link(TModelSpecial = true) in the direction to the node. Traffic flows on major legs thereforealso have an effect on crossing routes via secondary links.

276 © PTV AG


• Turn capacity restricts the flow per turn to the turn attribute Capacity PrT.These three options can be combined at will.Furthermore you can decide by node, whether the global blocking back model parametersettings are to be regarded; alternatively, a node-specific setting (node attribute Use presetblocking back capacity settings = TRUE) can be used instead. The node-specific setting isregarded for all turns via this node and for all links leading into this node. To regard the turncapacity only at particular nodes, for example, then exclude the consideration of turn capacitiesin the global blocking back model parameters and select TRUE for the attributes Use presetblocking back capacity settings and Use turn capacity in blocking back at the particularnodes.

5.8.2 Procedure of the blocking back modelThe procedure is divided into the following steps:• Determining the excess congestion factor• Formation of congestion (Phase 1)• Relief of congestion (Phase 2)• Determining the wait times

Determining the excess congestion factorPrior to the actual simulation of the queuing up, the excess congestion factor is calculated forthe network. In this process, the volumes and capacities of the links, nodes and turns for whichyou have preset that they are to be regarded are taken into account.For a single link S, the excess congestion factor σLink(S) is given by

.

Here, Vol(S) is the link volume resulting from assignment, Cap(S) is the PrT capacity of the link,and ScalingFactor is the scaling factor from the blocking back model parameters. Furthermore,qPreload(S) is a basic link volume that can be set in the "Procedures" dialog via PrT functions >Assignment.Analogously, excess congestion factors σTurn(T) and σNode(N) are defined for turns T and nodesN. (Since basic volumes can only be preset for links and turns in VISUM, the sum of all turncapacities of a node is used as basic volume for nodes.) Now, the excess congestion factor σof the network is the maximum of the excess congestion factors of all links, nodes, and turns,whose capacities are to be taken into account. It indicates by which factor the (remaining)capacity in the network is exceeded at most.The percentage of traffic corresponding to the reciprocal of this number can pass through thenetwork without any congestion. If σ ≤ 1, the procedure is not carried out. In this case, thecorrected volumes equal the volumes calculated in the assignment, thus no congestion occurs.If the denominator in the formula for the excess congestion factor calculation falls below 0 orbecomes 0 for a link or node or turn, there is no more free capacity available and the procedureterminates.

σLink S( ) Vol S( )Cap S( ) ScalingFactor⋅ qpreloadedVolume S( )–---------------------------------------------------------------------------------------------------------------------=

277 © PTV AG


Simulation phase 1 – Formation of congestionIn phase 1, queue lengths on links and connectors are calculated and also the reduced(compared to the original values) volumes of links, turns and nodes. Thereto, we let traffic flowinto the network step by step along the routes resulting from assignment, and in contrast to theprevious assignment, the rules 1 to 3 are observed here. (However, rule 3 is weakened by thepermeability factor P which determines the share that can pass existing congestions. If P = 0,rule 3 is satisfied).Let N be the number of shares for the volume distribution in phase 1. (This parameter can beset 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 untilwe reach a link on which a queue has already formed or for which the capacity is exceeded.This is carried out N times until all of the traffic has flown into the network. In this case, thecurrent 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 importantabbreviations used in this section:

Firstly, the network is loaded with that portion of demand which does not cause congestionsyet. Then, the remaining demand flows into the network step-by-step. At first, the greatestnatural number n is determined, that satisfies n/N ≤ 1/σ. (σ is the excess congestion factor.) Thegeneral process is then as follows:

Loading a volume flow to a route R is performed as follows. Let S0, S1, ..., Sk be the generalizedlinks of a route, i.e. S0 is the origin connector, Sk is the destination connector, and the real linksare in between. Now, the traffic from the origin zone flows via S0, S1, ..., Sk to the destinationzone, at which the flow is always limited by the capacities of the links and turns and nodes andby congestions that might have formed.Capacities bear limiting effects as described below. Let toNode(S) be the 'To node' of a link Sand let Turn(S,T) be the turn from S to T for the links S and T. Now, the flow from Sj to Sj+1 islimited by the capacity of Sj, and by the capacity of the 'To node' of Sj, and by the capacity ofthe turn to Sj+1. (If you have decided that a particular capacity should not have an effect, thenthe calculation assumes an infinite capacity. Connectors have an infinite capacity bydefinition.) Thus, the maximum flow from Sj to Sj+1 is as follows:

Vol Original volume resulting from assignment

VolBB (reduced) volume calculated in phase 1

Cap PrT capacity of a link, a turn or a node

C Stocking capacity of a link

Q Queue length of a link (or connector)

P Permeability of a link, describes the share of the flow that can pass existing queues

Initialize VolBB for all links, turns, nodes and connectors by entering 0.Initialize Q or all links and connectors by entering 0.For all links S and connectors C, load Vol(S)*n/N or Vol(C)*n/N, respectively.For j = n+1 to NFor each demand segment:For each route R of the demand segmentLoad Vol(R) / N to route R.

278 © PTV AG


maxFlow(Sj, Sj+1) = min{Cap(Sj) • ScalingFactor - qPreload(Sj), Cap(toNode(Sj)) • ScalingFactor - qPreload(toNode(Sj)), Cap(Turn(Sj, Sj+1)) • ScalingFactor - qPreload(Turn(Sj, Sj+1))}

If the amount of in-flowing traffic on a link of the route exceeds the amount, that can flow off tothe next link, then the portion of traffic that keeps flowing depends on the remaining freecapacity:

Traffic that cannot flow into the next link is added to the queue length. If the queue on a linkexceeds the maximum stocking capacity C, then backups will arise on previous links of theroute. In that process, the backup has to be subtracted from the volume(s) of the previouslink(s) again (also nodes and turns are concerned), since this flow actually cannot havereached the congested link being located ahead in the route course:

After phase 1, nodes require a special treatment for the following reason: Though there are noturns at connectors, connector nodes are loaded in the process. To achieve the state, that thenode volume = sum of all turn volumes at connector nodes after phase 1, the node volume ofconnector nodes is recalculated from the turn volumes after the procedure.We use a simple example with two routes to illustrate the procedure. Route 1 goes from A to Dand route 2 goes from B to C. Each route has a volume of 200 vehicles. The volume isdistributed to the routes in four iteration steps with 50 vehicles each. Route 1 is always chargedfirst. There is a bottleneck on route 1. On route 2, a backup arises though this route does nottraverse the bottleneck link.

Function Load(R, flow):For j = 0 to k-1propagatingFlow = flowIf Q(Sj) > 0propagatingFlow:= propagatingFlow * Permeability(Sj)

propagatingFlow:= min(propagatingFlow, maxFlow(Sj, Sj+1))VolBB(Sj) := VolBB(Sj) + propagatingFlowVolBB(toNode(Sj)) := VolBB(toNode(Sj)) + propagatingFlowVolBB(Turn(Sj, Sj+1)) := VolBB(Turn(Sj, Sj+1)) + propagatingFlowQ(Sj) := Q(Sj) + (flow - propagatingFlow)

Propagate queue backwards

Function PropagateQueue(R):propagatingQ = 0For j = k-1 to 1If Q(Sj) > K(Sj)propagatingQ := Q(Sj) - K(Sj)Q(Sj) > K(Sj)Q(Sj-1) := Q(Sj-1) + propagatingQVolBB(Sj-1) = VolBB(Sj-1) - propagatingQVolBB(toNode(Sj-1)) := VolBB(toNode(Sj-1)) - propagatingQVolBB(Turn(Sj-1, Sj)) := VolBB(Turn(Sj-1, Sj)) - propagatingQ

279 © PTV AG


Illustration 72: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2.

In the first two iteration steps, each of the two routes is loaded with 50 vehicles. Queues do notform yet (illustration 72).

Illustration 73: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1

Route 1: On the highlighted link, a bottleneck is located in iteration step 3. Due to theinsufficient stocking capacity of this link, the queue propagates to the preceding link(illustration 73).

280 © PTV AG



Since there is now a congestion on the link in the middle, also the vehicles following route 2 getstuck in the queue (illustration 74).


Route 1: 50 more vehicles are added in interation step 4. As the stocking capacity of the link inthe middle is fully exhausted, vehicles continue to propagate backwards (illustration 75).

281 © PTV AG



The 50 vehicles with route 2 cannot even reach the link in the middle; they all get stuck in thecongestion on the first link (illustration 76).

Simulation phase 2: Relief of congestionDuring the simulation phase 1, the local queue length of each link and corrected volumes havebeen determined. In order to determine a wait time as well, the simulation is continued withoutany further traffic flows entering the network until all queue lengths reach zero. Any trafficpassing through the network in phase 2 thus originates from the queues determined in phase1. In this process, a maximum of the M-th proportion of the capacity is passed on in eachiteration. (M represents the procedure parameter Number of shares for flow distribution inphase 2.) Accordingly, the M-th portion of the interval length of the first simulation phaseelapses 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 indetail.

Illustration 77: Blocking back model, phase 2, relief of congestion. Initial situation

282 © PTV AG


illustration 77 shows the initial situation prior to relief of congestion in phase 2. Only the queuelengths from phase 1 are regarded, there is no further influx. For congestion relief, four portionsare used (M = 4).

Illustration 78: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1

On route 1, the maximum congestion efflux is limited by the link capacity C = 100. Thus, C / M= 25 vehicles can flow off in iteration step 1 (illustration 78).

Illustration 79: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2

On route 2, the maximum congestion efflux is limited by the capacity of the link in the middle.Since two routes traverse the link in the middle, only a certain portion of the capacity isavailable for route 2 for this iteration, (C / M = 100); this portion is (C / M) • (OrigVol(Route 2) /OrigVol(link in the middle)) = 100 • (200 / 400) = 50 (illustration 79).

283 © PTV AG



During iteration step 2, again 25 vehicles flow off via route 1 (illustration 80).


Again, 50 vehicles flow off via route 2 (illustration 81).

284 © PTV AG



During iteration step 3 only some (12.5 ) vehicles flow off via route 1 which are part of theremaining 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 flowoff of the congestion for this iteration (C / M = 25) (illustration 82).


On the link in the middle, the remaining congestion can flow off via route 2 (illustration 83).Thus, the flow off in phase 2 works similar to the formation of the congestion in Phase 1; theonly difference is, that origin volumes do no longer arise from connectors, but from thecongested links. In each iteration, we let flow off a portion of the traffic which is restricted by thecapacities of the links and nodes and turns; thus, new queue lengths will be obtained. This isrepeated 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.

285 © PTV AG


In detail, the relief of congestion goes like this: In each iteration step, the Mth portion of thecapacity of links, nodes and turns is available. Thus, the maximum traffic that can flow off oflink S due to the link's capacity, is Cap(S) / M per iteration. To each route R, that traverses linkS, a certain share in the capacity is provided; this share equals the route's share in the originaltotal link volume, i.e. Vol(R) / Vol(S). For a link S that belongs to a route R, the maximum outflowof a congestion results from the following formula:maxOutflow(S) = (Cap(S) / M) • (Vol(R) / Vol(S))Furthermore, the outflow is restricted by the capacity of the To-Node and by the turn capacity.Let S0, S1, ..., Sk again be the generalized links of a route, i.e. S0 is the origin connector, Sk is thedestination connector, and the real links are in between. Thus, the maximum flow from Sj to Sj+1results as follows:maxOutflow(Sj, Sj+1) = min{(Cap(Sj) / M) • (Vol(R) / Vol(Sj)), (Cap(toNode(Sj)) / M) • (Vol(R) / Vol(toNode(Sj))), (Cap(Turn(Sj, Sj+1)) / M) • (Vol(R) / Vol(Turn(Sj, Sj+1)))}

The traffic flow that actually flows out comes from the existing queues. For each route R, thevolume originating from the queue on link Sj is as follows:

sourceVolQ(Sj) = prevQ(Sj) • (Vol(R) / Vol(Sj))

The source volume of a link (limited by maxOutflow) flows onto the next link; this volume isadded to the next link's source volume. If maxOutflow is less than the source volume, traffic willback-up again.Then, the following applies:

As in phase 1, the queue is propagated backwards:

Initialize prevQ with queue lengths on links and connectors after phase 1For j = 1 until (max. number of iterations in Phase 2) or until any prevQ = 0For each demand segmentFor each route R of the demand segmentCalculate the congestion flow off for R according to M and the

capacitiesand thus obtain currQ

Calculate wait timeprevQ:= currQ

Function QueueOutflow(R, M):arrivedFlow = 0For j = 0 to k-1totalSourceVol := sourceVolQ(Sj) + arrivedFlowpropagatingFlow:= min(totalSourceVol, maxOutflow(Sj, Sj+1))currQ(Sj) := currQ(Sj) - propagatingFlowarrivedFlow := propagatingFlow

Propagate queue backwards

Function PropagateQueue2(R):propagatingQ = 0For j = k-1 to 1If Q(Sj) > K(Sj)propagatingQ := Q(Sj) - K(Sj)Q(Sj) > K(Sj)Q(Sj-1) := Q(Sj-1) + propagatingQ

286 © PTV AG


Please note that the results of the blocking back model may depend on the order of routes thatare processed. (However, the more shares you choose for the distribution of the traffic flow, thesmaller the possible differences will be.) If the blocking back model is applied to the samenetwork for example, on the one hand with an equilibrium assignment and with LUCE on theother 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 notdirectly provide routes, but bushes in the first instance, which represent multiple routes at thesame time. In conjunction with LUCE, the blocking back model calculations are performeddirectly on the bush level. Since the bushes can include various from-links and to-links for eachlink, the traffic flows need to be distributed appropriately. This is performed in a way as ifseveral routes were processed simultaneously. From this, slightly deviating results may be theoutcome.

Determining the wait timesResulting from the second simulation stage are the values for the local queue length of eachlink after each measuring section. These values together with the queue length after the firstsimulation stage are used to form an integral of the overall wait time over the measured queuelength.illustration 84 shows an example for the display of the integral indicating the overall wait timeover the interpolated measured queue lengths.

Illustration 84: Integral indicating the overall wait time over the interpolated measured queue lengths

This is expressed by the following formula.

with I being the length of the first simulation interval in seconds. The sum extends over themeasured values with QS(0) indicating the queue length QS after the first simulation phase.

This results in a mean wait time per vehicle unit as follows

time

Que

ue le

ngth

[Veh

]

simulation interval I I/M I/M ...

Qs(0)= Qs

Qs(1)

Qs(2)

Qs(3)

Qs(4)

Qs(5)

( ) ( )⎟⎟⎠

⎞⎜⎜⎝

⎛ −++∗= ∑

M21iSQiSQ

2SQISW

287 © PTV AG


5.9 Convergence criteria of the assignment qualityTo assess the convergence speed VISUM traces the convergence criteria for each iteration,for all static assignment procedures (apart from incremental assignment). Stochasticassignment only stores the internal iterations of the previous external iteration (see "Stochasticassignment" on page 342).These criteria are output in a list as indicators of the goodness of a PrT assignment (see UserManual, Chpt. 5.7.1, page 932). They are initialized prior to each assignment and stored withthe version file.Among others, the following criteria are calculated:• Hypothetic vehicle impedance

Minimum impedance value calculated hypothetically for the next iteration step on theassumption that all vehicles – based on the current impedances in the network – use thebest path.

• Duality gap = (Veh.Imp.- hypothet. Veh. Imp.) / hypothet. Veh. Imp.Degree of convergence for the network.The value is the weighted volume difference between the vehicle impedance of the networkof the current iteration and the hypothetical vehicle impedance.

• Total Excess Cost TEC (Total Excess Cost)

where

• Average Excess Cost AEC (Average Excess Cost)AEC = Excess cost per vehicle

The following applies:n = Number of trips: Total demand in the demand matrix minus the diagonal, thus the sumof demand contributing to the assignment, no internal traffic.

• Relative Gap RG

tw S,

0 if Vol(S) = 0WSQS------- otherwise

⎩⎪⎨⎪⎧

=

TEC Difference between total impedance in the charged network and the hypothetical impedance resulting if all vehicles took the shortest path per OD pair.

Pij Number of routes from i to j

Rijmin minimum impedance among all routes from i to j

TEC Rr Rijmin–[ ] qr⋅

r Pij∈∑ij∑=

AEC TECn

-----------=

288 © PTV AG

Chapter 5.10: Distribution models in the assignment

The objective function of the equilibrium assignment is:

The lower limit X of the objective function F is calculated as follows: X = F - TEC

5.10 Distribution models in the assignmentIn 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 tothe alternatives. These are the (static) stochastic PrT assignment, the dynamic-stochastic PrTassignment and the timetable-based PuT assignment. PrT assignment procedures usealternative routes from origin zone to destination zone, whereas the PuT assignmentprocedure provides alternative connections (routes with detailed departure times). Forsimplification, we will only mention routes below in this section.A distribution model determines the share of demand which is assigned to a certain route. Thisportion depends on the impedance of a route. In any case, the percentage Pi

a of route i interms of the demand by OD pair in the time interval a is determined by including the impedanceRi

a 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 areavailable. The following approach applies to all models:

1. Impedance Ria s converted to the utility Ui

a of route i in the time interval a.

Uia = f(Ri

a)

2. From this utility Uia the percentage of demand Pi

a is calculated (where n is the total numberof routes).

The models reveal differences in the functional relation f of impedance and utility.

Notes: The Relative Gap determines the difference between the current volume in thenetwork and the equilibrium. It measures the excess cost of vehicles that do not take theoptimum routes yet in proportion to the total impedance in the network.

The calculation of Rijmin is based on the current shortest paths. However, these are only

available after a shortest path search. In the assignment procedures, a statistics calculationfollows the shortest path searches.

F R x( ) xd0

ql

∫l L∈∑=

RG TECX

-----------=

Pia:=

Uia

Uja β–

j 1=

n∑---------------------------

289 © PTV AG


5.10.1 The Kirchhoff model in the assignmentThe utility is as follows:

The percentage of demand is calculated as follows:

The sum of all routes j is taken and β is used as a parameter for modeling the impedancesensitivity. In this distribution method, the ratios of the various impedances are decisive. Itdoes not matter, therefore, whether two routes have impedances of 5 and 10 minutes, forexample, or 50 and 100 minutes – the distribution is the same. illustration 85 shows theparameterization of the Kirchhoff distribution model on the interface.

Illustration 85: Parameterization of the Kirchhoff distribution model

5.10.2 The Logit model in the assignmentIn this model, the difference, rather than the ratio, between the impedances is used tocalculate distribution. The impedance is additionally divided by a scaling divisor.The utility is as follows:

The percentage of demand is as follows:

Parameter β describes the sensitivity of passengers towards increased impedances. As in thiscase the differences rather than the ratios of the impedances are considered, it does not matterwhether two routes have impedances of 5 and 10 minutes, for example, or 95 and 100 minutes.illustration 86 shows the parameterization of the Logit distribution model on the interface.

Uia Ri

a β–

=

Pia:=

Ria β–

Rja β–

j∑------------------

Uia e

β– Ria⋅

=

Pia:= e

β– Ria⋅

eβ– Rj

a⋅

j∑-------------------------

290 © PTV AG


Illustration 86: Parameterization of the Logit distribution model

5.10.3 The Box-Cox model in the assignmentThis distribution model is based on the Box-Cox transformation. For the given τ ≥ 0, the Box-Cox transformation is explained as follows.

When calculating the utility, b(τ)(Ria) is now included in the Logit model instead of Ri

a, thus

results.

The percentage Pia of the route i in terms of the demand for time interval a is then calculated

as follows:

The importance of the Box-Cox model is illustrated by the two special cases below.• τ = 0 (leads to the Kirchhoff distribution)

With these parameter settings, b(0)(Ria) = log(Ri

a) applies, thus the following applies to thechoice:

This is precisely the Kirchhoff model.• τ = 1 (leads to the Logit distribution)

( )( ) ( )⎪⎪⎩

⎪⎪⎨

⎧≠

−

==01

0log:τ

ττ

τ

τifx

ifxxb

Uia e

β– b τ( ) Ria( )⋅ ⋅

=

Pia:= e

β– b τ( ) Ria( )⋅ ⋅

eβ– b τ( ) Rj

a( )⋅ ⋅

j∑--------------------------------------

Pia e

β– Ria( )log⋅

eβ– Rj

a( )log⋅

j∑-----------------------------------

Ria β–

Rja β–

j∑------------------==

291 © PTV AG


With these parameter settings, b(1)(Ria) = (Ri

a-1) applies, thus the following applies to thechoice:

This is identical to the Logit distribution.illustration 87 shows the parameterization of the Box-Cox distribution model on the interface.

Illustration 87: Parameterization of the Box-Cox distribution model

5.10.4 The Lohse model in the assignmentIn this model, the impedances are related to each other in an entirely different way.

applies.

Here, Rmina := minjRj

a is the smallest occurring impedance, and β is again a parameter tocontrol the impedance sensitivity. When calibrating, do not forget that β is squared.In this case, the impedance of a route is related to the minimum impedance, which thereforemeasures the relative difference from the optimum. Due to this different approach, the Lohsemodel can be used as an alternative to Kirchhoff and Logit. It should be noted, that the Lohsedistribution formula cannot be regarded as a special form of Box-Cox transformation.illustration 88 shows the parameterization of the Lohse distribution model on the interface.

Pia e

β– Ria 1–( )⋅

eβ– Rj

a 1–( )⋅

j∑----------------------------------- e

β– Ria⋅

eβ– Rj

a⋅

j∑-------------------------==

Pia := e

βRi

a

Rmina

---------- 1–⎝ ⎠⎜ ⎟⎛ ⎞

⋅2

–

eβ

Rja

Rmina

---------- 1–⎝ ⎠⎜ ⎟⎛ ⎞

⋅2

–

j∑

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

292 © PTV AG


Illustration 88: Parameterization of the Lohse distribution model

5.10.5 Lohse model with variable beta in the assignmentThe model is described in Schnabel and Lohse (1997) and differs from the Lohse model in thatthe distribution parameter β is determined depending on the value of the minimum impedanceRmin

a . The calculation can be calibrated in more detail when using three additional parametersτ, λ and κ. The following approach applies:

The following therefore applies:

β is calculated according to the following formula:

The impedance is additionally divided by a scaling divisor.The variable distribution parameter β improves the modeling of the impedance sensitivity.Identical ratios of impedances are considered differently for short routes compared to longroutes. In the case of two routes with impedances of 5 and 10 minutes or 50 and 100 minutes,the distribution is not the same.The following example illustrates the effect of the distribution model Lohse with variable beta.illustration 89 compares different best paths (10 min, 50 min, 150 min, 300 min) with "detour"alternatives. The distribution to the routes is done on the basis of the sumptuary ratio and theabsolute value of the best path.For shorter best paths and their alternatives lower detour sensitivity is assumed than for longerbest paths.

Uia e

βRi

a

Rmina

---------- 1–⎝ ⎠⎜ ⎟⎛ ⎞

⋅2

–

=

Pia := e

βRi

a

Rmina

---------- 1–⎝ ⎠⎜ ⎟⎛ ⎞

⋅2

–

eβ

Rja

Rmina

---------- 1–⎝ ⎠⎜ ⎟⎛ ⎞

⋅2

–

j∑

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

β τ

1 eλ κ Rmin

a⋅–( )+

-------------------------------------=

293 © PTV AG


Illustration 89: Distribution with variable beta according to the modified Kirchhoff rule (please refer to Schnabel / Lohse)

The parameters in illustration 89 are described in Table 95.

illustration 90 shows the parameterization of the Lohse distribution model with variable beta onthe interface.

Illustration 90: Parameterization of the Lohse distribution model with variable Beta

τ λ κ Rmina β

10 0.800 0.010 10 min 3.32

10 0.800 0.010 50 min 4.26

10 0.800 0.010 150 min 6.68

10 0.800 0.010 300 min 9.00

Table 95: Parameters for the distribution with variable beta in illustration 89

294 © PTV AG


5.10.6 Comparison of the distribution models for the assignmentThe effects of the four distribution models (Kirchhoff, Logit, Box-Cox and Lohse) are illustratedin a simple example. Table 96 to Table 98 show three simple cases of a choice between twoalternatives which represent either routes or connections. The model parameters used can befound in Table 99.• Example 1

Alternative 1 has an impedance of 5, alternative 2 an impedance of 10. Thus alternative 2has a 5-unit higher impedance or a double impedance compared to alternative 1.

• Example 2The impedance of example 1 is increased by 100 units, so that alternative 1 now has animpedance of 105 and alternative 2 an impedance of 110. This means that alternative 2thus has a 5-unit higher impedance, as in example 1; however, the impedance ratio is now0.95 rather than 0.5.

• Example 3The impedance of example 1 is doubled, so that alternative 1 now has an impedance of 50and alternative 2 an impedance of 100. This now means that alternative 2 has a 50-unithigher impedance; the impedance ratio is 0.5 as in example 1.

The distribution results demonstrate that in the Logit model the difference of impedances isdecisive, 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 samedistribution values for examples 1 and 3. The Box-Cox model allows a combination of Logitand Kirchhoff, which is also illustrated by the distribution values.It would seem that the Logit model cannot be recommended for practical use, because thebasis for a passenger’s choice is different for short and long connections. In practice, it willcertainly make a difference whether a passenger has to travel 5 and 10 minutes (Table 96), or105 and 110 minutes (Table 97). In the case of long journeys, the additional 5 minutes are notas important as in case of short trips. The weaknesses of the Kirchhoff model in the examplein Table 98, where one can expect all passengers to chose alternative 1, are not relevant forthe assignment, because connections that differ to such an extent would not be found in thesearch at all and would therefore not be real alternatives for the road-user.

No. R Kirchhoff Logit Box-Cox Lohse

1 5 94 % 78 % 86 % 100 %

2 10 6 % 22 % 14 % 0 %

Table 96: Distribution to two alternatives with the impedances 5 and 10


1 105 55 % 78 % 62 % 51 %

2 110 45 % 22 % 38 % 49 %

Table 97: Distribution for two alternatives with impedance 105 and 110

295 © PTV AG


5.11 Incremental assignmentThe incremental assignment procedure models how a network continuously fills up. At thebeginning, road users can use a free network for which exactly one shortest route exists forevery origin/destination relation. The traffic network is then successively loaded. Every stepcongests the road network with additional vehicles and, in this way, increases impedance onthe congested links, turns and connectors. Because of the changed impedance, alternativeshortest 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 theuser (maximum 12). The default is an incremental assignment with three iteration steps (33 %,33 % and 34 %).• The first step determines lowest impedance routes for all required OD-relations of the

current network for either a free network or based on a basic volume.• The defined percentage of the first incremental step of the matrix is then assigned to these

routes.• Subsequently, the new network impedances resulting from these volumes are calculated

via the VD functions. • On this basis, the next iteration step again calculates lowest impedance routes.• This procedure is continued until the entire matrix has been assigned to the network. If 100% is entered for the first iteration step, VISUM calculates the impedances of the currentnetwork and carries out a so-called best-route assignment.

5.11.1 Example of the incremental assignmentTable 100 shows how the incremental procedure works on the example network (see"Example network for the PrT assignment procedures" on page 197). The 2000 car trips areassigned 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 isloaded with 50 % of car trips, that is, with 1,000 car trips.


1 50 94 % 100 % 100 % 100 %

2 100 6 % 0 % 0 % 0 %

Table 98: Distribution for two alternatives with impedance 50 and 100

Kirchhoff β = 4

Logit β = 0.25

Box-Cox β = 1, τ= 0.5

Lohse β = 4

Table 99: Model parameters

296 © PTV AG

Chapter 5.11: Incremental assignment

• Iteration step 2The shortest route after the first iteration step is route 1 with an impedance of 20:50 min.Itis loaded with 25 % of car trips, that is, with 500 car trips.

• Iteration step 3After the second iteration step route 1 remains the shortest route with an impedance of29:50 min. It is again loaded with 25 % of car trips, that is, with 500 car trips, and now has1,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 ofthe route. Additional impedances for connectors and turns are not considered. In addition tothis, it is assumed that impedance results from current travel time tCur, and that current traveltime in turn results from the BPR function with a=1, b=2 and c=1.

LinkNo Type Length [m] v0 [km/h] Capacity t0 [min]

1 20 5000 100 1200 03:00

2 20 5000 100 1200 03:00

3 20 5000 100 1200 03:00

5 20 5000 100 1200 03:00

6 20 5000 100 1200 03:00

7 20 5000 100 1200 03:00

8 30 16000 80 800 12:00

9 30 5000 80 800 03:45

10 40 10000 60 500 10:00

11 40 5000 60 500 05:00

Route Links of the route Length [m] t0 [min]

1 1+8+9 26000 18:45

2 1+2+3+5+6+7 30000 18:00

3 10+11+5+6+7 30000 24:00

LinkNo Volume tCur Volume tCur Volume tCur

Step 1 (50%) Step 2 (25%) Step 3 (25%)

1 1000 05:05 1500 07:41 2000 11:20

2 1000 05:05 1000 05:05 1000 05:05

3 1000 05:05 1000 05:05 1000 05:05

5 1000 05:05 1000 05:05 1000 05:05

6 1000 05:05 1000 05:05 1000 05:05

7 1000 05:05 1000 05:05 1000 05:05

297 © PTV AG


5.11.2 Procedure of the incremental assignmentillustration 91 shows the procedure of an incremental assignment.

8 0 12:00 500 16:41 1000 30:45

9 0 03:45 500 05:13 1000 09:37

10 0 10:00 0 10:00 0 10:00

11 0 05:00 0 05:00 0 05:00

Route Volume tCur Volume tCur Volume tCur

Step 1 (50%) Step 2 (25%) Step 3 (25%)

1 0 20:50 500 29:35 1000 51:42

2 1000 30:30 1000 33:06 1000 36:45

3 0 30:15 0 30:15 0 30:15

Table 100: Example of the incremental assignment (BPR function a=1, b=2, R=tCur)

LinkNo Volume tCur Volume tCur Volume tCur

298 © PTV AG

Chapter 5.11: Incremental assignment

Illustration 91: Procedure of the incremental assignment

5.11.3 Input and output attributes of the incremental assignmentTo execute the incremental assignment, certain entries have to be made. After calculation, theresults are available in the output attributes and can be displayed in the list view (see UserManual, Chpt. 12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2,page 1253) . Table 101 gives an overview of which input attributes have to be maintained.Table 102 lists the output attributes which store the results of the procedure.

Demand matrix FNumber of iteration steps NDemand proportion Pn for each iteration step n = 1, N

Input

n = 0Volume q0 = 0 or basic volume

Determination of impedance Rn of all network objects withthe corresponding impedance function.

Determination of the best route for all relations based on impedance Rn.

Assignment of travel demand which results from Pn ontonetwork objects which are part of the best route.qn+1 = qn + Pn • F

Determination of impedance Rn of all network objects withthe corresponding impedance function.

n = n +1

n = N ?

Impedance determination

Route search

Query

End

yes

no

Volume

299 © PTV AG


Table 101: Input attributes for the incremental assignment

The abbreviations have the following meanings:

x1 The toll by PrTSys has to be inserted manually in the impedance function(X) Can be used optionally(*) Apart from the parameters which are directly set in the assignment procedure

300 © PTV AG

Chapter 5.12: Equilibrium assignment

Table 102: Output attributes of the incremental assignment

5.11.4 Evaluation of the incremental assignmentLohse (1997) lists the following decisive disadvantages of the incremental assignmentprocedure.• The number and the size of layers (partial matrices) mainly decide on the goodness of the

results. However, there is no procedure to specify optimal layers.• The calculation ends after the specified number of steps has been executed without

checking correspondence between the resulting traffic volume and link impedances.

5.12 Equilibrium assignmentThe 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 routesis the same, and that switching to a different route would increase personal travel time (useroptimum)."This behavioral hypothesis underlies the unrealistic assumption that every road user is fullyinformed about the network state. In transport planning this hypothesis is approved of given a

301 © PTV AG


fundamental methodical advantage of the equilibrium assignment - with quite generalrequirements, the existence and uniqueness of the assignment result (expressed in volumesof the network object) is guaranteed. Moreover, measures for the distance of an approximationsolution from the equilibrium exist, from which an objective termination criterion can be derivedfor the procedure, which generally is an iterative problem solution.The equilibrium assignment determines a user optimum which differs from a system optimum,as shown in Table 103 and Table 104.• A user optimum means that the same impedance results for all routes of a traffic relation

between zones i and j (within the scope of calculation accuracy). This results directly fromthe condition, that changing to another route is not profitable for any road user (Table 103).

• A system optimum however means that the total impedance in the network, which is theproduct 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 userswhich use routes to serve the general public, with an impedance above average(Table 104).

5.12.1 Evaluation of the equilibrium assignment• Because the procedure only terminates when all routes of any OD pair are in the balanced

state, the procedure provides more realistic results than the incremental procedure.• For a lower volume/capacity ratio, a similar result is achieved as with best-route

assignment, because the route search does not find new routes. In this case it isrecommended to use an incremental assignment with suitable parameters as initial solutionor 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 astrongly saturated network, more computation time is required in this case.

• Compared to stochastic assignment procedures (see "Stochastic assignment" on page 342and "Dynamic stochastic assignment" on page 396) the equilibrium assignment provides

Route Links Volume tCur [min] Volume • tCur

1 1+8+9 736 38:19 470:05:53

2 1+2+3+5+6+7 995 38:21 636:01:21

3 10+11+5+6+7 269 38:20 171:50:02

Total 2000 1277:57:17

Table 103: Calculation of the user optimum for the example network

Route Links Volume tCur [min] Volume • tCur

1 1+8+9 734 37:43 461:46:27

2 1+2+3+5+6+7 919 37:13 569:58:45

3 10+11+5+6+7 347 41:13 238:11:24

Total 2000 1269:56:36

Table 104: Calculation of the system optimum for the example network

302 © PTV AG


distinct network volumes. Convergence parameter such as Duality Gap or Relative Gap aremore objective termination criteria than for example the number of calculated iterations.

5.12.2 Introductive example for the equilibrium assignmentThe effectiveness of the equilibrium assignment is described as follows on the basis of theexample described in Table 105 and illustration 92. The example analyzes the relationbetween 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 ofthe route (see "Impact models" on page 189). Impedances for connectors and turns are notconsidered 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=2and c=1.

• The access and egress times for the connectors are not considered, that is, they are set to0 minutes.

• Turn penalties are not considered.With regard to the traffic demand the following applies.• Traffic demand between village A and city X consists of 2000 car trips during the peak hour.• Capacity and demand refer to one hour.The example network contains three routes which connect village A and city X.• Route 1 via nodes 10 – 11 – 41 – 40• Route 2 via nodes 10 – 11 – 20 – 21 – 30 – 31 – 40• Route 3 via nodes 10 – 12 – 21 – 30 – 31 – 40Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 kmlong. It is the fastest route because the federal road can be traversed at a speed of 100 km/hif there is free traffic flow. Route 3 which is also 30 km long is an alternative route which only makes sense if the federalroad is congested.

303 © PTV AG


Illustration 92: Example network for the equilibrium assignment

As a result, the assignment provides values from Table 106 for the three routes (PrT paths).

LinkNo

From Node


1 10 11 20 Federal road 5000 1200 100

2 11 20 20 Federal road 5000 1200 100

3 20 21 20 Federal road 5000 1200 100

4 20 40 90 Rail track 10000 0 0

5 21 30 20 Federal road 5000 1200 100

6 30 31 20 Federal road 5000 1200 100

7 31 40 20 Federal road 5000 1200 100

8 11 41 30 Country road 16000 800 80

9 40 41 30 Country road 5000 800 80

10 10 12 40 Other roads 10000 500 60

11 12 21 40 Other roads 5000 500 60

Table 105: Example network for the equilibrium assignment

Route tCur Impedance Volume(AP)

1 46min 39s 2798 1157.488

2 46min 34s 2794 618.079

3 46min 12s 2772 224.432

Table 106: Assignment results for the three PrT paths

11

21

20

10

12

41

40

3130

village A

city X

1

2 9

6 5

8

11

7 3

10

304 © PTV AG


The most important assignment results for the links are displayed in Table 107.

5.12.3 Input and output attributes of the equilibrium assignmentTo execute the equilibrium assignment, certain entries have to be made. After calculation, theresults are available in the output attributes and can be displayed in the list view (see UserManual, Chpt. 12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2,page 1253) . The Table 108 gives an overview of which input attributes have to be maintained.Table 109 lists the output attributes which store the results of the procedure.

Link

tCur Impedance Volume(AP) Saturation PrT (AP)

VehicleHr(tCur) VehKmTravelled PrT

1 11min 40s 700 1908 170 370h 54min 19s 9537.839

2 5min 47s 347 1157 96 111h 43min 15s 5787.442

3 5min 47s 347 1157 96 111h 43min 15s 5787.442

5 7min 48s 468 1450 126 188h 29min 38s 7249.603

6 7min 48s 468 1450 126 188h 29min 38s 7249.603

7 7min 48s 468 1450 126 188h 29min 38s 7249.603

8 26min 35s 1595 750 110 332h 23min 38s 12001.270

9 8min 19s 499 750 110 103h 52min 23s 3750.397

10 15min 12s 912 292 72 74h 3min 56s 2924.321

11 7min 36s 456 292 72 37h 1min 58s 1462.161

Table 107: Assignment result at the links

305 © PTV AG


Table 108: Input attributes of the equilibrium assignment


x1 Toll PrTSys has to be inserted manually in the impedance function0 Generally possible, however not recommended(*) Apart from the parameters which are directly set in the assignment procedure

306 © PTV AG


Table 109: Output attributes of the equilibrium assignment

If you use metric units, enter the long lengths for kilometers and speeds in km/h. For imperialunits enter the long lengths in miles and speeds in mph.

5.12.4 Procedure of the equilibrium assignmentThe equilibrium state calculation can be formulated as an optimization problem with a convexobjective function and linear secondary conditions.

The following applies.

E the set of all edges in a network and a one of these edges

min! Ra x( ) xd0

qa

∫a E∈∑

qijr 0 ijr∀,>

qijrr∑ qij= ij∀,

qijrijr:a Pijr∈∑ qa= a∀,

qa qaa Eu-∈∑–

a Eu+∈∑ qiu qujj∑–

i∑ Du Ou–= = u∀,

307 © PTV AG


In VISUM, edges are all links, turns and connectors, whereas nodes are zones and networknodes.The objective function shows that the sum of impedances of all edges is minimized. Thesecondary 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 outgoingedges have to correspond exactly with the difference between the destination and origintraffic. There is no origin and destination traffic at network nodes, thus the difference mustbe zero.

Due to the non-linear objective function, the optimization problem is not solved directly butiteratively. Because of the monotonicity of the impedance function, the minimum is reached, sothat starting with a starting solution between the alternative paths, a movement i-j is shifted, sothat the paths all have the same impedance.During the equilibrium assignment the steps showed in illustration 93 will be made.

qa volume of object a

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

E-u

the set of the outgoing edges at node u

Du destination traffic at node u

Ou origin traffic at node u

308 © PTV AG


Illustration 93: Procedure of the equilibrium assignment

Based on an assignment result from a previously calculated assignment or an incrementalassignment (by default) as a starting solution, the state of balance is reached by multiple stepiteration. In the inner iteration step, two routes of a relation are brought into a state ofequilibrium by shifting vehicles. These iteration steps are carried out for all relations until allrelations are in a state of balance. Every shift of vehicles from one route to another has animmediate 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 ofthe current network state. If this is the case for at least one relation, another state of balancemust be calculated. The following termination condition applies. A state of balance has been reached if the inneriteration step did not need to shift vehicles, and no new routes were later found by the externaliteration step.Also the convergence criterion relative gap can be used as termination condition (see UserManual, Chpt. 5.6.2.2, page 891).

Loaded network (starting solution) with loaded routes rMaximum number of iteration steps NMaximum absolute deviation of impedance EabsMaximum relative deviation of impedance Erel

Input

n = 0

Balance the volumes of all routes r for all OD pairs ij so that the impedance Rrij of the routes is:

| min. Rij – max. Rij |< Eabs ormax. Rij / min. Rij < 1 + Erel

Determination of the best routes for all relations i-j basedon impedance R(n).

End

n = n +1

New routes found andn < N and

relative gap > max. permitted relative gap?

Network balancing

Route search

Query

yes

no

309 © PTV AG


Network balancingThe procedure of the network balancing is displayed in illustration 94.

Illustration 94: Procedure of the network balancing for an OD pair in the equilibrium assignment

Termination criterionVISUM cancels the iteration process for calculating the equilibrium, if one of the followingconditions has been fulfilled:• Network balancing has been achieved, this means a permitted deviation of impedances of

the routes compared in pairs was reached or undercut.• The specified number of external iterations was reached without a network balancing being

reached (in very highly loaded networks it is possible that the permitted deviations whichwere specified do not result in a state of balance because only integer vehicles are shifted).

• The convergence criterion max. relative gap is reached or undercut.

Volume qr of each route r,Impedance Rr of each route r,Maximum absolute deviation of impedance EabsMaximum relative deviation of impedance Er el

Input

Select two routes:Route r1: Route with minimal impedance R1Route r2: Route with maximum impedance R2

Update impedance of all network objects whose volume has changed.

Network balancing completed

Is the following condition fulfilled for the route with theminimum impedance R1, and the route with the maximumimpedance R2?

| R1 – R2 | < Eabs orR2 / R1 < 1 + Er el

Update impedance

Pair balancing

Query

End

yes

no

Route search

Balance the volume of routes r1 and r2 in such a way thatthe impedance of the routes is:

| R1 – R2 |< Eabs or1 – Er el < R1 / R2 < 1 + Er el

I f the volume of route r1 or r2 is 0 after balancing, deleteroute.

310 © PTV AG


• In case of an equilibrium assignment with blocking back model the maximum deviation wasreached or undercut (see "Blocking back model" on page 273). The procedure is cancelledif the congestion volume values and the congestion wait times of two external iterationsdeviate by the max. rel. difference or less.

5.12.5 Calculation example for the equilibrium assignment

Route Volume tCur [min]

Starting solution 1 1000 51:42

Routes 1 + 2 are known 2 1000 36:45

3 0 30:15

Network balancing 0 1 776 41:54

Routes 1 + 2 2 1224 41:56

3 0 33:22

1. Iteration step: route search finds route 3


Routes 1 + 3 2 1224 42:58

3 127 36:23

Max. imp. route = 2, Min. imp. route = 3


Routes 2 + 3 2 1067 40:17

3 284 40:15



Routes 1 + 2 2 982 38:10

3 277 38:51



Routes 1 + 3 2 982 38:07

3 277 38:31



Routes 2 + 3 2 990 38:14

3 269 38:15



Routes 1 + 2 2 995 38:21

3 269 38:20

Table 110: Example equilibrium procedure (BPR function a=1, b=2)

311 © PTV AG


Table 110 shows how the equilibrium procedure works on the example network (see "Examplenetwork for the PrT assignment procedures" on page 197). The volume determined with theincremental procedure is used here as the initial solution (see "Example of the incrementalassignment" on page 296). This starting solution encompasses two routes, each loaded with1,000 car trips. The specified absolute deviation is a value of five impedance units, and therelative deviation is specified as being 0.1 %. Based on the starting solution, the followingsteps 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 tworoute impedances is below the specified deviation. This is guaranteed with a volume of 776and 1224 vehicles for route 1 and route 2.

• Route search for iteration step 1After network balancing of routes 1 and 2, the shortest path search of the first iteration stepdetermines route 3.

• Network balancing for iteration step 1The three routes are balanced in pairs until the impedance of all routes accords with thespecified 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 LUCEprocedure. The main idea is to seek at each node a user equilibrium for the local route choiceof drivers directed toward the destination among the arcs of its forward star. The travelalternatives that make up the local choice sets are the arcs that belong to the current bush. Abush is an acyclic sub-graph that connects each origin to the destination at hand. The costfunctions associated to these alternatives express the average impendence to reach thedestination linearized at the current flow pattern.The unique solutions to such local linear equilibria in terms of destination flows, recursivelyapplied for each node of the bush in topological order, provide a descent direction with respectto the classical sum-integral objective function. The network loading is then performed throughsuch splitting rates, thus avoiding explicit path enumeration.

312 © PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

5.13.1 Mathematical formulation and theoretical frameworkThe transport network is represented through a directed graph G = (N, A), where N is the set ofthe nodes and A ⊆ N×N is the set of the arcs. In the graph, the nodes represent the zonecentroids and the road intersections (VISUM network nodes), while the arcs represent the linksand the connectors. When turns with impendence or restrictions are introduced in the networkmodel, then the node is properly exploded, so that such turns are associated to specific or noarcs of the graph.We adopt the following notation:

There are two fundamental relations between flow variables. The flow on arc ij∈A is the sumof the flows on the paths that include it:

fij = ∑k∈K δijk • Fk

The travel demand between origin o∈Z and destination δÎZ must be equal to the sum of theflows on the paths that connect them:∑k∈Kod 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 agiven path k is the sum of the costs on the arcs that belong to it:

Ck = ∑ij∈A δijk • cij (6)

By definition, the minimum cost to reach destination d∈Z from node i∈N is the cost of anyshortest path that connects them:

Imp = min{Ck : k∈Kid} (7)

fij Total flow on arc ij∈A, generic element of the (|A|×1) vector f

cij Cost of arc ij∈A, generic element of the (|A|×1) vector c

cij( fij) Cost function of arc ij∈A

Z ⊆ N Set of the zone centroids

Dod Demand flow between origin o∈Z and destination d∈Z, generic element of the (|Z|2×1) vector D, that is the demand matrix in row major order

Kid Set of the acyclic paths between node i∈N and destination d∈Z

C K = ∪o∈Z ∪d∈Z Kod is the set of paths available to road users

δijk δij

k = 1, if arc ιϕÎA belongs to path k, and 0, otherwise – for κÎK, this is the generic element of the (|A|´|K|) matrix Δ

λodk λod

k is 1, if path k∈K connects origin o∈Z to destination d∈Z (i.e. k∈Kod), and 0, otherwise –

this is the generic element of the (|Z|2×|K|) matrix ΛFk Flow on path k∈K, generic element of the (|K|×1) vector F

Ck The cost of path k – for k∈K this is the generic element of the (|K|×1) vector C

Wid Minimum cost to reach destination d∈Z from node i∈N

ℜ Set of real numbers

|S| Cardinality of the generic set S

313 © PTV AG


In this case, the traffic assignment problem can be formalized through the following program:

(8)

where

To ensure the existence and uniqueness of the solution to problem (8) we assume that: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:

(9)

where, although the solution uniqueness does not hold anymore, the convexity of themathematical program is preserved, implying that any descent algorithm in the space of pathflows will provide one of the global solutions, which then make up a convex set.The relevance of program (9) to traffic assignment stands from the fact that, in the case ofadditive path costs, its first order (necessary) conditions coincide with the following formulationof the deterministic user equilibrium based on Wardrop's Principles, for each o∈Z and δÎZ:

Fk • (Ck - Wod) = 0, ∀k∈Kod (10.1)

Ck ≥ Wod, ∀k∈Kod (10.2)

Fk ≥ 0, ∀k∈Kod (10.3)∑k∈Kod 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, whileconsidering that each path cost Ck is a function (potentially) of all the path flows F through thearc cost function:

Ck = ∑ij∈A δijk • cij(∑k∈K δij

k • Fk), in compact form C = DT • c(D•F)

Since the gradient of Φ(F) is C = ΔT• c(Δ•F), by linearizing the objective function of problem (9)at a given a point F∈Ω, for X → F we obtain:

Θ {f∈ℜ|A|: f = Δ•F, F∈Ω} is the set of feasible arc flowsΗ {F∈ℜ|K|: F ≥ 0, Λ•F = D} is the set of feasible path flows

min ω(f) cij x( ) x: f Θ∈d0

fij

∫ij A∈∑=

⎩ ⎭⎪ ⎪⎨ ⎬⎪ ⎪⎧ ⎫

min Φ(F) cij x( ) x: F Θ∈df 0=

δijk Fk⋅

k K∈∑∫ij A∈∑=

⎩ ⎭⎪ ⎪⎨ ⎬⎪ ⎪⎧ ⎫

314 © PTV AG


Φ(X) = F(F) + CT•(X-F) + o(||X-F||). (11)From equation (11) we recognize that a direction E-F is descent if and only if:

CT•(E-F) < 0. (12)In other words, to decrease the objective function and maintain feasibility we necessarily haveto shift path flows getting a lower total cost with respect to the current cost pattern, i. e. movethe current solution from F towards an E∈Ω such that CT•E < CT•F, where C = ΔT•c(Δ•F). Thenecessity derives from the convexity of the problem, since in this case at any point X such thatCT•(X-F) > 0 we have: Φ(X) > Φ(F).This approach to determine a descent direction can be applied to each OD pair separately, toeach destination, or to the whole network jointly. Based on the above general rule, setting theflow pattern E by means of an all-or-nothing assignment to shortest paths clearly provides adescent direction. If we adopt such a direction for all OD pairs of the network jointly, and applyalong it a line search, we obtain the well known Frank-Wolfe algorithm. However, at equilibriumeach OD pair typically uses several paths, implying that any descent direction that loads asingle 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 currentsolution along the segment F+α•(E-F) and take a step α∈(0,1] such that the objective functionof 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 todetermine an α which minimizes φ(α). VISUM uses an Armijo-like search and determines thelargest step α = 0.5k, for any non-negative integer k, such that

∂φ(0.5k)/∂α < 0. (13)This method requires to compute the directional derivative of the objective function:

∂φ(α)/∂α = [c(Δ•(F+α•(E-F)))]T•[Δ•(E-F)] , (14)which implies to evaluate the arc costs at the candidate flows F+α•(E-F) and then thedifference between the corresponding total costs obtained with the flows E and F. if such totalcosts with E are smaller than those with F, then ∂φ(α)/α is negative so that the optimal solutionis more toward E, and vice versa.

5.13.2 Local user equilibriumIn this section we present a new method to determine a descent direction, which is based onlocal shifts of flows that satisfy the total cost lowering rule and exploits the inexpensiveinformation 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 ODpair 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 95), so that an all ornothing approach would lead to a descent direction (D, 0), which is far away from theequilibrium f* (gray circle in the Figure). The LUCE approach, instead, is to consider the firstorder 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): thisdescent direction efficiently approaches the equilibrium f*. In most cases α=1 can be taken asthe new iterate with a step one.

315 © PTV AG


Illustration 95: Linear User Cost Equilibrium between two paths

To reach any destination d∈Z, at the equilibrium only shortest paths are utilized. Given that thearc cost functions are strictly monotone increasing, they make up an acyclic [*1] sub-graph ofG, i.e. a (reverse) bush rooted at d. At strict monotonicity, any arc cost can be null only if its flowis such. However, in VISUM links and connectors may have null impedance, producing twofoldconsequences: a) the corresponding arc cost functions loose strict monotonicity, so thatuniqueness is not guaranteed anymore. b) he sub-graph made-up by arcs with positivedestination flows at some of the possible equilibria may be cyclic. The implementation of LUCEin VISUM specifically addresses this issue and converges to one among the possible equilibriaby forcing an acyclic solution and equally splitting the flow among all alternatives with minimumcost 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 thecurrent bush B(d) and introduce an updating mechanism to make sure that eventually anyshortest path will be included into it; equilibrium is actually only attained this way. Let us focuson the local route choice at a generic node i∈N for road users directed to destination d∈Z.For the topology of the bush we will use the following notation:

For the flow pattern we will use the following notation:

FSB(i, d) = {j∈N: ij∈B(d)} the forward star of node i∈N made-up by nodes that can be reached from it through arcs belonging to the current bush B(d) of destination d∈Z

BSB(i, d) = {j∈N: ij∈B(d)} the backward star of node i∈N made-up by nodes that can reach it through arcs belonging to the current bush B(d) of destination d∈Z

fijd current flow on arc ij∈A directed to destination d∈ZBy construction it is fijd = 0 for each j∉FSB(i, d);

moreover it clearly is: fij = ∑d∈Z fijd

fid = ∑j∈FSB(i, d) fijd current flow leaving node i∈N to destination d∈Z

yijd yij

d = fijd / fid current flow proportion on arc ij∈A directed to destination d∈Z, if

fid > 0, yijd = 0 else

eijd descent direction, in terms of flow on arc ij∈A directed to destination d∈Z

316 © PTV AG


For the cost pattern we will use the following notation:

The average cost Cid is the expected impendence that a user encounters by travelling from

node i∈N to destination d∈N. Here it is defined recursively based on the current flow pattern:

if fid > 0 , then Cid = ∑j∈FSB(i, d) yijd • (

cij + Cjd), else (15.1)

Cid = min{cij + Cj

d: j∈FSB(i, d)}, (15.2)

as if drivers utilize paths accordingly with the current flow proportions. In the following weassume that the cost function cij( fij) is continuously differentiable for each arc ιϕÎA:

gij = ∂cij(fij) / ∂fij (16)

Under the assumption that an infinitesimal increment of flow leaving node i∈N directed towardsdestination d∈Z would diverge accordingly with the current flow proportions, we have:

if fid > 0, then Gid = ∂Ci

d / ∂fid = ∑j∈FSB(i, d) yijd 2 • (gij + Gj

d), else (17.1)

Gid = ∑j∈FSB(i, d) [Ci

d = cij + Cjd] • (gij + Gj

d) / ∑j∈FSB(i, d) [Cid = cij + Cj

d], (17.2)

where the derivatives gij + Gjd are scaled by the share yij

d of ∂fid utilizing arc ij and thenpassing through node j, that jointly with the flow proportion involved in the averaging yields thesquare yijd 2.

The average costs and their derivatives can be computed by processing the nodes of the bushin reverse topological order according to d, starting from Cd

d = Gdd = 0.

We now address the local user equilibrium for the eid drivers directed to destination d∈Z, whose

available alternatives are the arcs of the bush exiting from node i∈N. To each travel alternativewe associate the cost function:

vijd(eij

d) = (cij + Cjd) + (gij + Gj

d) • (eijd - yij

d • eid), (18)

resulting from a linearization at the current flow pattern of the average cost encountered by auser choosing the generic arc ij, with j∈FSB(i, d).This problem can be formulated, in analogy to (10.1) to (10.4), by the following system ofinequalities:

eijd • [vij

d(eijd) - Vi

d] = 0, ∀j∈FSB(i, d), (19.1)

vijd(eij

d) ≥ Vid, ∀j∈FSB(i, d), (19.2)

eijd ≥ 0, ∀j∈FSB(i, d), (19.3)

eid descent direction, in terms of flow leaving node i∈N directed to destination d∈Z

eijd = eij

d / eid descent direction, in terms of flow proportion on arc ij∈A directed to destination

d∈Z

Cid average cost to reach destination d∈Z from node i∈N

gij Cost derivative of arc ij∈A

Gid Derivative of the average cost to reach destination d∈Z from node i∈N.

317 © PTV AG


∑j∈FSB(i, d) eijd = ei

d, (19.4)

where we denote:

If eid = 0, the solution to the above problem is trivially: eij

d = 0, for each j∈FSB(i, d). Consider

then the case where eid > 0. To improve readability, problem (19.1) to (19.4) can be rewritten

as:xj • (aj + bj • xj - v) = 0, ∀j∈J, (20.1)aj + bj • xj ≥ v, ∀j∈J, (20.2)xj ≥ 0, ∀j∈J, (20.3)∑j xj = 1, (20.4)

where:

Applying the usual Beckmann approach we can reformulate the equilibrium problem (20.1) to(20.4) as the following quadratic program:

min{∑j∈J 0∫ xj(aj + bj • x) • dx: x∈X} = min{∑j∈J aj • xj + 0.5 • bj • xj2: x∈X} , (21)

where X is the convex set of all vectors satisfying the feasibility conditions (20.3) and (20.4).The gradient of the objective function is a vector with generic entry aj + bj • xj, and then theHessian of the objective function is a diagonal matrix with generic entry bj. Therefore, if allentries bj are strictly positive, the Hessian is positive definite and problem (21) has a uniquesolution. In order to ensure such a desirable property we assume without loss of generality thatthe derivates gij are strictly positive for all arcs ij∈A. 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 (20.1) to (20.4) we propose the following simple method. In order to satisfycondition (20.1), either it is xj = 0, and in this case condition (20.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 = { j∈J: xj = 0}. For anygiven J0 the solution is immediate, since from (20.4) it is ∑j∈J (v - aj) / bj = 1; therefore we have:

v = (1 + ∑j∈J\J0 aj / bj) / (∑j∈J\J0 1 / bj) , (22.1)xj = (v - aj) / bj , ∀j∈J\J0 , (22.2)xj = 0 , ∀j∈J0 . (22.3)

Vid local equilibrium cost to reach destination d∈Z from node i∈N;

vijd Cost of the local alternative j∈FSB(i, d) to reach destination d∈Z from node i∈N via j.

J {(i, j, d): j∈FSB(i, d)}aj (cij + Cj

d) - (gij + Gjd) • ei

d • yijd

bj (gij + Gjd) • ei

d

xj eijd / ei

d

V Vid

318 © PTV AG


The flow proportions provided by (22.1) to (22.3) implicitly satisfy (20.4). But to state that thechosen J0 yields the solution of problem (20.1) to (20.4), we still must ensure the followingconditions: aj < v, for each j∈J\J0 (as required by (20.3), since xj = (v - aj) / bj > 0), and aj ≥ v, foreach j∈J0 (as required by (20.2), since xj = 0). This implies that at the solution the value of vresulting from (22.1) must partition the set J into two sub-sets: the set J0, made up by thealternatives j such that aj ≥ v; and its complement J\J0, made up by the alternatives j such thataj < v.

At a first glance the problem to determine the set J0 of alternatives with zero flow may seem tobe combinatorial. However, this is not the case. The equation (22.1) can be rewritten as arecursive formula. It then shows the effect of removing an alternative k from the set J0:

v[J0\{k}] = (v[J0] • ∑j∈J\J0 1 / bj + ak / bk) / (∑j∈J\J0 1 / bj + 1 / bk) . (23)

The right hand side of (23) can be interpreted as an average between v[J0] and ak with thepositive weights ∑j∈J\J0 1 / bj and 1 / bk . Therefore, the local equilibrium cost increases byremoving from J0 any alternative k∈J\J0, for which ak is higher than the current value v[J0]. Viceversa it decreases by adding such alternatives to J0. Consequently, the correct partition set J0can be simply obtained by adding iteratively to an initially empty set each alternative j∈J\J0such that aj > v, i.e. each alternative for which (22.2) yields a negative flow proportion.

5.13.3 Descent directionTo obtain a complete pattern of arc flows ed for a given destination d∈Z consistent with the localuser equilibrium we simply have to solve problem (19.1) to (19.4) at each node iÎΝ∴{d}proceeding in topological order, where the node flow is computed as follows:

eid = ∑j∈BSB(i, d) eji

d + Did (24)

We have shown that a given direction is descent if, and only if (12) applies (see "Mathematicalformulation and theoretical framework" on page 313). In terms of arc flows directed todestination d∈Z, the following results:

∑ijA cij • (eijd - fijd) < 0, (25)

expressing that the shift of flow from fd to ed must entail a decrease of total cost with respect tothe current cost pattern. The proof that the proposed procedure provides a descent directiongoes beyond the scope of this description. For more detailed information, please refer toGentile G., 2009.In the following we present an example showing the computation of the descent directionprovided by the LUCE algorithm. We consider the graph of the Braess paradox, with 4 nodesand 5 arcs.

319 © PTV AG


Illustration 96: 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 2routes from 2 to 4, are equally used by each OD pair. In this case it is fij = fijd and the bush isthe entire network.After we evaluate at the current flow pattern the arc costs and their derivatives, we cancompute for each node i the average cost Ci

d and its derivative Gid iteratively stating from the

destination, where Cdd = Gd

d = 0, and proceeding in reverse topological order. To this aim weapply the formulas:

Cid = ∑j∈FSB(i, d) yij

d • (cij + Cjd), Gi

d = ∑j∈FSB(i, d) yijd 2 • (gij + Gjd).

While the computation for node 3 is trivial, since its forward star is a singleton, for node 2 wehave:

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 = y13

4 • (c13 + C34) + y12

4 • (c12 + C24) = 0.33 • (29 + 52) + 0.66 • (41 + 57.5) = 92.7,

G34 = y13

4 2 • (g13 + G34) + y12

4 2 • (g12 + G24) = 0.332 • (12 + 14) + 0.662 • (12 + 9.5) = 12.4.

320 © PTV AG


Illustration 97: Numerical example of the procedure to obtain the descent direction

Now we can compute for each node i the node flows eid and the arc flows eij

d iteratively byproceeding 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 weassociate the cost function:

vij(eijd) = (cij + Cj

d) + (gij + Gjd) • (eij

d - yijd • ei

d),

resulting from a linearization at the current flow pattern of the average cost encountered by auser choosing arc ij, and we look for an equilibrium. We have shown that the latter can bedetermined using the following formulas:

Vid = (1 + ∑j∈J aij

d / bijd) / (∑j∈J 1 / bij

d), eijd = ei

d • (Vid - aij

d) / bijd,

where: aijd = (cij + Cj

d) - (gij + Gjd) • ei

d • yijd, bij

d = (gij + Gjd) • ei

d. 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 + C3

4) - (g13 + G34) • e1

4 • y134 = (29 + 52) - (12 + 14) • 9 • 0.33 = 3,

a124 = (c12 + C2

4) - (g12 + G24) • e1

4 • y124 = (41 + 57.5) - (12 + 9.5) • 9 • 0.66 = -30.5,

b134 = (g13 + G3

4) • e14 = (29 + 14) • 9 = 387.

b124 = (g12 + G2

4) • e14 = (41 + 9.5) • 9 = 454.5,

V14 = (1 + a13

4/b134 + a12

4/b124) / (1/b13

4 +1/b124) = (1+ 3/387-30.5/454.5) / (1/387+1/454.5) = 196.6,

e134 = e1

4 • (V14 - a13

4) / b134 = 9 • (196.6 - 3) / 387 = 4.5,

e124 = e1

4 • (V14 - a12

4) / b124 = 9 • (196.6 + 30.5) / 454.5 = 4.5.

Then we go on with node 2, whose node flow is e24 = e12

4 + D24 = 4.50 + 2 = 6.5:

a234 = (c23 + C3

4) - (g23 + G34) • e2

4 • y234 = (21 + 52) - (8 + 14) • 6.5 • 0.5 = 1.5,

a244 = (c24 + C4

4) - (g24 + G44) • e2

4 • y244 = (42 + 0) - (16 + 0) • 6.5 • 0.5 = -10,

321 © PTV AG


b234 = (g23 + G3

4) • e14 = (8 + 14) • 6.5 = 143.

b244 = (g24 + G4

4) • e14 = (16 + 0) • 6.5 = 104.

V24 = (1 + a23

4/b234 + a24

4/b244) / (1/b23

4 +1/b244) = (1 +1.5/143 -10/104) / (1/143+1/104) = 55.1,

e234 = e2

4 • (V24 - a23

4) / b234 = 6.5 • (55.1 - 1.5) / 143 = 2.43,

e244 = e2

4 • (V24 - a24

4) / b244 = 6.5 • (55.1 + 10) / 104 = 4.07.

Finally we consider node 3, whose node flow is e34 = e134 +

e234 + D34 = 4.5 + 2.43 + 0 = 6.93:

Since there is only one alternative, e344 = e34 = 6.93 results immediately. Only for completeness

we compute V34 as follows:

V34 = (c34 + C4

4) + (g34 + G44) • (e34

4 - 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:

∑ij∈A fijd • cij = 949 > ∑ij∈A eijd • cij = 897.

illustration 96 represents the AON assignment to shortest paths (marked by *). illustration 97displays the equilibrium flow and cost pattern (marked by *). It can be seen that one singleiteration of the proposed descent direction allows a substantial step towards the solution.

5.13.4 Assignment algorithmBelow we provide a pseudo code of the procedure within the framework of an assignmentalgorithm.

function LUCEf = 0 initialize the solution flows to zerofor k = 1 to n perform n iterationsfor each d∈Z for each destination dfor each ij∈A compute arc costs and their derivatives

cij = cij( fij)gij = max{∂cij( fij)/∂fij, ε}if fid > 0 then yij

d = fijd / fid else yijd = 0

B(d) =B(B(d), c, f) initialize or modify the current bushCd

d = 0 the average cost of the destination is zeroGd

d = 0 so its derivativefor each i:∃ij∈B(d) in reverse topological order for each node i ≠ d in the bushif fid > 0 then

Cid = ∑j∈FSB(i, d) yij

d • (cij + Cjd) compute the node average cost to d

Gid = ∑j∈FSB(i, d) yij

d 2 (gij + Gjd) and its derivative

elseCi

d = min{cij + Cjd: j∈FSB(i, d)}

Gid = ∑j∈FSB(i, d) [Ci

d = cij + Cjd] • (gij + Gj

d) / ∑j∈FSB(i, d) [Cid = cij + Cj

d],ed = 0 reset the arc and node flows to dfor each o∈Z load on the origins the demand to d

eod = Dod

for each i:∃ij∈B(d) in topological order for each node i ≠ d in the bushJ = FSB(i, d) initialize the set of arcs with positive flowλ = 0until λ = 1 do

λ = 1

322 © PTV AG


Vid = [ei

d + ∑j∈J (cij + Cjd) / (gij + Gj

d) - eid•yij

d] / ∑j∈J 1/(gij + Gjd)

for each j∈Jeij

d = Vid / (gij + Gj

d) - (cij + Cjd) / (gij + Gj

d) + eidyij

d if eij

d < 0 theneij

d = 0J = J \ {j} remove ij from the set of arcs with positive flowλ = 0 then repeat the procedure

for each j∈Jej

d = ejd + eij

d propagate the arc flows to the head node flowsα = 1if k > 1 thenuntil ∑ij∈A cij( fij + α • (eij

d - fijd)) • (eijd - fijd) < 0 do α = 0.5 ⋅ α armijo step

for each ij∈A update arc flowsfij = fij + α • (eij

d - fijd)fijd = fijd + α • (eij

d - fijd)

The bush of each destination d∈Z is initialized with the set of efficient arcs that bring closer tothe 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 arcthat would improve shortest paths on the bush is added to it, if its reverse arc does not carrydestination flow. If the resulting sub-graph is acyclic, then it is substituted to the current bushof that destination. Since the LUCE algorithm tends to an equilibrium on the bush, eventuallythe 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 shortestpath computations, but only simple visits of the bushes.

5.13.5 Input and output attributes of the equilibrium assignment (LUCE)To execute the LUCE assignment, certain entries have to be made. After calculation, theresults are available in the output attributes and can be displayed in the list view (see UserManual, Chpt. 12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2,page 1253) .The Table 108 gives an overview of which input attributes have to be maintained.

5.13.6 Persistent storage of bushesThe VISUM format is used for the persistent storage of the demand segment-specific busheswith the edges that comply with the shortest path in VISUM.

Tip: This hint might help to reduce the LUCE run time by means of specific network modeling.Internally, LUCE has to explode a node to generate several sub-nodes and connecting linksbetween these sub-nodes, if the turns via the node have different impedances of if some ofthese turns are not open. Due to this, the graph on which the procedure works will beextended which again means an increase in the run time. If you do not want to model theturns explicitly in your network model, make sure that also the U-turns are permissible for allprivate transport systems. Otherwise, VISUM has to explode all nodes because of theblocked U-turns. By default, regular turns are open in VISUM, whereas U-turns are blocked.Thus open the U-turns, too, as long as the blocking does not need to be retained for someother reason. Bear in mind, that this will not have any negative effect on the created routes,since U-turns are never traversed by loaded routes as long as none of the turns has beenmodeled explicitly.

323 © PTV AG


Bushes are regarded for the following operations on paths: • Skim matrix (also for a freely definable skim) in case of route-based assignments:

• for the „Minimum“ weight, always the shortest path is used for calculation• for the „Mean over route volumes“ weight, the shortest path is used only if the OD pair

is not in the bush; otherwise, the skim data is weighted with the volumes of the edgesfrom the origin to the destinations.

• Flow bundle • TFlowFuzzy• COM: TFlowMatrix• OD pair filter• Blocking back• Generate demand matrix from paths Furthermore, they are regarded for the following operations:• Paths list output• Draw paths• COM (Paths interface)• Route export• Subnetwork generation• ANM export• Demand matrix calibration• Optimization of the signal timing coordination

5.14 Equilibrium_LohseThe Equilibrium_Lohse procedure was developed by professor Lohse and is described inSchnabel (1997). This procedure models the learning process of road users using the network.Based on an "all or nothing" assignment, drivers make use of information gained during theirprevious trip for the new route search. Several shortest routes are searched in an iterativeprocess whereby for the route search the impedance is deduced from the impedance of thecurrent volume and the previously estimated impedance. To do this, the total traffic flow isassigned 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 intoaccount (like 100 % best-route assignment). The calculation of the impedance in every further iteration step is carried out using the currentmean 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 routewas found ("kept in mind" by VISUM). The procedure only terminates when the estimated times underlying the route choice and thetravel times resulting from these routes coincide to a sufficient degree; there is a highprobability that this stable state of the traffic network corresponds to the route choice behaviorof drivers.

324 © PTV AG

Chapter 5.14: Equilibrium_Lohse

To estimate the travel time for each link of the following iteration step n+1, the estimated traveltime for n is added to the difference between the calculated actual travel time of n (calculatedfrom the VD functions) and the estimated travel time of n. This difference is then multiplied bythe 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 foriteration steps n and n-1, and the calculated actual travel time of iteration step n, sufficientlycorrespond to each other. This is defined by the precision threshold EPSILON.

5.14.1 Example of the Equilibrium_Lohse procedureThe Equilibrium_Lohse procedure is demonstrated below with a calculation example.Table 111 shows the parameter settings of the Equilibrium_Lohse and the impedance for linksand routes in the unloaded network. Table 112, Table 113 and Table 114 then show threeiterations of the calculation process.

LinkNo Type Length [m] v0 [km/h] Capacity [car units] R0* [min]

1 20 5000 100 1200 03:00

2 20 5000 100 1200 03:00

3 20 5000 100 1200 03:00

5 20 5000 100 1200 03:00

6 20 5000 100 1200 03:00

7 20 5000 100 1200 03:00

8 30 16000 80 800 12:00

9 30 5000 80 800 03:45

10 40 10000 60 500 10:00

11 40 5000 60 500 05:00

Table 111: Impedance in unloaded network, input parameters of Equilibrium_Lohse method

Route Links Length [m] R0* [min]

1 1+8+9 26000 0:18:45

2 1+2+3+5+6+7 30000 0:18:00

3 10+11+5+6+7 30000 0:24:00

Input parameters:• BPR function with a = 1, b = 2, c = 1• ΔLowerLimit = 0.15• ΔUpperLimit = 0.5• V1 = 2.5• V2 = 4• V3 = 0.002

• f TT( ) 2.51 e4 0.002 TT⋅–+--------------------------------------=

325 © PTV AG


LinkNo

Volume1 [car units] R1 [min] TT1 f(TT1) Delta Δ1 R1* [min]

1 2000 11:20 2.78 0.0452 0.4796 07:00

2 2000 11:20 2.78 0.0452 0.4796 07:00

3 2000 11:20 2.78 0.0452 0.4796 07:00

5 2000 11:20 2.78 0.0452 0.4796 07:00

6 2000 11:20 2.78 0.0452 0.4796 07:00

7 2000 11:20 2.78 0.0452 0.4796 07:00

8 0 12:00 0.00 0.0450 0.5000 12:00

9 0 03:45 0.00 0.0450 0.5000 03:45

10 0 10:00 0.00 0.0450 0.5000 10:00

11 0 05:00 0.00 0.0450 0.5000 05:00

Route Volume1 R1 R1*

1 0 0:27:05 0:22:45

2 2000 1:08:00 0:41:59

3 0 0:49:00 0:35:59

Table 112: Example of Equilibrium_Lohse: 1. Iteration Step

LinkNo


1 2000 11:20 0.62 0.0450 0.4925 09:08

2 1000 05:05 0.27 0.0450 0.4962 06:03

3 1000 05:05 0.27 0.0450 0.4962 06:03

5 1000 05:05 0.27 0.0450 0.4962 06:03

6 1000 05:05 0.27 0.0450 0.4962 06:03

7 1000 05:05 0.27 0.0450 0.4962 06:03

8 1000 30:45 1.56 0.0451 0.4855 21:06

9 1000 09:37 1.56 0.0451 0.4855 06:36

10 0 10:00 0.00 0.0450 0.5000 10:00

11 0 05:00 0.00 0.0450 0.5000 05:00


1 1000 0:51:42 0:36:50

2 1000 0:36:45 0:39:22

3 0 0:30:15 0:33:08


326 © PTV AG


Table 111, Table 112, Table 113 and Table 114 illustrate the first three iteration steps of theEquilibrium_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 thelowest impedance route of the unloaded network.For impedance R0* this is route 2, whichis 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) = 3min • (1+(2,000/1,200)²) = 11min 20s

• Estimated impedance R1*

The estimated impedance R1* of every link consists of the current impedance R1 and theestimated impedance R0* of the last iteration step. It results from the learning factor Δ. Todetermine R1* for link 1, the following calculations are necessary:

• R0* = 3min = 180s• R1 = 11min 20s = 680s• TT1 = |R1 - R0*| /R0* = |680s - 180s| / 180s = 2.78

LinkNo


1 1333 06:42 0.27 0.0450 0.4963 07:56

2 667 03:56 0.35 0.0450 0.4953 05:00

3 667 03:56 0.35 0.0450 0.4953 05:00

5 1333 06:42 0.11 0.0450 0.4984 06:22

6 1333 06:42 0.11 0.0450 0.4984 06:22

7 1333 06:42 0.11 0.0450 0.4984 06:22

8 667 20:20 0.04 0.0450 0.4994 20:43

9 667 06:21 0.04 0.0450 0.4994 06:28

10 667 27:47 1.78 0.0451 0.4842 18:37

11 667 13:53 1.78 0.0451 0.4842 09:18


1 667 0:33:23 0:35:07

2 667 0:34:40 0:37:03

3 667 1:01:47 0:47:02


327 © PTV AG


•

•• R1* = R0* + Δ1 • (R1 - R0*) = 180s + 0.4796 • (680s - 180s) = 420s


The lowest impedance route for R1* is route 1. Now two routes exist, route 1 and 2. Everyroute is loaded with 1/n, that is, with ½ demand, so that every route is used by 1,000 cars.


The current impedance R2 of every link increases on newly loaded links 8 and 9, and itdecreases on links 2, 3, 5, 6 and 7.


The estimated impedance R2* of every link consists of the current impedance R2 and theestimated impedance R1* of the last iteration step.


The lowest impedance route for R2* is route 3 1/3 of the 2,000 car trips are now distributedover routes 1, 2 and 3.


The current impedance R3 again results from the current volume 3 via the VD function.


The estimated impedance R3* of every link consists of the current impedance R3 and theestimated impedance R2* of the last iteration step.

Iteration step 4, n = 4The concluding route search based on R3* determines route 1 as the shortest route. Thus, thefollowing route volumes result:• Volume route 1 = 2/4 • 2,000 = 1,000 trips• Volume route 2 = 1/4 • 2,000 = 500 trips• Volume route 3 = 1/4 • 2,000 = 500 trips

5.14.2 Input and output attributes of the Equilibrium_Lohse procedureTo 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 UserManual, Chpt. 12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2,page 1253) . The Table 115 gives an overview of which input attributes have to be maintained.Table 116 lists the output attributes which store the results of the procedure.

( ) 0452,078,2002,04e15,2TT3V2Ve11V1TTf 1 =⎟⎠⎞⎜

⎝⎛ ×−+=⎟

⎠⎞⎜

⎝⎛ ×−+=

( ) ( ) ( )4796.00452.078.21

15,05,015.011

11

=+

−+=

+

Δ−Δ+Δ=Δ TTfTT

BottomTopBottom

328 © PTV AG


Table 115: Input attributes of the Equilibrium_Lohse procedure


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

329 © PTV AG


Table 116: Output attributes of the Equilibrium_Lohse procedure

5.14.3 Procedure of the Equilibrium_Lohse assignmentThe succeeding steps in the Equilibrium_Lohse procedure are illustrated by illustration 98.

330 © PTV AG


Illustration 98: Procedure of the Equilibrium_Lohse assignment

5.14.4 Evaluation of the Equilibrium_Lohse procedureUnder the condition that a sufficient number of iteration steps (N > 40) are carried out and thatthe procedure is not terminated due to the condition n = N, the Equilibrium_Lohse methodproduces realistic, stable results. Even in networks with low saturation, the distribution of

Upper and lower threshold of delta: Δupper and Δlowerparameters of the f(TT) function: V1, V2, V3Termination conditions: max. number iterations N;E1, E2, E3 for determining the max. deviation E of impedance

Input

n = 0, Rn=0* = Impedance in unloaded network

Determine volumes for all routes of any relation ij: Route volume qr = (Fij / n) • Countr

n = N or for every link applies:

Rn = impedance at current volume n

Route volumes

Route search

Query

Impedance determination

yes

no

Determination of shortest route rn for all OD pairs based on impedance Rn-1*I f route rn is new router: Countr = 1If route rn already exists as router : Countr = Countr +1

n = n + 1

End

*1

*1 −−−= nnnn RRRTT

)1()( 321

nTTVVn eVTTf ×−+=

( ) )(n 1 nTTfnTT

lowerupperlower

+Δ−Δ

+Δ=Δ

( )*nnn

*n

*n RRΔRR 11 −− −×+=

32 /11

*1

EEnnn REERR −− ×=<−

331 © PTV AG


volumes onto alternative routes is good. The greater number of iteration steps necessary for agood solution usually requires more route searches than the equilibrium assignment. Thisresults in longer computing times.

5.15 Assignment with ICACompared to other procedures, using volume-delay functions by lane which are permanentlyre-calibrated by means of ICA causes a significantly improved convergence behavior, sincethe lane geometry and interdependencies between the individual turns via a node are regardedin detail.

5.15.1 Fundamental principleIn VISUM, any variant of the equilibrium assignment uses volume-delay functions for links andturns to model the impedance that increases with increasing volumes. In urban networkmodels, the Turn VDFs are of particular importance, since the nodes affect the networkperformance to a much greater extend than links do. The mathematical formulation of theassignment problem assumes, that the impedance which is calculated by the VDFs dependsonly on the volume and the capacity of the individual network object (link, turn). Volume delayfunctions with this property are called separable VDFs. In reality, this holds approximately forlinks, but it does not apply to turns via nodes. Typical counter-examples are the permitted turnsat signalized nodes or turns from minor approaches at two-way nodes. In these cases, theimpedance does not only depend on the volume of the turn itself, but also from the volumes ofthe conflicting flows, i.e. the volumes of other turns via this node. Thus, the associated volume-delay functions can no longer be separable. This is a problem for the mathematical solution ofthe assignment problem, since existence and uniqueness of the equilibrium solution requireseparable volume-delay functions.Two requirements can be derived from this analysis:• Realistic impedance modeling for nodes premises that nodes are modeled in detail in a way

that conflicts between turns can be identified correctly. Transferred to VISUM this means,that for these nodes the geometry and control have to be modeled in the junction editor.Subsequently, precise impedances and capacities of the turns can be calculated using theIntersection Capacity Analysis (ICA).

• For lack of separability, the values calculated by means of ICA may not directly be used toreplace the volume-delay functions in the assignment procedure, since the convergencewould get lost then.

Illustration 99: ICA-based impedance calculation

Assignment with volume/delay functions by turn

Impedance calculation using ICA

Smoothedturn

volumes

Adjustment of the parameters for turn VDFs

332 © PTV AG

Chapter 5.15: Assignment with ICA

VISUM by-passes the separability problem by an approximation approach. The procedurecomprises an interaction of an equilibrium assignment procedure (using conventional VDFs)and the node impedance calculation (ICA). First, some assignment iterations determine turnvolumes among others which are used as input data for ICA. With ICA, turn capacities and waittimes are determined first for the given volumes resulting from assignment. Then the volumeof each individual turn is varied while the volumes of the other turns via the same node areretained for the wait time estimation with various load cases. From the determined wait timesa volume-delay function is interpolated for each turn subsequently. These turn-specific VDFswill then be used in the next iteration of the assignment. They model the dependence of theimpedance on only the turn volume while the conflicting flows are regarded as if beingconstant. From the assignment's point of view, the effect of conflicting flows is "frozen" therebyuntil (after more equilibrium iterations) these flows are also updated in the next ICA calculation.In this way, the volume-delay functions are stabilized for some iterations in each case to favorconvergence. The feedback loop between assignment and ICA terminates as soon as theimpedances calculated by the volume-delay function or ICA respectively do not differsignificantly anymore. For links and connectors, if applicable, the assignment with ICA usesregular volume-delay functions. Their parameters do not depend on the individual networkobject, however, for links they depend on the link type only.

5.15.2 Evaluation of the procedureSpecific advantage: Usually, ICA cannot be applied properly while an assignment is runningsince the volume-delay functions are not separable. By "freezing" the conflicting flows for someiterations of the equilibrium assignment, the Turn VDFs become "approximately separable".Normally, convergence is reached in this way. Simultaneously, the Turn VDFs arecontinuously adjusted to the wait times and capacities calculated by ICA. The HCM 2000method used by ICA is one of the most highly approved analysis methods for nodeperformance calculations and considers the lane distribution and conflicting turns in detail.The disadvantage is the significantly higher time and effort for modeling and calibration, sincenodes whose impedances are to be calculated by ICA have to be modeled in detail. If you donot want to model all nodes in detail in your network model you should make sure that for theother nodes volume-delay functions are used which provide impedance data in a comparablescale. The route choice will be distorted if mixed impedances are produced by ICA turns andnon-ICA turns systematically: Then, for example, only routes are chosen that do not traverseICA nodes.Also the assignment itself requires more computation time than a usual equilibriumassignment, since additional ICA calculations are required and because the adjustment of theturn VDFs after some balancing iterations at a time usually leads to a regression inconvergence which has to be caught up accordingly thereafter. That is why you mightcalculate an assignment with ICA for the base scenario of a project, where as a by-product thevolume-delay functions by turn are adjusted to the volumes reached in the balanced state. Youcan continue to use these VDFs without modifications as far as the volumes do not significantlychange in the scenarios which are to be analyzed subsequently. For this, VISUM makes itpossible to calculate a normal equilibrium assignment (without ICA, i.e. fast), however usingthe turn-specific VDFs in this process which result from the recent assignment with ICA.

333 © PTV AG


5.15.3 Input and output attributes of the assignment with ICAPrior to the calculation of an assignment with ICA, certain attributes of network objects and alsoprocedure parameters have to be set. After the calculation, the results are available in theoutput attributes and can be displayed in the list view (see User Manual, Chpt. 12.1,page 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) . Table 117gives an overview of which input attributes have to be maintained. It is of particularimportance, that for those nodes whose turn impedances shall be calculated in detail with ICA,the option Node impedance calculation (ICA) is selected for the attribute Method forimpedance at node and that the attribute Use preset method for impedance at node is setto TRUE. Table 119 lists the output attributes which store the results of the procedure.The following prerequisites are required for the assignment with ICA:• Prior to the assignment with ICA calculation, the geometry and control need to be modeled

correctly for the nodes the ICA impedance calculation has been activated for. Whether thecalculation can be performed correctly for all these nodes you can verify quickly via menuCalculate >Network check by means of the option Viability for ICA.

• For turns, the design volume PrT needs to be a volume-representing attribute (Volume PrTor Volume PrT with base). The configuration has to be set via menu Calculate >Procedures > tab Functions > navigator entry PrT functions > Node impedances. Forthe design volume PrT, only factor 1.0 is permitted. This is due to the fact, that thecalibration of the VDFs by turn would fail otherwise. For consistency reasons, the factorneeds to be set to 1.0, too, for any other turn (turns not to be calculated by ICA).

334 © PTV AG


Table 117: Input attributes of the assignment with ICA


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

335 © PTV AG


For the output of results, the following options are provided:There are different output variants: Primarily, the assignment with ICA fills the usual attributesof the various network object types (link, turn, etc.) with the calculated volumes andimpedances. Additionally to the common volume and travel time attributes, for turns and main turns thefollowing output attributes are provided which are only filled by the assignment with ICA:

Furthermore, numerous diagnostic outputs are provided which can be used for convergencecheck. If the procedure converges either slowly or not at all, the outputs provide usefulindications, for example, which of the turns show significant differences between theimpedance calculations with ICA and the volume-delay function.• As long as the procedure is running, you can watch the process in the "Goodness of PrT

assignment with ICA" list.• Files of the *.csv data type are created which store the intermediate turn attribute data.

These files are helpful for comparisons of the development of the attribute values ofindividual turns in different iterations.

• Output attributes of the recent iteration are stored as user-defined attributes, if applicable.This data can be used for the comparison of the convergence reached in different runs ofthe assignment with ICA. However, the created user-defined attributes need to be copiedprior to the second run.

Note: Please note, that Toll PrTSys (marked by x1) has to be inserted manually in theimpedance function to have an effect.

Attribute Meaning

Is ICA turn in ICA assignment Indicates whether the ICA-Turn function is to be used for this turn in the assignment with ICA.

Final capacity for assignment with ICA

Capacity that was recently used with ICA assignment. In contrast, the attribute Capacity PrT specifies the initial capacity of the turn at the start of the procedure which can be reduced by the ICA calculation.

Final t0 for assignment with ICA

t0 that was recently used with ICA assignment. In contrast, the attribute t0-PrT specifies the loss time of the turn in the unloaded network at the start of the procedure. This value is changed by the ICA calculation.

Final smoothed volume for assignment with ICA

Smoothed volume resulting from recent iteration.

tCur-PrTSys for assignment with ICA

tCur-PrTSys from the turn-specific VDF with final VD function parameters. In contrast, the attribute tCur-PrTSys stores the result calculated in the recent ICA calculation.

Impedance-PrTSys for assignment with ICA

Impedance-PrTSys from the turn-specific VDF with final VD function parameters. In contrast, the attribute Impedance-PrTSys stores the result calculated in the recent ICA calculation.

Final A for assignment with ICA

Final VD function parameter a for the turn-specific VDF

Final B for assignment with ICA

Final VD function parameter b for the turn-specific VDF

Table 118: Additional attributes of turns and main turns for assignment with ICA

336 © PTV AG


• Optionally, an Excel report is created which contains the results of the recent ICAcalculation. From the report it is to be seen, which volumes were used for the calculationand which capacities resulted from that. For nodes of the All-way stop type, the v/c value isreturned in the same way as for nodes of the Two-way stop type.

Table 119: Output attributes of the assignment with ICA

The precise times, when attribute data is stored in an iteration is described with the procedure(see "Description of the procedure" on page 337). Additionally please note the following:• Also for other network objects, the volumes, times, and impedances are evaluated and

modified.• The assignment with ICA ignores the global attribute for the Design volume PrT. Neither

the global factor is taken into account. The smoothed volumes of the turns are usedinstead.

5.15.4 Description of the procedureThe assignment with ICA is based on the iterative solution for the user optimum with volume-delay functions for all network objects. The distinctive feature is that the parameters of the turnVDFs can be set by turn and might change during the calculation due to the adjustment of theICA calculation results, as described with the fundamental principle (see "Fundamentalprinciple" on page 332).

337 © PTV AG


It is possible to activate the blocking back model as long as the procedure is running. In thiscase, the blocking back model is applied after the completion of the embedded assignmentprocedure to adjust the turn volumes first and the link impedances then. However, the linkcapacity remains unchanged. The modified turn volumes are regarded by ICA. • First the embedded assignment procedure is performed. For those nodes, for which ICA

calculation has been activated, the VDFs by turn are used. This means, that no ICA isapplied as long as the embedded assignment procedure is running.

• A specific description is provided for the definition of the volume delay functions applied byturn (illustration 100, query 2: Is the turn share T below p2?“).

• Once the embedded assignment procedure is finished the blocking back model canoptionally be applied. Please note, that the blocking back model is not used as long as theembedded assignment procedure is executed.

• The global parameters for the blocking back model are ignored, if the blocking back modelis used (see User Manual, Chpt. 5.5.2, page 884). Only the parameters set for theprocedure assignment with ICA will take effect.

• Only the capacities of turns are adjusted, when the blocking back model is used. Capacitiesof links or nodes are not modified. However, link impedances are adjusted. Only Phase 1of the blocking back model is performed.

• Prior to the ICA calculation, the current values are determined for volume and impedanceand also the parameters of the VDFs are recorded (according to the settings: in attributefiles, as user-defined attributes and in the Goodness of PrT assignment with ICA list). Then,the turn volumes calculated in the recent iteration and in the current iteration are smoothed,i.e. the weighted mean is calculated.

• Subsequently to the assignment and to the optionally performed blocking back model, theimpedances and the capacities of the turns are calculated via ICA. For the ICA calculation,the smoothed turn volume (also with base volume, if applicable) is used as design volumePrT.

• The calculation of new turn-specific VDFs is performed in two steps, in each case for allturns or main turns separately. In the first instance, the parameters of the volume-delayfunction are determined by interpolation of three sampling points. One sampling point isknown from the smoothed turn volumes resulting from the assignment and the relatedimpedance, for two more sampling points, the volume of the currently processed turn isreduced or increased, while the volumes of other turns via the node are kept; then theimpedance of the current turn is calculated again via ICA. Since the VDF which is to beinterpolated shows three free parameters (t0, a, b), it is clearly defined by the threesampling points. In the second step, these parameters and also the capacity are smoothedby 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 minimumcapacity, the minimum capacity will be used instead.

• The convergence check is performed after the determination of the new VDFs. If theconvergence constraints are satisfied, the parameters of the VDF will be reset to the valueof the recent iteration. This means, that the VDFs of the recently performed embeddedassignment are suitable. You can reproduce the equilibrium state from the recentembedded assignment as follows: For the ICA nodes, select the turn-specific VDFs (option"From previous assignment with ICA") for the method for impedances at node parameter

338 © PTV AG


after the procedure is finished. In the flow diagram, qTn represents the volume of turn T initeration n.

339 © PTV AG


Illustration 100: Procedure of the assignment with ICA

340 © PTV AG


5.15.5 Used turn VDF

Illustration 101: Turn volume delay function of the assignment with ICA

where

For each (main) turn, the factors a and b are updated with every ICA impedance calculationduring the assignment. The values that apply to the recent iteration can be found in the (main)turn attributes Final A for assignment with ICA and Final B for assignment with ICA.

a and b Attributes of the particular (main) turn

satcrit satcrit = 1.1

b‘ b‘ = 3b (thus more steeply compared to sat ≤ satcrit)

a‘ a‘ =

t0‘ t0‘ =

a‘ and t0‘ These values have been selected, so that both branches are differentiatedly linked together for sat = satcrit.

0,0000000000

5,0000000000

10,0000000000

15,0000000000

20,0000000000

25,0000000000

30,0000000000

35,0000000000

40,0000000000

s

Volume/Capacity Ratio

ICA Turn Volume/Delay Function

ICA Turn

Part 1

Part 2

tcur sat( )t0 a satb⋅+ sat s≤ atcrit

t0' a' s⋅ atb'+ sat s> atcrit⎩⎪⎨⎪⎧

=

a3--- satcrit

b b'–⋅

t0 a satcritb⋅ a' satcrit

b'⋅–+

341 © PTV AG


5.16 Stochastic assignmentStochastic assignment procedures assume that traffic participants in principle select the bestroute, 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 modelsin the assignment" on page 289) to the found routes as for a PuT assignment using adistribution 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, asimilarity measure is determined from overlapping routes (analogous to independence duringtimetable-based PuT assignment) – it is called the Commonality Factor ( “C-Logit“) – or theindependence 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 theshortest route that is found, but a number of alternatives are found using a multiple best pathsearch 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 poorlyloaded network in the case of the stochastic assignment, because a (small) part of the demandis also assigned to suboptimal routes due to the distribution model. In all cases, this propertyis closer to reality than the strict application of Wardrop’s first principle.

5.16.2 Input and output attributes of the stochastic assignment To execute the stochastic assignment, certain entries have to be made. Table 120 gives anoverview of which input attributes have to be maintained. After calculation, the results areavailable in the output attributes and can be displayed in the list view (see User Manual, Chpt.12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) .Table 121 lists the output attributes which store the results of the procedure.

342 © PTV AG

Chapter 5.16: Stochastic assignment

Table 120: Input attributes for the stochastic assignment

The abbreviations represent the following:

x1 Toll PrTSys has to be inserted manually in the impedance function

343 © PTV AG


Table 121: Output attributes for the stochastic assignment

5.16.3 Procedure of the stochastic assignmentThe procedure is broken down into an external and an internal iteration (illustration 102).• The external (global) iteration with iterator n is used for the route search. This loop is

repeated until either n = N or until no new shortest routes are found.• The internal iteration with iterator m is used to assign the volume to the routes. This loop is

repeated until either m = M or until the deviations of the impedances on the networkelements and the deviation of the volumes on the routes between two iteration steps is verysmall.

(x) Can be used optionally(*) Apart from the parameters which are directly set in the assignment procedure

344 © PTV AG


n = 0Start of external iterartion

Calculate impedance R in the unloaded network for all network elements.

Calculate one route per OD pair using a shortest pathsearch with Rn. Generate other routes by varying Rn based on a standarddistribution 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 existingroute.

Calculate independence factor (commonality factor) that takes into account the relative similarity of the routes or calculate the independence (Ben Akiva)

Number of new shortest routes > 0

Delete all routes with R > a • R*min + b andt0 > c • t0,min + d

Counter for external iterat ion

Route search

Route preselection

Independence

no

Search impedance

n = n + 1

Termination external iterat ion

jastop

345 © PTV AG


Illustration 102: Procedure of the stochastic assignment

The alternative route search by stochastic variation of the impedances is closely related toother procedures used to determine k-shortest paths and shares their common drawback thatoften new routes are found that differ insignificantly from previous routes. Such routes are notdesirable as they hardly change the volume situation in the network and only increase the routequantity, which leads to extended computing time and higher memory requirements. For thisreason a detour test is offered as part of the stochastic assignment that discards a route r2 if aroute r1 already exists that matches r2, with the exception of a subsection, and if this

m = 0Start of internal iteration

Set impedance R or R* of all network objects toimpedance in the unloaded network.

Calculate R * of all routes as a total R * for all traversednetwork objects. Correct impedance using impedance factor.

Calculate R * for all network objects from the volumes thatresult from the route choice. The search impedance is an estimated R * value that iscalculated as in the Equilibrium_Lohse procedure:

m = max. number of internal iterations oris valid for the impedance of all network elements, and

is valid for the volume of all routes

Counter for internal iteration

Choice impedance

Route volume

Update search impedance

no

Initialisation of choice

impedance

m = m + 1

Termination criterion for

internal iteration

ja

Assignment of demand across the routes in accordancewith Logit, Box-Cox, Kirchhoff, Lohse or Lohse withvariable beta results in route volumes qrm*

Route choice

n = max. number of external iteration

Termination of external iteration

yes

no

stop

mqmq

q rmmrrm

')1()1( +−⋅= −

( )*oldnew

*ld

*new RRRR o −×Δ+=

),),max(min( 32*

1*

1*

1* EERRERR mmmm +⋅≤− −−

),),max(min( 65)1(4)1( EEqqEqq mrrmmrrm +⋅≤− −−

346 © PTV AG


subsection in r2 is significantly longer than in r1. More precisely, r2 is discarded in favor of r1 ifthe following applies (illustration 103).• r1 = AT1B• r2 = AT2B• Length(T2) > Factor • Length(T1)

Illustration 103: Discarding routes

The route sections A and B can be empty if the subsection is at the start or the end of theroutes.

5.16.4 Similarity of routes and commonality factorIn the case of the stochastic assignment, alternative routes are generated - based on anotherassignment as initial solution - for an OD pair by varying the impedances of the network objectsbased on a distribution, in order to model the incomplete information supplied to the road-usersand their individual differences in terms of perception and preferences. In this way, it ispossible to calculate in one step not only the shortest route in terms of impedance, but alsoalternative routes with higher impedances. After completion of the route search, depending onthe route impedance based on an assignment model (Logit, Box-Cox, Kirchhoff, Lohse orLohse with variable beta), the demand is distributed across the alternatives. The similarity ofthe routes is to be taken into account during the distribution process. The problem of similarityis illustrated with the example below (illustration 104):Whereas the independence of the routes is given in cases 1 and 2, there is a dependence ofroutes 1 and 3 in case 3, since there is some degree of overlap. This overlapping must betaken into consideration in the route choice.

347 © PTV AG


Illustration 104: Example for similarity of routes

The C-Logit approach proposed by CASCETTA is a suitable way of overcoming this problem.To do this, a so-called commonality factor C is introduced to measure the overlapping of thetwo routes r and s as follows:

Case 1 Portion

expected Logit

Route 1 50% 50%

Route 2 50% 50%

Case 2 Portion

expected Logit

Route 1 33% 33%

Route 2 33% 33%

Route 3 33% 33%

Case 3 Portion

expected Logit

Route 1 approx. 28%

33%

Route 2 approx. 44%

33%

Route 3 approx. 28%

33%

Route 1

Route 2 Impedance R1 = R2

Route 2 Impedance R1 = R2 = R3

Route 1

Route 3

Route 2 Impedance R1 = R2 = R3

Route 1

Route 3

348 © PTV AG


or

with

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 factorCFr of a route r compared to any other route s is defined as follows:

The correction factor of a route r is 1 if the commonality factors Crs for all routes s have thevalue 0, i.e. the route has no overlap with another route. In any other case it is below 1. Thecorrection factor CFr is then regarded in the Logit model as follows:

In the case of Box-Cox, Kirchhoff, Lohse or Lohse with variable beta, its inclusion is alsocarried out in the same way.Alternatively, the correction factor CFr can be determined using a simpler approach accordingto Ben Akiva. It is then defined as:

or

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

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

Crst0rs

t0r t0s⋅---------------------= Crs

lrs

lr ls⋅----------------=

CFr1Crss∑

----------------- 11 Crsr s≠∑+---------------------------------= =

Pe

Vr CFr⋅

eVs CFs⋅( )

s 1=

N∑--------------------------------------------=

CFrt0at0r------ 1

Nija---------⋅⎝ ⎠

⎛ ⎞a Pr∈∑=

CFrlalr---- 1

Nija---------⋅⎝ ⎠

⎛ ⎞a Pr∈∑=

349 © PTV AG


5.16.5 Example for the stochastic assignmentThe Table 122 shows the main key input data for the sample network. If the followingparameters are chosen for the search, then in a single external iteration, all 3 conceivableroutes 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 Ras mean value and whose standard deviation σ is given as a function of R.

After completing the search, the correction factor for the independence of each route isdetermined according to Cascetta. It is based on the similarity of the individual route pairs withreference to time t0 or to the length. The Table 123 shows the commonality factors C. Fromthis, the correction factor CFr of route r is calculated.

• Route 1

LinkNo Type v0 [km/h] Length [m] Capacity [car units] R0* [min] R0* [s]

1 20 100 5000 1200 03:00 180

2 20 100 5000 1200 03:00 180

3 20 100 5000 1200 03:00 180

5 20 100 5000 1200 03:00 180

6 20 100 5000 1200 03:00 180

7 20 100 5000 1200 03:00 180

8 30 80 16000 800 12:00 720

9 30 80 5000 800 03:45 225

10 40 60 10000 500 10:00 600

11 40 60 5000 500 05:00 300

Route Links Length [m] R0* [min] R0* [s]

1 1+8+9 26000 0:18:45 1125

2 1+2+3+5+6+7 30000 0:18:00 1080

3 10+11+5+6+7 30000 0:24:00 1440

Input parameters• BPR function with a = 1, b = 2, c = 1• ΔBottom = 0.5, ΔTop = 0.5 Δ = 0.5• Assignment with Logit, β = 0.001

Table 122: Impedance in the unloaded network, input parameters for stochastic assignment

CF11C1jj∑

----------------- 11.0 0.16 + 0.0+-------------------------------------- 0.8596= = =

350 © PTV AG


• Route 2

• Route 3

The share by route is calculated from the correction factor according to Cascetta and from theimpedance Rmin

0 in the unloaded network.

For Route 1, the portion is calculated using the Logit model as follows:

In the same way, the portions showed in the Table 124 result for Routes 2 and 3. The volumeof 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 105).This results in the impedances R1 of the routes. These interim results can be verified in VISUMif the maximum number of internal iterations are set to M = 1 in the assignment parameters.

Route pair t0ij t0i t0j Cij

1.1 1125 1125 1125 1.00

1.2 180 1125 1080 0.16

1.3 0 1125 1440 0.00

2.1 180 1080 1125 0.16

2.2 1080 1080 1080 1.00

2.3 540 1080 1440 0.43

3.1 0 1440 1125 0.00

3.2 540 1440 1080 0.43

3.3 1440 1440 1440 1.00

Table 123: Calculation of the commonality factor C for all route pairs

Route E Rmin0 exp(Rmin

0)•E Portion P qr1 R1

1 0.8596 1125 0.279079049 0.425 849.4 2470

2 0.6264 1080 0.212737561 0.324 647.5 1961

3 0.6978 1440 0.165335421 0.252 503.2 2848

Sum 0.657152032 1.000 2000.0

Table 124: Volumes in the first internal iteration step m = 1

CF21C2jj∑

----------------- 10.16 1.0 + 0.43+----------------------------------------- 0.6264= = =

CF31C3jj∑

----------------- 10.0 0.43 + 1.0+-------------------------------------- 0.6978= = =

P10.8596 e-0.0011125⋅

0.8596 e-0.0011125 0.6264 e-0.0011080⋅ 0.6978 e-0.0011440⋅+ +⋅---------------------------------------------------------------------------------------------------------------------------------------------------- 0.425= =

351 © PTV AG


Illustration 105: Volumes and link run times after the first internal iteration step m=1

For the route choice in the second iteration step, an estimated impedance 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.

For m = 2, this results in the following for the volume of Route 1:

This route volume then leads to the link volumes and impedances of the second iteration step(Table 125). The iterations are repeated until the termination criteria are met.

Route E Rmin1 exp(R)•E Portion P qr2‘ qr2 R2

1 0.8596 1797.6 0.142432 0.3944 788.8 819.1 2405.2

2 0.6264 1520.7 0.136919 0.3791 758.3 702.9 2016.0

3 0.6978 2144.0 0.081775 0.2264 452.9 478.0 2785.6

Sum 0.361126 2000

Table 125: Volumes in the second internal iteration step m = 2

A Village

X City

qrmqr m 1–( ) m 1–( ) qrm'+⋅

m----------------------------------------------------------=

qr2849.4 2 1–( ) 788.8+⋅

2------------------------------------------------------=

352 © PTV AG

Chapter 5.17: TRIBUT

5.17 TRIBUTTaking 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 conventionalmonocriterial 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 twoseparate criteria, namely with time and costs (bicriterion).This method has been used for many years in France, for the evaluation of privately financedfreeways with toll management. Compared to the conventional approach, this approach is amore 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 assignmentprocedure. VISUM provides two extensions of this kind: TRIBUT-Equlibrium (as extension tothe "Equilibrium" method) and TRIBUT-Learning procedure (as extension to the"Equilibrium_Lohse" method).

5.17.1 Input and output attributes of the TRIBUT procedureTo execute a TRIBUT procedure, certain entries must be made. The Table 126 gives anoverview of which input attributes have to be maintained. After calculation, the results areavailable in the output attributes and can be displayed in the list view (see User Manual, Chpt.12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) .Table 127 lists the output attributes which store the results of the procedure.

353 © PTV AG


Table 126: Input attributes for TRIBUT

The abbreviations have the following meaning:

x1 Only for link tollx2 Only for area toll or matrix toll0 Generally possible, however not recommended(*) Apart from the parameters which are directly set in the assignment procedure

354 © PTV AG


Table 127: Output attributes for TRIBUT

5.17.2 Basics of the assignment with toll considerationThe decisive feature of an assignment procedure is the impedance definition for routeevaluation and route choice. With all toll-regarding assignment procedures, the impedance Rrof a route r consists of travel time tr and monetary costs cr:

Here, VT is the value of time in [€/h], for example. Though this equation applies to all toll-regarding assignment procedures, the TRIBUT procedure differs from other procedures in twoproperties:• 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 tollIn the simplest case, the route's monetary costs result from summing up the toll amounts bylink along the route.The following applies:

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

Rr tr cr VT⁄+=

355 © PTV AG


This toll type applies to the HGV toll in Germany, for example: On parts of the network(highways), heavy goods vehicles have to pay a toll amount which is precisely proportional tothe covered distance. Thus to each link of the highway link type the product from the link lengthx constant km cost multiplication can be allocated as toll amount. For any other link and for anyother transport system, the toll amount = 0. The total of these amounts summed up along aroute represents the cost resulting from the distance traveled on highway links for the transportsystem HGV.For link toll, no toll system has to be defined. It is not necessary either to include the linkattribute Toll-PrTSys in the impedance definition, since TRIBUT regards this amountautomatically.

Area tollEspecially toll systems for inner city areas often use a different type. For area toll, a physicallycohesive section of the network is allocated as toll area - and a distance-independent fixedcharge is collected if a route partially lies in the toll area:

Note: The TRIBUT-Equilibrium assignment always regards the link-specific toll values. TheTRIBUT-Learning procedure only regards the link-specific toll values of links which do notbelong to any toll system.

Rr trcrVT-------+ tLL r∈∑

cVT------- if a L € R lies in the toll area

0 otherwise⎩⎪⎨⎪⎧

+= =

356 © PTV AG


Illustration 106: Example for area toll : The London Congestion Charging Zone

At first view, the monetary costs of a route do not depend on the individual links beingtraversed, 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 linksand requires the impedances by link therefore. That is why TRIBUT puts the area toll down tothe link toll case. For that, define the toll area first by creating a network object 'toll system' ofthe area toll type and then allocating the toll area's number to all links which are located in thearea as value for the attribute Toll system number. The toll system additionally stores thefixed toll amount for each transport system. For the clear definition of the figure below, allconnector nodes of each zone need to be located either within the toll area or outside of it.On this basis, TRIBUT defines the toll amounts for links, turns, and connectors as follows:cL = 0 for all links L

cC = 0 for all connectors C

for all turns T, with δT = 1, if turn T leads from a link inside the toll area to a link

outside or vice versa, i.e. if the toll area border is crossed. Otherwise, δX = 0.

for all transitions X from connectors to links, where δX = 1, if the transition X leads

to a link in the toll area or originates from there. Otherwise, δT = 0.

illustration 107 illustrates the principle:

cT δTc2---⋅=

cX δXc2---⋅=

357 © PTV AG


Illustration 107: Reducing the area toll to the link toll case(For clarity reasons, turns without toll are not displayed)

Summing up the toll amounts along a route results in an amount null for routes that do nottouch the toll area at all. Any other route (origin traffic, destination traffic, through traffic, internaltraffic of the toll area) is charged with the toll amount of c, since they traverse exactly twonetwork objects with toll amount = c/2 each.In a VISUM model, you can define multiple toll systems of the area toll type. Then, thedefinitions for turn and connector cost are applied to each toll system with the associated fixedtoll amount. For turns between two toll areas the two toll amounts are charged. The area tolltype does not regard the link attribute Toll-PrTSys.Please note the two characteristics. For routes, that cross the border of the toll area multipletimes the toll amount is charged multiple times. This might not correspond to reality, howeverit 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 inreality. For the TRIBUT route choice it is no problem that these flows are nevertheless chargedwith toll amounts, since the toll comparably refers to all route alternatives and thus this additiveconstant value does not modify the equilibrium solution. But when calculating a skim matrix ofthe impedance for future use in a demand model for example, you need to perform anadditional matrix operation after skim matrix calculation to subtract the toll amount from theinternal traffic OD pairs data.

Matrix tollAnother type of toll models is often applied to arterial highways. In this case we have aphysically cohesive subnetwork with a limited number of connections (entries and exits) to theremaining network (illustration 108).

Note: Only the TRIBUT-Learning procedure takes the area toll into consideration.

Link outside of toll area

Link inside of toll area

Turn with toll

Connector with toll Connector without toll

Zone 1 Zone 2

358 © PTV AG


Illustration 108: Toll station at highway exit

Toll amounts are not defined as the sum of toll amounts by link, but arbitrarily as fee by pair(entry, exit). Using such a fee matrix, the operator has more flexibility since the toll amounts forlonger routes can be defined irrespectively of the toll amounts for shorter sections of a longerroute. Usually, those tariffs are on a diminishing scale, thus the rate per kilometer declines withincreasing total distance. As a matter of principle, such a matrix toll (which is named according to the fare matrix) cannotbe reduced to summing up the toll amounts by link. Let us have a look at the example inillustration 109:

Illustration 109: Example of a matrix toll

The links 1-2 and 2-3 form a highway corridor with matrix toll. For that, define the toll area firstby creating a network object 'toll system' of the matrix toll type and then allocating the toll area'snumber 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 tollamounts between all border nodes of the toll area. In this example, these are the nodes 1, 2,and 3. The toll amounts are listed in Table 128:

from / to node 1 2 3

1 0 2 3

2 2 0 2

3 3 2 0

Table 128: Toll amounts for the example network

Link outside of toll area

Link inside of toll area 1 2 3Node with number 1

359 © PTV AG


Please note, that the toll amount for the overall link is less compared to the two individual links.For each pair (entry, exit) in the toll area, TRIBUT generates a virtual link with the toll amountfrom the matrix in the network and uses these virtual links for the shortest path search. Incontrast, the original links in the toll area are not regarded for the shortest path search. Fortravel 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) requiredbetween 'from node' and 'to node' of the virtual link. illustration 110 shows the graph that isgenerated for the shortest path search in the example.

Illustration 110: Shortest path search graph with matrix toll

This modeling approach assumes a degressive toll matrix, i.e. if there are three nodes A, B,and C, always cA-C ≤ cA-B + cB-C applies. Furthermore, the number of virtual links that are addedto the search graph exhibits quadratic growth proportionally to the toll area's number of bordernodes.Thus you should use a toll matrix only in those cases where the toll area is connectedto the surrounding network by a manageable number of nodes.In a VISUM model, you can define several toll systems of the matrix toll type.Nevertheless,each link may belong to just one toll system. Then, virtual links are generated for each tollsystem and the toll amounts from the valid toll matrix are attributed to them.With matrix toll, the link attribute Toll-PrTSys is not regarded.

The Value of Time as stochastic parameterAdditionally, the TRIBUT procedure features the definition of the value of time (VT) and theimpact of this definition (Table 129). This description is reduced to the link toll case, since thebasic principle does not differ by toll type.

The complexity of a bicriterial route choice procedure can be made clear in a time-cost diagram(illustration 111).

Note: Only the TRIBUT-Learning procedure takes the matrix toll into consideration.

"Conventional" toll assignment TRIBUT

VT is constant for all vehicles. VT is concurrent distributed, which means that each vehicle of the matrix specifies an individual VT for route choice.

monocriterialIn 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.

bicriterialDuring the assignment, both criteria (tR and cR) must always be available for each path.

Table 129: Comparison of conventional toll assignment and TRIBUT

Link outsideof toll area Virtual link with road toll Nodewith number

11

2 32 2

3

2

360 © PTV AG


Illustration 111: Time-cost diagram

• Each point on the diagram, for example A = (tA,cA), corresponds with a route of the sameorigin destination relation.

• A certain time value VT corresponds with a family of parallel straight lines with a negativeslope.

• If two routes lie on one VT straight, they are ”equally good” (for a user with the same VT).This VT is also characterized as a critical VT for two routes.

5.17.3 LogN distribution of the random variable VTThe 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. TRIBUTuses a LogNormal distribution for the random variable VT.

The two distribution parameters apply:

has the following properties:• The probability is equal to zero for negative values.

Route B

costc

time t

cA

tA

Route A

cB

tB

VT = - |cB-cA|/ |tB-tA|

Position parameter, corresponds with the Median of σ Distribution parameter

This parameter corresponds with the standard deviation of the associated standard normal variable.

( )σ,vtNlogVT =

vt ( )σ,vtNlogVT =

( )σ,vtNlogVT =

361 © PTV AG


• The position parameter corresponds with the Median of , which

means that the distribution function adopts the value of 50 % for VT= .

The illustrations show the density function (illustration 112) and the distribution function(illustration 113).

Logarithmic normal distributions

Illustration 112: Density function

Illustration 113: Distribution function

vt( )σ,vtNlogVT =

vt

0,000

0,010

0,020

0,030

0,040

0,050

0,060

0 10 20 30 40 50 60 70 80 90

value of time

g(vo

t)

Density function g1(vot)Density function g2(vot)

0,000

0,200

0,400

0,600

0,800

1,000

1,200

0 10 20 30 40 50 60 70 80 90

value of time

G(v

ot)

Distribution function G1(vot)Distribution function G2(vot)

362 © PTV AG


5.17.4 Route search - efficient frontier as exclusive criterionWhereas 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 theroute search as well as kept in RAM, because the VT which is not unique. Hence, the resultingcomplexity of the route search can, however, be limited with critical values of time (as shownin illustration 114).

Illustration 114: Path Search

illustration 114 shows a route search with six routes. It can be verified graphically oranalytically, 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 lieto the ”right” of this convex front no longer have to be observed, because they cannot beoptimal for any user (for no VT).The relevant routes on the convex front are also designated as set of the efficient routes. Onlythese efficient routes are saved for further search and later distribution.There are two aspects:• For bicriterial procedures you can also discard most alternatives from a multitude of

possible routes, so that the route search can be calculated with the finite time spent andmemory 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 foreach source destination relation.

5.17.5 Route splitThe result of a route search only comprises the efficient routes. Under these, the demand foran OD relation is set. The critical VT are decisive for every neighboring routes on the efficientfront. In the example, there are three critical values of time - A/B, B/C and C/D.

B

c

t

D

C

A

Y

XVTcrit C/D

VTcrit B/C

VTcrit A/B

363 © PTV AG


As illustrated in illustration 115 – the demand shares of the four efficient routes can be derivedfrom the probability distribution of the VT.

Illustration 115: Distribution of the traffic demand onto the routes

5.17.6 Route balancing in the equilibrium iterationSimilar to the equilibrium assignment (see "Equilibrium assignment" on page 301), each newTRIBUT iteration starts with a route search. If new routes are found which fall on the convexfront, they are included in the set of relevant routes. The equilibrium formation is then executedby a coupled demand equalization between the routes (illustration 116). The following stepsare carried out:• Balance between the route of a toll level• Balance between the neighboring toll levels• Constant correction of the course of the convex front and adjustment of the critical values

of time.

0%

50%

100%

P (A)

VTcrit A/B VTcrit B/C VTcrit C/D

P (D)

P (C)

P (B)

Matrix distribution to the found Tribut best routes according to the respective distribution functionInitial solution

Shift of demand between the efficient routes of each OD

Determination of efficient routes for curr. time impedances

End

Found new routes?

Route search

yes

no

Route spl it

364 © PTV AG


Illustration 116: Equilibrium formation with TRIBUT

5.17.7 Route distribution in the iteration of the TRIBUT Equilibrium_LohseThe TRIBUT Equilibrium_Lohse is a modified version of the conventional French procedure,where procedural steps of the Equilibrium_Lohse method are used.Route search is also executed at the beginning of the iteration of the Equilibrium_Lohse (see"Assignment with ICA" on page 332). For all resulting efficient paths, the percentage isdetermined via the critical values of time. All efficient paths are added to the list of best pathsfrom the preceding iterations including their current percentage. For existing paths allpercentages are added.

5.17.8 List outputsVia the menu Lists > Toll, the list types Toll matrices and Toll systems are provided, whichoffer the following attributes for selection:

c

t

C

B

NA

365 © PTV AG


Illustration 117: Attribute selection for the Toll systems list

Illustration 118: Attribute selection for the Toll matrices list

366 © PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

5.18 Dynamic User Equilibrium (DUE)The quantitative analysis of road network traffic performed through static assignment modelsyields 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) areassumed to be constant over time within the reference period. Although static assignmentmodels satisfactorily reproduce congestion effects on traffic flow and cost patterns, they do notallow to represent the variation over time of the demand flows (for example, around the rushhour) and of the network performances (for example in presence of time varying tolls, laneusage, signal plans, link usage permission); Most importantly, they cannot reproduce someimportant dynamic phenomena, such as the formation and dispersion of vehicle queues due tothe temporary over-saturation of link sections, and the spillback, that is queues propagationtowards upstream links. For these use cases, dynamic models are available.

5.18.1 Fields of application of the Dynamic User Equilibrium procedureThe Within-Day Dynamic Traffic Assignment (WDDTA) models are conceived to overcome thelimits of static models. Among them, the Dynamic User Equilibrium (DUE) model embedded inVISUM presents several new and unique features, yielding an algorithm highly efficient both interms 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 ofanalysis (possibly the entire day). It is particularly suitable for the following application fields.• Simulation of heavily congested urban and extra urban networks, where oversaturation

conditions and the back propagations of congestion among adjacent roads are presentover a large part of the network for several hours each day.

• Simulation of networks with transient congestion effects, leading to route choice varyingduring the assignment period.

• Simulation of networks in presence of dynamic management and/or time varying accesspolicies, 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 Equilibriumprocedure implemented in VISUM. However, in order to improve readability, any bibliographicreference is omitted, along with many analytic proofs. For those, and for a deeper insight intothe 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" onpage 715).

5.18.2 Overview of the dynamic equilibrium assignment modelThis model is aimed at solving the Within-Day Dynamic Traffic Assignment (WDDTA) onlink networks addressing explicitly the simulation of queue spillovers. It is based on amacroscopic approach, the Dynamic User Equilibrium (illustration 119).

367 © PTV AG


Illustration 119: The dynamic user equilibrium problem

Apart from the temporal dimension, the main difference between the static and the dynamicuser 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, inthe dynamic case they concern the temporal dimension also. More specifically, for given pathflows, the determination of the arc flows, which in the static case requires only the arc-pathincidence matrix, in the dynamic case involves also the travel times on the network; that is, thenetwork flow propagation model depends also on the path performances (diagonal arrow inillustration 119).The present formulation of the WDDTA has three essential innovations compared to existingWDDTA 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 ofanalysis, based on the temporal profiles of the other variables of the problem, which areassumed to be fixed to their current value; this approach, conceptually depicted on the righthand side of illustration 120, has an iterative nature, since each variable has to berecalculated until a convergence is achieved.

368 © PTV AG


Illustration 120: Time slice approach (left side) and time profile approach (right side) to the Continuous Dynamic Network Loading problem

2. Spill-back can be modeled explicitly simply by switching between two alternative networkperformance models. Without spillback, arc performance (the relationship between arcinflow 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 notexceeded (illustration 121).

Illustration 121: Scheme of the fixed point formulation for the WDDTA with spillback congestion

3. The path choice model can adopt either a deterministic view where only objectively least-cost paths are loaded, or a Probit view where impedances are perturbed stochastically toreflect subjective user perceptions.

This approach presents several advantages.• Consistency between path and link flows (network loading) is achieved in the same

iteration as the equilibration between demand and supply. Nested loops are avoided.• An implicit path approach generates rational path probabilities without the need to

enumerate all paths.• A major advantage of the temporal profile approach, is that the assignment period may be

subdivided into long time intervals (typically 5-15 minutes), instead of a few seconds for the

link flows, travel times, … at time τ0

link flows, travel times, … at time τi

link flows, travel times, … ad time τi+1

link flows, travel times, … ad time τI

link flow tem

poral profiles

link travel time tem

poral profiles

state of the network

period of analysis

state of the networkperiod of analysis

link flows, travel times, … at time τ0

link flows, travel times, … at time τi

link flows, travel times, … ad time τi+1

link flows, travel times, … ad time τI

link flow tem

poral profiles

link travel time tem

poral profiles

state of the network

period of analysis

state of the networkperiod of analysis

network flow propagation model

implicit path enumeration route choice model

demand flows

arc travel times

network loading map

network performance model

arc conditional probabilities

arc costs

arc performance function

arc flows

369 © PTV AG


simulation approaches, saving computation time and memory. This allows overcoming thedifficulty 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 bythe number of (long) time intervals introduced.

For queue spillover modeling, the interaction among the flows on adjacent arcs is propagatedin terms of time-varying arc exit capacities. The approach is then to reproduce the spillbackphenomenon as a hypercritical flow state, either propagating backwards - from the final sectionof an arc - and reaching its initial section, or originating on the latter that reduces the capacitiesof 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 mainvariables underlying the continuous model are introduced, along with some significant resultsof the traffic flow theory underlying the presented model (see "Mathematical framework of theDynamic User Equilibrium" on page 370). Subsequently, the network performance model andits submodels are described (see "Network performance model" on page 374). Then, thedisplay of the network loading map (see "Assignment of the network demand (networkloading)" on page 384) is followed by a description of the overall Dynamic User Equilibriummodel, both for the deterministic and Probit case (see "The overall model" on page 386). Anumeric example including the analysis rounds off the procedure description (see "Example ofthe Dynamic user equilibrium" on page 388).

5.18.3 Mathematical framework of the Dynamic User EquilibriumAs the analysis is carried out within a dynamic context, the model variables are temporalprofiles, here represented as piecewise continuous functions of the time variable t. Users trips on the road network are modeled through a strongly connected oriented graph G =(N, A), where N is the set of the nodes and A Í Ν ´ N is the set of the arcs. Each link, turn, andconnector in the VISUM network corresponds to an arc. Each VISUM network node and zonecorresponds 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)).ExampleFor an arc a representing a link in the VISUM network, TL(a) would correspond to its FromNodeand HD(a) to its ToNode. The forward and backward star of node x∈N are denoted,respectively, FS(x) ={a∈A: x = TL(a)} and BS(y) = {a∈A: y = HD(a)}. The zones constitute asubset Z ⊆ N of nodes. When traveling from a node o∈N to anode d∈Z users consider the set Kod of all the pathsconnecting o and d on G. We are interested in the n:1 many-to-one shortest path problem fromeach node o∈N to a given destination d∈Z. Graph G is assumed to be strongly connected, sothat Kxd with x∈N ≠ d∈Z is non-empty.

Path topology is described through the following set notation: A(k) = concatenated sequence of arcs constituting the path k∈Kod from o∈N to d∈Z.

The following notations are adopted for the network volumes.

370 © PTV AG


The following applies by definition:

(26)For the calculation of network performance, travel times are introduced through inflow-outflowfunctions, and the following notation is adopted.

Due to the presence of time-varying costs, it may be convenient to wait at nodes in order toenter a given arc later. In the following, it is assumed that vehicles are not allowed to wait atnodes, but paths with cycles may result. However, the shortest paths include at most a finitenumber of cycles.Since waiting at nodes is not allowed, the path exit time Tk(τ) is the sum of the travel times ofits arcs A(k), each of them referred to the instant when these vehicles enter the arc whentraveling along the path. Moreover, assuming that path costs are additive with respect to arccosts, 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:

(27)

(28)where a = (o, x)∈A is the first arc of k and h∈Kxd is the rest of path k (illustration 122).

Dod(τ) Vehicle demand, which are moving from origin o∈N to destination dÎΖ and are departing at time t

fa(τ) Vehicle flow, which at time t is traversing arc aÎA

Fa(τ) cumulated vehicle flow, which at time t is traversing arc aÎA

ua(τ) Exit flow from arc a∈A at time t

ca(τ) Cost of traversing arc a∈A for vehicles entering it at time τta(τ) Outflow time of arc a∈A for vehicles entering it at time τ

fa-1(τ) Inflow time of arc a∈A for vehicles exiting it at time τ

Ck(τ) Cost of path k∈Kod from o∈N to d∈Z for vehicles departing from node o at time τ

Tk(τ) Outflow time of path k∈Kod from o∈N to d∈Z for vehicles departing from o at time τ

∫ ∞−= τ σστ d)(a)(a fF

( ) ( )( )ττ athTkT =

( ) ( ) ( )( )τττ athCackC +=

371 © PTV AG


Illustration 122: Recursive expressions of path exit time, entrance time and cost

The strict First In First Out (FIFO) rule holds if the following property is satisfied for each arca∈A:

, for all t‘ > t (29)The monotonicity expressed by (29) ensures that the temporal profiles of the arc exit times areinvertible. Moreover, the FIFO rule applies also to the entrance times.

, for all t‘ > t (30)Any arc a∈A consists of a homogeneous channel with two bottlenecks located at the beginningand at the end. The flow states along the arc are determined on the basis of the SimplifiedTheory of Kinematic Waves (STKW), assuming the concave parabolic-trapezoidalfundamental diagram depicted in illustration 123, expressing the vehicle flow qa(x,τ) at a givensection x of the arc and instant t, as a function of the vehicle density ka(x,τ) at the same sectionand 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

(x, y)∈A(k)

d∈Zo∈N

time

x

y

time

τ Tk(τ) = Th(ta(τ))ta(τ)

h∈Kxd

k∈Kod

Ch(ta(τ))ca(τ)

Ck(τ) = ca(τ) + Ch(ta(τ))

a = (o, x)∈A(k)

(x, y)∈A(k)

d∈Zo∈N

time

x

y

time

τ Tk(τ) = Th(ta(τ))ta(τ)

h∈Kxd

k∈Kod

Ch(ta(τ))ca(τ)

Ck(τ) = ca(τ) + Ch(ta(τ))

a = (o, x)∈A(k)

( ) ( )ττ at'at >

( ) ( )ττ 1xyt'1

xyt −>−

372 © PTV AG


Within this framework, for links the in-capacity corresponds to the physical mid-block capacity,whereas out-capacity reflects the bottleneck capacity imposed by the signal control or priorityrules at the downstream junction. Exit connectors (x, d)∈A: x∈N \ Z, d∈Z are arcs with infinite in-capacity, entry connectors (o, y)∈A: o∈Z, y∈N \ Z are arcs with infinite out-capacity. Turns,however, are represented by arcs having zero length and in-capacity equal to their out-capacity.

Illustration 123: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among vehicular flow, speed and density along a given arc.

In illustration 123, k2a ≥ k1a is assumed, implying the following relation among the aboveparameters:

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, thevehicular flow decreases.

Then, koa(q) and voa(q) express the density and the speed as functions of the flow in presenceof hypercritical flow conditions, while kua(q) and vua(q) express the density and the speed asfunctions of the flow in presence of hypocritical flow conditions. When modeling arcs with low speed limits, i.e. representing urban roads, it may be assumedthat the vehicle speed under hypocritical flow conditions is constant and equal to the speedlimit, until capacity is reached. In this case, the simpler trapezoidal fundamental diagram

Wa propagation speed of hypercritical flow states on arc a, called hypercritical kinematic wave speed.

2 1a a

a a

KJ QV W

⎛ ⎞≥ ⋅ −⎜ ⎟

⎝ ⎠

373 © PTV AG


depicted in illustration 124 may be adopted, where, in order to guarantee k2a ≥ k1a, thefollowing relation must apply:

Illustration 124: The trapezoidal fundamental diagram suggested for urban links

In order to implement the proposed models, the period of analysis [0, Q] is divided into n timeintervals identified by the sequence of instants t = {τ0, … , tι, , tn}, 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 apiecewise linear or a piecewise constant function, defined by the values gi = g(τi) taken at eachinstant τi∈τ. This way, any temporal profile g(τ) can be then represented numerically throughthe vector g = (g0, … , gi, … , gn).

5.18.4 Network performance modelTo represent the spillback phenomenon, we assume that each arc is characterized by twotime-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 ofqueues propagating backwards on the arc itself, which can reach the initial section and canthus induce spillback conditions on the upstream arcs. In this case the entry capacity is set tolimit the current inflow at the value which keeps the number of vehicles on the arc equal to thestorage 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 withthe STKW. Specifically, the space freed by vehicles exiting the arc at the head of the queuetakes some time to become actually available at the tail of the queue, so that the jam densitytimes the length is only the upper bound of the storage capacity, which can be reached only ifthe queue is not moving.The exit capacity, bound from above by the out-capacity, is meant to reproduce the effect ofqueue spillovers propagating backwards from the downstream arcs, which may generate

1 1a a

a a

KJ QV W

⎛ ⎞≥ ⋅ −⎜ ⎟

⎝ ⎠

flow

density

Wa

-Qa / Wa

Va

Qa / Va

k1a KJa

Qa

q

k2a

voa(q)

koa(q)kua(q)

hypocritical flow conditions hypercritical flow conditions

flow

density

Wa

-Qa / Wa

Va

Qa / Va

k1a KJa

Qa

q

k2a

voa(q)

koa(q)kua(q)

hypocritical flow conditions hypercritical flow conditions

374 © PTV AG


hypercritical flow states on the arc itself. For given arc inflows, arc outflows and intersectionpriorities, which are here assumed proportional to the mid-block capacities, the exit capacitiesare 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, namelythe “exit flow and travel time model for time-varying capacities”, the “entry capacity model”, andthe “exit capacity model”, which are solved iteratively. The three models display illustration 125in the context. The journey times which result from the solution of the three feed back modelcomponents, are combined with the monetary costs to generalized costs by an Arc CostModel.

Illustration 125: Scheme of the fixed point formulation for the NPM

Exit flow and travel time models for time-varying exit capacityUnder 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 exitflow is achieved by propagating the inflow temporal profile along the arc and thus calculatingthe corresponding time-series of the travel time. Assuming that the capacity at the end of a given edge a∈A is not reduced due to spillbackeffects, for a vehicle entering the edge at time τ, the hypocritical exit time ra(τ)can beexpressed, dependant of the previous part of the inflow time series, which corresponds to theinflow fa(σ) at any time σ ≤ τ.

(31)Equation (31) is described below.• for the trapezoidal fundamental diagram (see "Hypocritical exit time model for a trapezoidal

fundamental diagram" on page 377) (illustration 124)• for the parabolic fundamental diagram (see "Hypocritical exit time model for a parabolic

fundamental diagram" on page 377) (illustration 123)If, however, at the end of the edge there is a bottleneck with a time-varying capacity ψa(τ) ≤ Safor each time σ, the time series of the cumulative outflow is determined, whose value Ea(τ) attime t is defined as follows.

arc inflowsarc outflows


arc exit flows

exit flow and travel time model

entry capacity model

arc travel times

exit capacity model

arc entry capacities

in- capacities

out-capacities

arc costs

arc cost model

arc exit capacities

arc inflowsarc outflows


arc exit flows

exit flow and travel time model

entry capacity model

arc travel times

exit capacity model

arc entry capacities

in- capacities

out-capacities

arc costs

arc cost model

arc exit capacities

( ) ( )( )τσστ ≤= :afarar

375 © PTV AG


(32)where ψa(τ) denotes the cumulative exit capacity at time t.

(33)This means that ψa(τ) - ψa(σ) vehicles can exit the edge between times σ and τ.

The above expression (32) is based on the following specification of the FIFO rule, stating thatthe cumulative exit time at the exit instant ta(τ) of a vehicle that enters the arc at t is equal tothe cumulative inflow at time t. This means the following:

(34)Then, equation (32) can be explained as follows: If there is no queue at a given time t, the traveltime is equal to the hypocritical travel time, so that, based on the FIFO rule (34), the cumulativeexit flow ra

-1(τ) is equal to the cumulative inflow at time ra-1(τ) when a vehicle that enters the

arc at time is leaving it at t. If a queue develops at time s < t, the exit flow from this point of timeto the time where the queue breaks up, then corresponds to the exit capacity. Based on theFIFO 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:

(35)By definition, ea(τ) ≤ ψa(τ) applies at any time t and hypercritical exit flows occur ιφ ea(τ) = ψa(τ).

Knowing the cumulative inflow and exit flow temporal profiles, the FIFO rule (34) yields animplicit expression for the arc exit time temporal profile.

(36)illustration 126 depicts a graphical interpretation of equation (36), where the time profile of thecumulative 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 thatit goes through the point (σ,Fa[ra

-1(σ)]). This represents the rate of vehicles that can exit thearc following time s. No queue is present when curve a) prevails. Queuing starts, when thecumulative exit flow curve falls below the time-shifted cumulative entry flow curve, thismeans that more vehicles arrive at the final section of the arc than can exit. In the diagram,therefore, the queue arises at time s''. In the illustration 126, the calculation of the exit timebased on the cumulative inflow and exit flow temporal profiles is shown using thick arrows.

( ) ( ) ( ) ( )⎭⎬⎫

⎩⎨⎧ ≤−+⎟

⎠⎞⎜

⎝⎛ −= τσσψτψστ :aa

1araFminaE

( ) ( ) da a

τ

−∞Ψ τ = ψ σ ⋅ σ∫

( )( ) ( )ττ aFataE =

( ) ( ) ττ d/radEae =

( ) ( ) ( ) ( ){ }{ }τσσττ aFaE:min,armaxat ==

376 © PTV AG


Illustration 126: Arc with time-varying capacity

Hypocritical exit time model for a trapezoidal fundamental diagramIf the trapezoidal fundamental diagram is adopted to represent flow states on the arc, thehypocritical speed on the link is constant, and thus equation (27) is simply specified as follows.

(37) In this case, using (37) equation (32) can be made explicit as follows:

(38)

Hypocritical exit time model for a parabolic fundamental diagramIf the parabolic fundamental diagram is adopted, the situation becomes more complicatedbecause vehicles may travel at different speeds even at hypocritical densities. If the arc inflowtemporal profile is piecewise constant, the running link exit time can be determined at leastapproximately from the STKW. The general idea is to trace out the trajectory of a vehicleentering arc a at time t, observing the different speeds it will encounter along the arc, anddetermining its exit time ta(τ). Since it can result in a large computational effort, we then replaceit with a simpler model which averages traffic conditions and thus limits the number of differenttraffic situations encountered by any vehicle on the arc. Readers who would like to get ageneral feel for the model as a whole may just note the general idea and skip to the conclusionof this section. (see "Input and output attributes of the dynamic user equilibrium (DUE)" onpage 390).

( ) aV/aLar += ττ

( ) ( ) ( ) ( ){ }τσσψτψστ ≤−+−= :aaV/aLaFminaE a

377 © PTV AG


Illustration 127: Flow pattern given by the Simplified Theory of Kinematic Waves

Based on the STKW, vehicles change their speeds instantaneously. As depicted inillustration 127, when the inflow temporal profile is piecewise constant, vehicle trajectories arepiecewise linear. Furthermore, the space-time plane comes out to be subdivided into flowregions characterized by homogeneous flow states and delimited by linear shock waves. Theslope Wa

ij of the shockwave separating the two hypocritical flow states Φ(fai) and Φ(faj) is:

(39)In theory, given a piece-wise constant inflow time series, it is possible to determine thetrajectory of a vehicle entering the arc at instant t, and thus its hypocritical exit time ra(τ).illustration 127 shows that it may be extremely cumbersome to determine these trajectories, infact.• Many shockwaves may be active on the arc at the same time. • Shockwaves may be generated either at the initial section by flow discontinuities at times

τi, 0 ≤ i ≤ n-1, or by shockwave intersections on any arc section at any time. • A vehicle may cross many shockwaves while traveling on the arc, and all the crossing

points have to be explicitly evaluated in order to determine its trajectory.In order to overcome these difficulties, as depicted in illustration 128, we assume that at eachinstant ri, 0 ≤ i ≤ n-1, a fictitious shockwave is generated on the initial arc section separating the

( ) ( )( ) ( )

j iij i ja a

a a a a a aj ia a a a

f fW vu f vu f Vku f ku f

−= = + −

−

378 © PTV AG


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.Fictitious shockwaves are very easy to deal with due to the following reasons: • They never meet each other, and thus are all generated on the current initial link section

only at time τi, 0 ≤ i ≤ n-1.• Each vehicle meets at the most the last generated fictitious shockwave, so that its trajectory

is very easy to be determined.

Based on (35), the slope Wai of the fictitious shockwave is as follows:

(40)

Illustration 128: Flow pattern given by the Averaged Kinematic Wave model

Note that the trajectory of a vehicle entering the current link at time τ ∈ (τi-1,τi] is directlyinfluenced only by the mean trajectory of the vehicle entered at time τi-1, which synthesizes theprevious history of flow states on the link. The approximation introduced has little effect on the model efficacy. Moreover, it satisfies theFIFO rule, which is still ensured between the arc initial and final sections, while local violationsthat 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:

,

1( )i i ia a aW vu f V+= + −λ

time

La

τ 0 τ2 τ 3τ 1 τ 4

fa1fa2 fa3 fa4

fictitious shockwavesaverage trajectory of the vehicle entering the running link at time τ i, , 0 ≤ i ≤ n-1

outflow profile

fa5

τ 5

Wa0

Wa1

Wa2

Wa4

Wa3

λ3

λ5

λ0 λ2

λ1

λ0

vua1

vua2

λ1

inflowprofile

λ4

space

( )i i ia a a ar L vu f= τ +

379 © PTV AG


Here, fai is the arc inflow during time interval (τi-1,τi].

b) Otherwise, its hypocritical exit time is determined on the basis of the two speeds itassumes before and after crossing the fictitious shockwave.

,

where ωi is the travel time of the vehicle before it reaches the fictitious shockwave(illustration 129).

.

Illustration 129: Determination of the arc hypocritical exit time

Then, the hypocritical travel time ra(τ) specifying (31) is:

(41)

Entry capacity modelIn this section we propose a new approach to represent the effect on the entry capacity ofqueues 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 thespillback option activated (see User Manual, Chpt. 5.5, page 883). If the option is turned off,the storage capacity of an arc is assumed to be infinite, and the entry capacity of a link is neverreduced below the in-capacity.To help understand let us assume, for the moment, that the queue is uncompressible, thatmeans, only one hypercritical density exists. Then, the kinematic wave speed is infinitive –from either illustration 123 or illustration 124 it is clear that wa = ∞ with KJa = k2a – so that anyhypercritical 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 flowstate until the arc has filled up completely. This means, that the cumulative number of vehiclesthat have entered the arc equals the number of vehicles that have exited the arc plus thestorage capacity. The latter in this case is constant in time and given by the arc length

( ) 1( )i i i i i ia a ar L vu f −= τ + ω + − ω ⋅ λ

1 1 1( ) ( ( ) )i i i i i ia a aW vu f W− − −ω = τ − τ ⋅ −

timeτ i-1W i-1 vu(f a

i)

ω i

space

L

τ i

rai

λ i-1λ i-1

rai-1

timeτ i-1W i-1 vu(f a

i)

ω i

space

L

τ i

rai

λ i-1λ i-1

rai-1

( ) 1ni0,1i,i,i1i/iar

1iar

iiarar −≤≤⎟

⎠⎞

⎢⎣⎡ +∈⎟

⎠⎞⎜

⎝⎛ −+⎟

⎠⎞⎜

⎝⎛ −+•⎟

⎠⎞⎜

⎝⎛ −+= ττττττττ

380 © PTV AG


multiplied by the maximum queue density. As soon as the queue exceeds the arc length, theentry capacity becomes equal to the exit capacity, that means, all vehicles on the arc move asone rigid object.In reality, hypercritical flow states may actually occur at different densities. Their kinematicwave speeds are not only lower than v0, implying that the vehicles will reach the first arcsection with a delay when starting from the final section, but also somewhat different from eachother, which generates a distortion in their forward propagation in time. Notice that thefundamental diagrams adopted here are capable of representing the dominant delay effectsbut 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 ofthe STKW. The flow state occurring on an arc section is the result of the interaction amonghypocritical flow states coming from upstream and hypercritical flow states coming fromdownstream. Specifically, on the initial section, the one flow state coming from upstream is theinflow, while the flow states coming from downstream are due to the exit capacity and can bedetermined by back-propagating the hypercritical portion of the cumulative exit flow temporalprofile, 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 spillbackphenomenon 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 interpretedas an upper bound to the inflow. This enables the determination of the proper value of the entrycapacity that maintains the queue length equal to the arc length.The instant υa(τ) when the backward kinematic wave generated at time τ on the final sectionof arc a∈A by the hypercritical exit flow ea(τ) = ψa(τ) would reach the initial section is given asfollows.

(42)By definition the points in time and space constituting the straight line trajectory produced by akinematic wave are characterized by a same flow state. Moreover, illustration 130 shows thatthe number of vehicles encountered by the hypercritical wave relative to the exit flow q for anyinfinitesimal space ds traveled in the opposite direction is equal to the time interval ds

multiplied by that flow. Therefore, integrating along the arc from the finalto the initial section, we obtain the maximum cumulative flow Ha(τ) that would be observed attime υa(τ) in the initial section as:

Ha(τ) = (43)

( ) ( )( )τττυ aeaw/aLa +=

( ) ( )[ ]qaw/1qav/1 +•

( ) ( ) ( )( ) ( )( )[ ]ττττ aeaw/1aeav/1aLaeaE +••+

381 © PTV AG


Illustration 130: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles

In the fundamental diagrams adopted here, the hypercritical branch is linear and thereforeυa(τ) is invertible. Since wa(q) = wa, the time at υa(τ) = τ is σ = τ - La /wa - based on (42).Furthermore, Ha(τ) = Ea(τ) + La • KJa results -based on (43) q/va(q) = KJa - q/wa. Therefore, themaximum cumulative inflow Ga(τ) that could have entered the arc at time t due to the inflowvolume is given by the following equation:

(44)

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 derivativedGa(τ)/dτ of the latter; otherwise, it is equal to the in-capacity Qa.

Differentiating Ga(τ) implies the following:

= From ea(τ - La /wa) , the following applies:

(45)

illustration 131 shows how, based on equation (44) the time series of the maximum cumulativeinflow can be obtained graphically through a rigid translation (thick arrows) of the cumulativeexit flow time series for La / wa in time and for La • KJa in value. Moreover, it points out that, ifGa(τ) is greater than Fa(τ), the queue is shorter than La and μa(τ) = Qa.

Otherwise spillback occurs and μa(τ) = ψa(τ - La /wa).

space

timewa(q)

ds / wa(q)ds / va(q)

va(q)

ds

kinematic wave

vehicles

space

timewa(q)

ds / wa(q)ds / va(q)

va(q)

ds

kinematic wave

vehicles

Ga τ( )Ea τ

Lawa------–⎝ ⎠

⎛ ⎞ La KJa if ea τLawa------–⎝ ⎠

⎛ ⎞⋅+⋅ Ψa τLawa------–⎝ ⎠

⎛ ⎞=

∞ otherwise⎩⎪⎨⎪⎧

=

( ) ττ d/adG ( )aw/aLae −τ

μa τ( )Ψa τ

Lawa------–⎝ ⎠

⎛ ⎞ if Ga τ( ) Fa τ( )≤⋅

Qa otherwise⎩⎪⎨⎪⎧

=

382 © PTV AG


Illustration 131: Graphical determination of the time series of the inflow capacity in the case of triangular fundamental diagram, piecewise constant inflow, and constant exit capacity

Exit capacity modelIn this section we present a model to determine, for a given node, the exit capacities of theupstream arcs, on the basis of the entry capacities of the downstream arcs and of the turnvolumes. Only two node forms occur in the graph that is formed on the basis of the VISUMnetwork. These are joining links and diverging links. In this case, the model can be describedby the inflows and outflows of edges.When considering joining links x∈N, that is an intersection with a singleton forward edge, theproblem is to split the entry capacity μb(τ) of the edge b = FS(x) available at time t among theedges belonging to its backward edge, whose outflows compete to get through theintersection. In principle, we assume that the available capacity is partitioned proportionally tothe out-capacity Sa of each arc a∈BS(x). But this way it may happen that on some arc a theoutflow μa(τ) is lower than the share of entry capacity assigned to it, so that only a lesserportion of the latter is actually exploited. The rest of the entry capacity is then partitionedamong the other arcs. Moreover, when no spillback phenomenon is active, the exit capacityψa(τ) is set equal to the out-capacity Sa.

La / Va

La / wa

La⋅KJa

hypercritical exit flowspillback

time

time

flow

vehicles

Qa

ψa

inflow Fa(τ), fa(τ)

exit flow Ea(τ), ea(τ)

maximum cumulative inflow Ga(τ)

entry capacity μa(τ)

σ' σ''

La / Va

La / Va

La / wa

La⋅KJa

hypercritical exit flowspillback

time

time

flow

vehicles

Qa

ψa

inflow Fa(τ), fa(τ)

exit flow Ea(τ), ea(τ)

maximum cumulative inflow Ga(τ)

entry capacity μa(τ)

σ' σ''

La / Va

383 © PTV AG


When considering diverging links x∈N , 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 amongthe forward edges. If no arc is spilling back, the exit capacity is set equal to the out-capacity. Ifonly one arc b∈FS(x) is spilling back, that is fb(τ) ≥ μb(τ), then the exit capacity μa(τ) scaled bythe share of vehicles turning on arc b is set equal to the entry capacity of b in order to ensurecapacity 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 b∈FS(x) is spilling back, the exitcapacity is the most penalizing among the above values. On this basis, the following equationis derived:

(46)

Note that, in contrast with the models presented in the previous two sections, this model isspatially non-separable, because the exit capacities of all the arcs belonging to the backwardstar of a same node are determined jointly, and temporally separable, because all relationsrefer to a same instant.It is assumed that vehicles do not occupy the intersection if they cannot cross it due to thepresence of a queue on their successive arc, but wait until the necessary space becomesavailable. Indeed, this model is not capable of addressing the deterioration of performancesdue to a misusage of the intersection capacity.

Arc Cost ModelThe cost for vehicles entering arc a at time t is given as follows:

(47)

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 implicitpath enumeration in the case of deterministic route choice model. To this end, we will firstlydefine and address the continuous dynamic shortest path problem, which lies at the heart ofthe route choice model.

Continuous dynamic shortest path problemContrary to the static case, in the dynamic context the shortest path problem involves explicitlythe time dimension, since the costs of the arcs constituting a path are to be evaluated atdifferent instants, consistently with the travel times experienced along the path, as induced bythe recursive equation (28). Then the minimum cost wo

d(τ) between each node o∈N and agiven destination d∈Z are determined for users departing at time t.

wod(τ) = min{Ck(τ): k ∈ Kod} (48)

It can be proved that the following dynamic version of the Bellman relation for each node o∈N(illustration 132) is equivalent to problem (48).

wod(τ) = min (49)

( ) ( ) ( ) ( ) ( ) ( ) ( ){ }τμττττμτψ bbf,xFSb:bf/aub;aSmina ≥∈•=

( ) ( )( ) ( )τττητ amatac +−•=

{ ( ) ( )( ) } ( ) }oFSx:oxtdxwoxC ∈+ ττ

384 © PTV AG


Illustration 132: Dynamic version of the Bellman relation

The set of Bellman relations (49) can be solved using a dynamic programming approachdescribed below.

Path choice and network flow propagation models Under the assumption that users are perfectly informed rational decision-makers, the resultingbehavior is such that only shortest paths are utilized. The deterministic route choice model forusers that travel between the origin οÎN and the destination δÎZ departing at time t, can then beformulated through the following extension of the dynamic case of Wardrop’s 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 besmaller than the minimum cost.

This can be formally expressed as follows:

(50)Moreover, the choice probabilities must be non-negative and amount to 1.We now develop a formulation based on implicit path enumeration for the route choice modeland for the corresponding network flow propagation model adopting the temporal-layerapproach, where the temporal perspective is the exit time from the current node.If the shortest paths from οÎN to δÎZ for users departing at time t involve more than one arcexiting from an intermediate node x, then the conditional probabilities of these arcs at time t forusers directed to d could depend, in general, on the sub-path utilized from each o to x. Becauseof the additive nature of arc costs, we assume instead that the arc conditional probabilities ateach node are equal for all users directed to the same destination regardless of the sub-pathso far utilized.Under this assumption, the choice probability Pk(τ) of a path k ∈ Kod from o∈N to d∈Z for usersdeparting at time t is equal to the product of the conditional probabilities of its arcs A(k), eachof them referring to the time when these users enter the arc when traveling along the path. Thechoice probability of k can be then retrieved through the following recursive expression:

cox(τ) + wxd(tox(τ))

d∈Z

o∈N

(o, x)∈FS(o)x∈N

τ

tox(τ)cox(τ) + wx

d(tox(τ))

d∈Z

o∈N

(o, x)∈FS(o)x∈N

τ

tox(τ)

( ) ( ) ( ) .0dowkCkP =⎥⎦

⎤⎢⎣⎡ −• τττ

385 © PTV AG


(51)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 arecalculated as follows.

(52)

(53)

(54)Equation (48) states that road users exiting at time t from node o∈N and directed to thedestination d∈Z may choose among the forward star FS(o) only an arc (o, x) for which the costCox(τ) plus the minimum cost wx

d(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 d∈Z 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:

(55)Applying the FIFO and flow conservation rules, the outflow from y at time τ can be expressedin terms of the inflow at a at time tyo

-1(τ).

(56)where the weight dtyo(τ)/dτ stems from the fact that travel times vary over time, so that usersexit from y at a certain rate and, in general, enter in o at a different rate, which is higher thanthe previous one, if the arc travel time is decreasing, and lower, otherwise.The total inflow and outflow of arc (o, x)∈A at time t are then:

(57)

5.18.6 The overall modelAll the components of the dynamic user equilibrium procedure have been introduced. Here weformulate the user equilibrium, where no user can reduce his perceived travel cost byunilaterally changing paths, described as a fixed point problem in the temporal profiles of thearc inflows and outflows.

( ) ( ) ( )( )τττ oxthPdoxpkP •=

( ) ( ) ( )( ) ( ) 0dowoxtd

xwoxCdoxp =⎥⎦

⎤⎢⎣⎡ −+• ττττ

( ) ( ) ( ) 1doxpoFSx,o =∈∑ τ

( ) 0doxp ≥τ

( ) ( ) ( ) ( ) ( ) ( )⎥⎦⎤

⎢⎣⎡

∈∑+•= ττττ dyouoBSo,yodDd

oxpdoxf

( ) ( ) ( ) ( )[ ]ττττ d/yodt/1yotd

yofdyou −=

( ) ( ) ( ) ( )ττττ doxZdox

doxZd uu;foxf

∈∈ ∑=∑=

386 © PTV AG


The deterministic caseThe formulation of the implicit path enumeration yields the model depicted in illustration 133.

Illustration 133: Variables and models of the fixed point formulations for the network performance model (left hand side) and for the dynamic assignment with spillback (right hand side)

In analogy with the static case, the Network Loading Map (NLM) is a functional relationyielding, for given demand flows D, an arc flow pattern f consistent with the arc performancest, and c, through the deterministic route choice model p(w(c, t), t, c), and the network flowpropagation model ω(p, t; D). The assignment uses an implicit path enumeration and is basedon the minimum costs w from each node to destination, as well as on the resulting conditionalprobabilities p of the edges. In turn, the arc performance model yields the arc exit time patternt, and the arc cost pattern c, consistent with the arc inflows f and arc outflows u. Thedeterministic equilibrium results from the feedback of network loading map and arcperformance model.


p(w, c, t)D

(p, t ; D)

c(t)

f, u t c

w

w(c, t)

network loading map

ψ*( f, u)

ψ

E( f, ψ)

E

t( f, u, E)

μ

μ( f, E, ψ; Q)

ψ

ψ(f, u, μ; S)


Q

S

f, u

E

E( f, ψ)

p


p(w, c, t)D

(p, t ; D)

c(t)

f, u t c

w

w(c, t)

network loading map

ψ*( f, u)

ψ

E( f, ψ)

E

t( f, u, E)

μ

μ( f, E, ψ; Q)

ψ

ψ(f, u, μ; S)


Q

S

f, u

E

E( f, ψ)

p

ϖ

387 © PTV AG


The Probit caseIn the Probit route choice model, which is based on the random utility theory, the arc costsperceived by users are not known with certainty and are thus regarded as independent randomvariables. We extend the Probit model to the dynamic case assuming that the arc cost ĉa(τ) ofarc a∈A perceived by users at time t is equal to the sum of the arc cost ca(τ) yielded by the arcperformance model and of a time-varying random error, whose value at time t is distributed asa normal variable. Its variance is assumed proportional to a time-varying cost term χa(τ) > 0and independent of the load case. The arc flow pattern resulting from the evaluation of the Probit NLM for given arc performancesis obtained through the well-known Montecarlo method as follows: 1. Get a sample of Η perceived arc cost patterns:

Applies in compact form

(58)where each ψa(τ) is extracted from a standard normal variable N[0.1] and h = 1, … , H..

2. For each perceived arc cost pattern of the sample, determine with the deterministic NLM aconsistent arc inflow pattern.

3. Calculate the mean of the resulting deterministic arc inflow patterns, thus obtaining anundistorted estimation of the Probit arc inflow pattern.

Note that, based on equation (58), the entire time series is disturbed by just onerandom number. This means, that the error of estimation of road users does not depend on thetime of day. This is consistent with the behavior of users, who perceive the arc cost temporalprofile 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 equilibriumIn order to investigate the behavior of the proposed model and to show the effect of spillbackon path choice, we analyze a simple example which presents intuitive solutions. It is located inthe folder Examples\DUE of your VISUM installation as Braess_without_spillback.veR andbraess_with_spillback.ver. We consider the Braess network depicted in illustration 134. Links have the characteristicsreported in the corresponding table, and are all modeled with a parabolic-trapezoidalfundamental 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.

( ) ( ) ( )[ ] 5.0a

haach

ac τχζψττ ••+=

( )χ;cchc =

( )τhc a

Link La[km] Qa [veh/h] Va [km/h] Wa [km/h] 1 / Ka[m]

A 0.4 2000 50 15 7.0

B 0.6 2000 50 15 7.0

C 0.6 2000 50 15 7.0

388 © PTV AG


The assignment period is constituted by 100 intervals of 1 minute. We assume a constantdemand for the first 33 minutes of simulation from node 1 to node 5 equal to D15 = 2,300 veh/h.


The outputs of two assignment runs, one without and the other with spillback congestion, arepresented in illustration 135. Without spillback, the congestion is evenly located only on turnsCF and DF (which can be gathered observing turn travel times), so that on all the pathsbetween node 1 and node 5 the queue is about equal, and path A-E-D-F has fewer users sinceit is clearly not convenient. With spillback, however, the queue propagates from turn CF to arcC and up to arc A, and from turn DF to arc D and up to arcs B and E. Moreover, the spillbackeffect is greater on arc B than on arc E because of the different capacities of turn ED and turnBD. Then, after an initial growth, the travel time on arc D remains constant, since congestion ispropagated 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 traveltime. That is why the flow on arc E increases from around 150 veh/h to 670 veh/happroximately.

D 0.4 2000 50 15 7.0

E 0.4 2000 50 15 7.0

F 0.1 4000 50 15 3.5

Link La[km] Qa [veh/h] Va [km/h] Wa [km/h] 1 / Ka[m]

4

A

DB

C

1

2

3

E5

F4

A

DB

C

1

2

3

E5

F

DUE without spillback - inflow [veh/h]

0

500

1000

1500

2000

0 500 1000 1500 2000 2500 3000 3500

arc A

arc B

arc C

arc D

arc E

arc A

arc B

arc C

arc D

arc E

389 © PTV AG


Illustration 135: Results of WDDTA without and with spillback

5.18.8 Input and output attributes of the dynamic user equilibrium (DUE)This method computes an equilibrium assignment over a given assignment period, given bothtime-varying demand and time-varying supply.

Input – SupplyThe available network is defined as usual by nodes, links, turns, zones, and connectors(optionally also main nodes and main turns). The attributes listed in Table 130 are relevant forDUE.

DUE with spillback - inflow [veh/h]

0

500

1000

1500

2000

0 500 1000 1500 2000 2500 3000 3500

arc A

arc B

arc C

arc D

arc E

arc A

arc B

arc C

arc D

arc E

DUE without spillback – travel time [sec]

0

50

100

150

200

250

300

0 500 1000 1500 2000 2500 3000 3500

turn AC

turn BD

turn CF

turn DE

turn ED

turn AC

turn BD

turn CF

turn DE

turn ED

DUE with spillback – travel time [sec]

0

50

100

150

200

250

300

0 500 1000 1500 2000 2500 3000 3500

arc A

arc B

arc C

arc D

arc E

390 © PTV AG


• *) MPA – only: affecting each OD pairSome of the attribute can be temporarily restricted. These attributes will then have a defaultvalue, 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 otherassignment methods.Impedances are handled in a special way in DUE (see "Network performance model" onpage 374). In particular, link travel time is the sum of t0 with free flow and a wait time at thebottleneck which is assumed to be located at the end of the link. The free-running travel timet0 depends on a flow-density fundamental diagram. The fundamental diagram can have one oftwo different shapes which differ in the sub-critical branch, this means, where density is lessthan the critical density (at which maximum flow is reached). The shape is defined by the linkattribute DueFunDiag. In the case of urban links, a trapezium shaped fundamental diagram is recommended. In thistype of diagram, the hypocritical branch is linear, which means that vehicles travel at free-flow

Network object Attribute Optionally time-varying

Comment

Link TSysSet J

Length N

v0 PrT J

Capacity PrT J in [veh/h]

Toll PrTSys J

DueVWave N See below for explanation of link impedanceDueFunDiag N

SpacePerPCU N

LinkSpacePerPCU N

Link type vMax PrTSys N Maximum speed per transport system on any link of this type

Turns TSysSet J

t0 PrT J

Capacity PrT J in [veh/h]

Main turns TSysSet N

t0 PrT N

Capacity PrT N in [veh/h]

Zones SharePrTOrig/Dest*) N Do connectors have shares{Yes/No}

Connectors t0_TSys N

Weight*) N Connector share, if enabled for zone

Table 130: Input attributes for the DUE procedure

391 © PTV AG


speed v0 (on the free-running part) until capacity is reached. illustration 136 illustrates how theshape of the diagram is determined by the link attributes.

Illustration 136: Shape of the fundamental diagram based on the link attributes

Notice that the jam density is the maximum number of vehicles per 1 km of link length. For asingle-lane link a typical value for SpacePerPCU would be around 7 m, resulting in a jamdensity of ~140 vehicles / km.In order for the fundamental diagram to be well-defined, the sub-critical and hyper-criticalbranches 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 anapproach similar to volume-delay functions appears more suitable.In this type of diagram, the sub-critical branch is parabolic (illustration 137), speed decreasesfrom v0 at free flow to 0.5 • v0 at capacity and the flow-density curve reaches capacity with zeroderivative. The validity condition for the attributes then becomesCapacity PrT • (2 / v0 + 1 / DUEvWAVE) ≤ 1.000 / LinkSpacePerPCU.

All other properties are identical to the sub-critical linear case.

DUE fundamental diagram

0

500

1000

1500

2000

2500

0 20 40 60 80 100 120 140 160

Density [veh/km]

Flow

[veh

/h]

sub-criticalhyper-critical

CapacityPrT

- DUEvWave

jam density = 1000 / SpacePerPCU

v0

392 © PTV AG


Illustration 137: Parabolic sub-critical branch in the fundamental diagram

The wait time at the end of the link is a function of the bottleneck capacity. This is defined foreach turn by turn attribute Capacity PrT. To work correctly with DUE, turn capacities shouldbe 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 ofa signalized intersection, or by some suitable multiplier in case of non-prioritized approachat a non-signalized intersection;

• Then, determine each turn capacity as the sum of the capacities of lanes allowed for thecorresponding maneuver.

Note: In case of lanes allowed for more than one maneuver, the corresponding lane capacityis not to be split among the corresponding turns, but is to be entirely assigned to each turncorresponding to the allowed maneuvers. In this case in fact, DUE will, based on the turnflows resulting from WDDTA, internally identify the actual capacity to be assigned to eachturn.

DUE fundamental diagram

0

500

1000

1500

2000

2500

0 20 40 60 80 100 120 140 160

Density [veh/km]

Flow

[veh

/h]

sub-criticalhyper-critical

CapacityPrT

v0

- DUEvWave

zero derivative

jam density = 1000 / SpacePerPCU

v0/2

393 © PTV AG


Example

Illustration 138: Signalized intersection in reality

The signalized intersection in illustration 138, with lane capacities = 1800 veh/h, signal cycle =90 s and green fractions depicted the in VISUM should be implemented in illustration 139 as infigure below. The turns approaching from the West have the following capacities:• turn 1 (1 lane allowed): Q1 = 1800 • 30 / 90 = 600 veh/h• turn 2 (2 lanes allowed): Q2 = 1800 • 45 / 90 + 1800 • 45 / 90 = 1800 veh/h• turn 3 (1 lane allowed): Q3 = 1800 • 45 / 90 = 900 veh/h

Whereas the capacity of the right lane, which can be used to go either straight or right, is addedboth to the straight turn capacity and to the right turn capacity.

Illustration 139: Diagram of the signalized node in VISUM

Wait time for a turn is the sum of t0 and a variable part based on volume and Capacity-PrT.

Input – DemandDUE accepts a description of time-varying demand. Like elsewhere in VISUM, this descriptioncan take two possible forms:

• Total demand matrix with a demand time profile which assigns percentage shares ofthe total matrix to time intervals.

• A demand time profile in which each time interval refers to a separate demand matrix.

Note: Note that if you declare turn Capacity-PrT time-varying, you can model the effects ofdifferent green time splits depending on the time of day.

80 m

g = 30 s

g = 45 s

g = 45 s

80 m

g = 30 s

g = 45 s

g = 45 s

Q1 Q2

Q3 links

turns

394 © PTV AG


If a calendar has been set, it is ignored. Make sure that the demand profile is defined for day 1of the calendar period.DUE is a multi-class assignment method, this means, multiple demand segments, each with itsown demand description, can be assigned in a single run.

Overview of all input attributesIn a overview Table 131 shows all relevant input attributes for DUE .

Table 131: Example of the Dynamic user equilibrium


Output attributes of the Dynamic user equilibriumThe results of the operation are available through link, turn, main turn and connector attributesfor volume and impedance. In particular, volumes are available as totals or by demandsegment or transport system, and in vehicles, PCU, or persons. Both volumes and impedancesare given by analysis time interval.

x2 Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure parameters) to have an effect

x3 Optionally time-varying

395 © PTV AG


The definition of queue lengths as a measure of oversaturation is not easily defined, as in theDUE model queues may move and only gradually approach the situation where traffic is at astandstill at queue density. Because queues move (at a speed depending on the hyper-criticalbranch of the fundamental diagram), and separation between vehicles (density) is notconstant, it would furthermore be misleading to speak of queue length in meters. Therefore weadopt a definition which is similar to “congestion hits” in more microscopic simulations. Thevalue of the queue length (for a given link and time interval) is the number of vehiclesexperiencing hyper-critical delay, i.e. spend more time on the link than the free-running linktravel time resulting from v0 plus the sub-critical wait time at the bottleneck (e.g. waiting for thenext green time in the cycle).Table 132 gives an overview of all DUE output attributes.

Table 132: Output attributes of the Dynamic user equilibrium


5.19 Dynamic stochastic assignmentThe dynamic stochastic assignment differs from all other PrT assignment procedures as aresult of the explicit modeling of the time required to complete trips in the network. For dynamicstochastic assignment - capacity has to be set as an hourly value - not regarding the length ofthe time interval the demand is available for.• The dynamic stochastic assignment takes time-varying attributes of traversed links, turns,

main turns and connectors into account (t0, tCur, VolCapRatio per time interval, thatresult from their temporary attributes, for example, capacity and v0 or t0).

• The dynamic stochastic assignment provides the calculated results, for example volume orimpedance of the connections (routes in time interval) and of their traversed network

x1 Totals for assignment period and values per time interval

396 © PTV AG

Chapter 5.19: Dynamic stochastic assignment

objects, which means links, turns, main turns and connectors, for each user-defined timeinterval. Since the impedance equals the congested travel time in most applications, timeprofiles for the assignment period can be generated this way. For the routes, tolls andAddValues are additionally issued for each time interval.

In contrast, all trips are completed in the case of static assignment procedures with noindication of the time required, capacities have to be specified according to the length of thetime interval demand data is available for, and the volumes of all trips and the resultantimpedances are superimposed upon each other at the individual network objects. Road-userssubsequently only have to choose from a number of different routes for each journey. Thedeparture time is irrelevant.In the case of the dynamic assignment on the other hand, an assignment period T (e.g. 24hours) is specified and divided up into time slices Ti of equal length (e.g. 15 minutes). Only thesearch for (alternative) routes for each journey is made with no reference to a specific time. Asin the case of the static stochastic assignment, several shortest path searches are completedwith network impedances that vary at random. All other operations explicitly include a timedimension. As for the stochastic assignment, further random searches may be carried out (seeUser Manual, Chpt. 5.6.9.2, page 928).From the entire demand and its temporal distribution curve, the portion with a desireddeparture 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 PuTassignment terminology, are also called connections. The impedance of a connection iscomposed of its network impedance and the difference between the actual and desireddeparture time slice (temporal utility). To determine the network impedance, the volume andthe capacity-dependent travel time for each network element are stored separately for everytime 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 networkelement is traversed is relevant.The following illustration 140 shows qualitatively the procedure for calculating the impedancesalong the time-path line of the connection.In this case, S (= faSt) and L (= sLow) represent the capacity-dependent speed of the networkelement in the relevant time slice. The correct path of the trip – and thus the correct networkimpedance of the connection – results only when the travel time on each link (B in particular inthis case) is included with respect to the time slice reached at this moment.

397 © PTV AG


Illustration 140: Example of the impedance calculation of a connection

After assignment to individual connections, the network elements are loaded with the demandfor each time slice as in the case of the impedance calculation, which results in new networkelement impedances. It is assumed that the departure times of the individual trips are equallydistributed within the time slice, this means, instead of a single time-path line, a volume rangeis decremented (Example illustration 141).

Illustration 141: Example of the network volume along a connection

Links

Time

A

S

C D

2

3

4

1

SSL

SSSS

SSSS

B

0 SS S

A

S

C D

2

3

4

1

SSL

SSS

SSSS

B

0 S S

Actual path

Travel times on reaching specific link

Travel times at departure time

398 © PTV AG


5.19.1 Evaluation of the Dynamic stochastic assignmentThe dynamic assignment permits the analysis of the analysis of temporary overload effects inthe network. Depending on the time-dependent capacity, not only are different routes chosenat different times, but if necessary the actual departure time is shifted with respect to thedesired departure time. The procedure is therefore ideal for calculating distribution curves ofthe volume on network objects.On the other hand, the use of the procedure requires a temporal layering of the demand usinga 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. TheTable 133 gives an overview of which input attributes have to be maintained. After calculation,the results are available in the output attributes and can be displayed in the list view (see UserManual, Chpt. 12.1, page 1227) or in the network editor (see User Manual, Chpt. 12.2,page 1253) . Table 134 lists the output attributes which store the results of the procedure.

Table 133: Input attributes of the dynamic stochastic assignment

399 © PTV AG


Table 134: Output attributes of the dynamic stochastic assignment


5.19.3 Procedure of the dynamic stochastic assignmentThe procedure in illustration 142 keeps to the sequence of the static stochastic iteration anddiffers essentially in the use of substeps on connections instead of on routes. It is broken downinto an external iteration for the connection search and an internal iteration for the connectionchoice and network loading.

x1 Totals for assignment period and values per time intervalx2 Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure

parameters) to have an effectx3 Optionally time-varying0 Generally possible, however not recommended(X) Can be used optionally(*) Apart from the parameters which are directly set in the assignment procedure

400 © PTV AG


n = 0Start of external iteration

Calculate impedance R in unloaded network for all network objects.

For each time slice Ti selected in the procedureparameters:Calculate one route per OD pair using a shortest pathsearch with Rn,Ti. Find more routes by varying Rn,Tiaccording to a normal distribution with pre-definedvariance.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.

Calculate independence factor (commonality factor) thattakes into account the relative similarity of the routes(basis: impedances in the unloaded network) or theindependence (Ben Akiva)

Number of new routes > 0

Delete all connections with R > a • R*min + b and t0 > c • t0,min + d

Counter for external iteration

Connection search

Connection preselection

Independence

no

Search impedance

n = n + 1


yes

m = 0Start of internal iterartion

Set impedance R and R* of all network objects in all time slices to impedance in the unloaded network.

Initialisation of choice

impedance

stop

401 © PTV AG


Illustration 142: Procedure of the dynamic stochastic assignment

5.20 NCHRP 255This postprocessor for PrT assignments is an Add-on module used to correct assignmentvolumes on links and turns of the forecast by means of a correction factor, which is calculatedon the basis of the differences between traffic counts and an assignment, both representing thesame time slice, as is described in Report 255 (National Cooperative Highway ResearchProgram).The procedure comprises the following steps:1. The count values of the incoming link at the node result from totaling the turn count values

for the corresponding From Link.

Calculate R* of all connections as total R* for all traversednetwork objects in each time slice affected. Increaseimpedance using deviation from desired departure t ime slice and correct using impedance factor.

Calculate R* for all network objects in all time slices fromthe volumes that result from the connection choice. The search impedance is an estimated R* value that iscalculated as in the learning procedure:

m = max. number of internal iterations or

is valid for the impedance of all network elements in all t ime slices, and

is valid for the volume of all connections

Counter for internal iteration

Choice impedance

Route volume

Update search impedance

no

m = m + 1

Termination criterion for

internal iteration

yes

Assignment of demand across connections in accordancewith Logit, Box-Cox, Kirchhoff, Lohse or Lohse withvariable beta results in connection volumes qrm*

Connection choice

n = max. number of external iteration


no

yesstop

mqmq

q rmmrrm

')1()1( +−⋅= −

( )*oldnew

*ld

*new RRRR o −×Δ+=

),),max(min( 32*

1*

1*

1* EERRERR mmmm +⋅≤− −−

),),max(min( 65)1(4)1( EEqqEqq mrrmmrrm +⋅≤− −−

402 © PTV AG

Chapter 5.21: Assignment analysis PrT

2. Calculate the difference between the link base count (as input by the user) and the value ofthe link base assignment value.

3. Calculate the adjusted link volumes as the future link assigned value + the adjustmentfactor.

4. Furness (balance) the new link adjusted volumes to match the counted turn volumes. Theresult 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 PrTAssignment analysis is used for calculating the correlation (Goodness-of-Fit Report) betweencalculated 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 speedsAny 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• PathsPrerequisite 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 threepossibilities:• All objects of the selected network object type • Only active objects • Only objects with observed value > 0For the assignment analysis, as an option, you can consider user-defined tolerances for user-defined value ranges of the calculated attribute.The quality of the correlation can be determined and issued in two ways:• in groups (for each value of the classification attribute)

403 © PTV AG


• collectively for all included network objectsFor the output, the data model of the network object types above has been supplemented withthe calculated attribute Assignment deviation (AssignDev) of type real. Alike all otherVISUM attributes, the attribute can be graphically displayed and issued in lists of the respectivenetwork object.In addition, VISUM calculates various indicators (per group or collectively) that can be issuedin a list or in a chart.

Table 135 shows the calculation rules for the output attributes of the assignment analysis. Tothe formulas applies:

Note: An assignment result is no longer necessary in order to calculate the correlationcoefficient.

Z Observed value (counts or measures)

U Calculated value (assignment or network model)

N Number of objects with observed value > 0

AbsRMSEAbs RMSE

Absolute root of mean square deviationSignificant differences between counted and modeled values have a higher impact according to

InterceptIntercept

Coefficient b in linear regression Cf. Excel function: Linear Regression (y = ax + b)

ShareAccGEHPercent with acc GEH

Percentage objects with acceptable GEH value (per network object)

ShareAccRelErrPercent with avg rel error

Percentage objects within tolerance

NumObsNumber observations

Number of observations per class (objects with observed value > 0)

NumClassNumber in class

Total number (=observed + not observed) objects per class

ClassValue Value of classification attribute (or blank, if not classified)

Table 135: Calculation rules for the output attributes of the assignment analysis

( ) ( ) 21N

1iN2

iUiZ⎥⎥⎦

⎤

⎢⎢⎣

⎡

=−= ∑ϑ

( ) ( )( ) 2iUiZ

2iUiZ

iGEH+

−=

abs Zi Ui–( )Ui

------------------------------ Tolerancz U( )≤

404 © PTV AG

Chapter 5.21: Assignment analysis PrT

Corr Correlation coefficient (cf. Excel function Pearson)NotesThe value range lies between -1 and 1, where the following applies:• -1 = observation opposed to modeling• 0 = no correlation (at random)• +1 = very good correlationThe observed/modeled value ratio should be as close to 1 as possible.If only 2 values > 0 are used, the correlation coefficient is -1 or 1.From the value of the correlation coefficient, one cannot determine whether all observed values are higher (or lower) than the calculated values or upward and downward deviations exist.

MeanAbsE Mean absolute errorMean deviation of absolute values (δa) (Difference between observed and modeled values)

MeanObs

Mean observed value

AvgRelErr Mean relative errorMean deviation of absolute values in % (δp) according to

R2 Coefficient of determination r2 Cf. Excel function RSQ

RelRMSE Relative root of mean square deviation

StdDev Standard deviation

Slope Coefficient a in linear regression Cf. Excel, Linear Regression (y = ax + b)


( ) ( )∑ −⋅= iUiZAbsN1

aδ

∑⋅ iZN1

( ) ( )∑

∑ −=

iZiUiZAbs

pδ

( )( )

∑

∑−

−

NiZ1N

2iUiZ

405 © PTV AG


406 © PTV AG

6 User Model PuT

The PuT User Model calculates the effect of PuT supply on PuT passengers.

Subjects• Overview of PuT assignment procedures• Example network for the PuT assignment procedures• PuT paths• PuT skims• PuT impedance functions• Distribution of the travel demand to PuT connectors• Allocation of skims with reference to lines/links• Transport system-based assignment• Headway-based assignment• Timetable-based assignment• Assignment analysis PuT• PuT Passenger surveys

6.1 Overview of PuT assignment proceduresTo model PuT trips, VISUM provides three types of PuT assignment procedures which differ inrequired input data, accuracy of results, and computing time.• The transport system-based procedure, which is based on a PuT-specific "all or nothing"

assignment, provides an overview of the transport demand structure. This procedure doesnot require a line network (see "Transport system-based assignment" on page 428). Forrough-cut planning purposes it helps to determine the "ideal line network" where eachpassenger chooses the fastest route in the network without any restrictions caused by PuTline routes or timetables.

• The headway-based procedure is ideal for urban networks with short headways and forlong-term conceptual planning, as long as the timetable for the period being analyzed is stillunknown. The headway-based procedure determines the transfer wait time at transferstops from the mean headway of the succeeding lines. If necessary, co-ordination in thecase of transfers between lines and also between the timetables of multiple lines are takeninto consideration on sections with shared services, and then specified deviating transferwait times are valid. Doing without the timetable on the level of individual trips ensures shortcomputing times even for large networks (see "Headway-based assignment" on page 430).

• The timetable-based procedure should be used if the PuT supply has long headwaysand coordination of the timetable is important for transfers. It takes the accurate timetableinto 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 theconnection search procedure (see "Timetable-based assignment" on page 452).

407 © PTV AG

Chapter 6: User Model PuT

In large networks, a distinction can often be made between a main network, which is the mostimportant one to be analyzed, and a subordinated network, which provides feeder functions forthe main network. Examples for this are national rail networks with subordinated regional orurban bus networks, which also include cars or taxis for access and egress. For modeling thesubordinated 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 requiredto estimate the route choice in the subordinated network accurately when selecting andsetting attributes for the connectors. The route choice can also change in the case ofsupply changes in the main network.

• With regard to modeling accuracy, it is instead recommended to also model thesubordinated network as a PuT supply. In addition to the considerable effort required toobtain the timetable data, memory requirements and computing time for the assignmentare also greater. Especially in the case of short headways in the subordinated network, thenumber of connections explodes.

A compromise solution involves modeling the entire main network and performing either aheadway or a timetable-based assignment. The subordinated PuT supply in comparison isonly modeled as a used link network and in the course of the either headway or timetable-based assignment it is treated as in the transport system-based procedure (best path search,see illustration 143).

Illustration 143: Different modeling options for main and subordinated networks

For this kind of modeling, the used links and turns in the subordinated network are opened fortransport systems of the special PuTAux type and provided with specific run times for theseconnections. If PuT auxiliary transport systems are not available for all demand segments (forexample 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 transportsystem P+R, but the demand segment Employed without car does not.The PuT assignment procedures are mainly used for the following applications.• To determine volumes, for example line volumes, link volumes, and the number of

passengers who board, transfer or alight at stops.• To calculate passenger-specific PuT skims, for example journey time, number of transfers,

service frequency.• As a timetable information system which provides information on the departure and arrival

times of individual connections.

SS

PuT with timetable

PuT w/o timetable

408 © PTV AG

Chapter 6.2: Example network for the PuT assignment procedures

6.2 Example network for the PuT assignment proceduresThe different procedures are described below using an example (illustration 144,illustration 145, illustration 146, Table 136 and Table 137). The connections between A-Villageand X-City are to be determined from 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:30a.m. (Tables $TIMESERIES and $TIMESERIESITEM in demand data file PuT.dmd).

The Table 136 contains example data of the PuT.dmd file which is provided in English.

409 © PTV AG


The example network VISUM115 can be found in the directory ...\\Examples\Example_net.• Version file: Example.ver• Graphic parameters PuT.gpa• OD matrix and demand distribution PuT.dmd• Procedure parameters PuT.par

$VISION* VisumInst (2010-03-15)* 04/11/07* * Table: VERSION$VERSION:VERSNR;FILETYPE;LANGUAGE;UNIT4,000;Demand;ENG;KM

* Table: ODMATRIX$ODMATRIX:NO;CODE;NAME;CONTENT;ROUND;NUMDECPLACES1;C;Car;;0;02;H;HVeh;;0;03;P;PuT;;0;0

* Table: MATRIXSINGLELISTITEM $MATRIXSINGLELISTITEM:MATRIXNO;FROMZONENO;TOZONENO;VALUE1;100;200;2000.0002;100;200;200.0003;100;200;90.000

* Table: TIMESERIESDOMAINTYPE$TIMESERIESDOMAINTYPE:NO;DESCRIPTION;UNITYSTRING;NUMDECPLACES;MAXVALUE;MIN-VALUE1;Time series by percentages;%;2;9999999999.000;0.0002;Time series of matrix numbers;No;0;999999999.000;0.000

* Table: Time series$TIMESERIES:NO;NAME;TYPENO;UNITX;NUMINTERVALS;LENGTHINTERVAL;USEVALUE-LIST;VALUELISTTYPE; VALUEREFTYPE;DECSEPARATOR;VALUESEPARATOR1;;1;;86400;1;0;0;2;;

* Table: Time series items$TIMESERIESITEM:TIMESERIESNO;STARTINTERVALINDEX;ENDINTERVALINDEX;VALUE1;1;19800;0.0001;19801;23400;33.0001;23401;27000;67.000

* Table: Demand time series$DEMANDTIMESERIES:NO;CODE;NAME;TIMESERIESNO1;;;1

* Table: Demand descriptions$DEMANDDESCRIPTION:DSEGCODE;DEMANDTIMESERIESNO;MATRIXNO;STARTDAYINDEX;START-TIMEC;0;1;1;12:00 AM:00H;0;2;1;12:00 AM:00P;1;3;1;12:00 AM:00

Table 136: Demand matrix and temporal distribution of demand for the example

410 © PTV AG

Chapter 6.2: Example network for the PuT assignment procedures

Illustration 144: Timetable

Illustration 145: Line map

Timetable Bus 1 Timetable Train

A-Village 6:10 6:55 7:25 Station 6:25 7:05 7:45

Station 6:22 7:07 7:37 X-City 6:41 7:21 8:01

B-Village 6:42 7:27 7:57

X-City 6:55 7:40 8:10

Connections

Departure 6:10 a.m., Arrival 6:55 a.m., ride time 45 min., 0 × transfer





Table 137: PuT supply of the example with connections from A-Village to X-City

6.00

6.30

7.00

7.30

8.00

Origin Destination

Bus 1

Bus 1

Bus 1

Station

TrainTrain

TrainTrain

TrainTrain

A-Village X-CityB-Village

X-City (destination)

A-Village (Origin)

Station

Bus 1

Train

B-Village

411 © PTV AG


6.3 PuT pathsPaths are the central result of an assignment (see "Paths in PrT and PuT" on page 192). In thetimetable-based assignment (see "Timetable-based assignment" on page 452) a PuT path isdescribed through a sequence of path legs which each represent one of the following activities.• Change of location from one stop point to another by using a specific service trip• Change of location from origin zone via a connector and links to a stop point or from there

to destination zone with a PuT-Walk TSys• Transition from one stop point to another with a PuT-Walk TSys• Change of location by using a PuT-Aux TSysBecause each of the used service trips is known, the path has a time reference (see "Networkobjects of the line hierarchy" on page 46). Each of its path legs starts and ends at a precisetime. This is called a connection.If the option Save paths – as connections has been selected for the assignment (see UserManual, Chpt. 6.1.1.2, page 944), these connections become visible in the PuT path leg list(see User Manual, Chpt. 12.1.10, page 1249).Alternatively, a path can be described without specifying service trips in detail. In this case onlythe time profile is known, which was used for a change of location via a PuT line (see "Networkobjects of the line hierarchy" on page 46). The departure and arrival times of each path leg arethen relative times relating to the beginning of the path, completely analog to the differencebetween service trip and time profile. Such a path described by the used time profiles andrelative times is called a route.Naturally, routes are suitable especially to aggregate display of recurring connections atregular 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 (seeUser Manual, Chpt. 6.1.1.2, page 944), individual connections are still determined and loadedinternally. 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. ThePuT path leg list then shows the relative times for departure and arrival, and the optionalrelations to the first and after the last vehicle journey item are empty. Because the networkelements are loaded prior to discarding the connections, time-based volumes can still bedetermined.The third option Save paths – do not save (see User Manual, Chpt. 6.1.1.2, page 944) resultsin that no path information is saved after ending the assignment. Only the derived values of thenetwork 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 arealso possible with this option.Due to its differing user model, headway-based assignment (see "Headway-basedassignment" on page 430) not even internally determines connections but routes. The optionSave paths as connections can be selected, however, but at headway-based assignmentroutes are saved in either case (or nothing). These are formally equal to those routesdetermined by the timetable-based assignment and can be output in the same way as PuTpath list or PuT path leg list.

412 © PTV AG

Chapter 6.3: PuT paths

Table 138 shows the path legs which result from a timetable-based assignment in exampleExample.ver. In this case, the paths were saved as connections.

For the same assignment, Table 139 shows the path legs, when the paths were saved asroutes.

Origin zone

Destination zone

Path index

Path leg index

Passenger trips

From stop point

To stop point

Time profile ID Departure

100 200 1 25,000 10 40 06:10:00

1 10 OrigConn 06:10:00

2 10 20 BUS1 1_H > 1 06:10:00

3 20 20 Transfer 06:22:00

4 20 40 TRAIN 1_H > 1 06:25:00

5 40 DestConn 06:41:00

100 200 2 14.000 10 40 06:10:00

1 10 OrigConn 06:10:00

2 10 40 BUS1 1_H > 1 06:10:00

3 40 DestConn 06:55:00

100 200 3 18.000 10 40 06:55:00

1 10 OrigConn 06:55:00

2 10 40 BUS1 1_H > 1 06:55:00

3 40 DestConn 07:40:00

100 200 4 16.000 10 40 07:25:00

1 10 OrigConn 07:25:00

2 10 20 BUS1 1_H > 1 07:25:00

3 20 20 Transfer 07:37:00

4 20 40 TRAIN 1_H > 1 07:45:00

5 40 DestConn 08:01:00

100 200 5 17.000 10 40 07:25:00

1 10 OrigConn 07:25:00

2 10 40 BUS1 1_H > 1 07:25:00

3 40 DestConn 08:10:00

Table 138: Path legs after a timetable-based assignment (paths saved as connections)

Origin zone

Destination zone

Path index

Path leg index

Passenger trips

From stop point

To stop point


100 200 1 25,000 10 40 00:00:00

1 10 OrigConn 00:00:00

Table 139: Path legs after a timetable-based assignment (paths saved as routes)

413 © PTV AG


6.4 PuT skimsBy means of the Calculate PuT skim matrix procedure or during an assignment (see UserManual, Chpt. 6.4, page 1004) the skim data can be calculated for the PuT skims of the variousskim categories (see "PuT skim categories" on page 414).Since there are numerous routes or connections for an OD pair usually, the skims gained perroute or connection are aggregated to relation-based skim data by OD pair. Apart from theservice frequency which results from the number of connections, all skims are provided on thelevel of connections as well as on the level of OD pairs.

6.4.1 PuT skim categoriesThe skims can be divided into six categories.1. Skims of time (see "Skims of time" on page 415)2. Skims of length (see "You can select the metric units meters or kilometers (alternatively:

imperial feet/miles) for skim matrices. Table 141 shows all skims of the length provided inVISUM." on page 416)

3. Monetary skims (see "Monetary skims" on page 417)4. Frequency skims (see "Skims of frequency" on page 417)5. Skims of attribute data (see "Skims of attribute data" on page 418)6. Derived skims (see "Derived skims" on page 418)

2 10 20 BUS1 1_H > 1 00:00:00

3 20 20 Transfer 00:12:00

4 20 40 TRAIN 1_H > 1 00:15:00

5 40 DestConn 00:31:00

100 200 2 49.000 10 40 00:00:00

1 10 OrigConn 00:00:00

2 10 40 BUS1 1_H > 1 00:00:00

3 40 DestConn 00:45:00

100 200 3 16.000 10 40 00:00:00

1 10 OrigConn 00:00:00

2 10 20 BUS1 1_H > 1 00:00:00

3 20 20 Transfer 00:12:00

4 20 40 TRAIN 1_H > 1 00:20:00

5 40 DestConn 00:36:00

Origin zone

Destination zone

Path index

Path leg index

Passenger trips

From stop point

To stop point


Table 139: Path legs after a timetable-based assignment (paths saved as routes)

414 © PTV AG

Chapter 6.4: PuT skims

6.4.1.1 Skims of timeSkims of time (Table 140) are administered in seconds within the program VISUM. For skimmatrices you can select the unit minutes or seconds.

Skim Definition

Access time (ACT) Time required for covering the origin connector

Egress time (EGT) Time required for covering the destination connector

Origin wait time (OWT) Wait time at the start stop point (applies to the headway-based assignment only, as for the timetable-based procedure OWT = 0 is assumed)Note:For the timetable-based procedure, an adapted origin wait time can be calculated. (see "Adapted skims of time for the timetable-based assignment" on page 416).

Weighted origin wait time

Product from the origin wait time and the weighting factor of the origin wait time in the settings for the impedance of the headway-based assignment. This skim is only available in the headway-based assignment.

Transfer wait time (TWT)

Wait time between arrival and departure at a transfer stop point Note:For the timetable-based procedure, additionally the adapted transfer wait time can be calculated (see "Adapted skims of time for the timetable-based assignment" on page 416).

Weighted transfer wait time

Product from the transfer wait time and the weighting factor of the transfer wait time in the settings for the impedance of the headway-based assignment. This skim is only available in the headway-based assignment.

Extended transfer wait time (XTWT)

Extended wait time according to the settings for the transfer wait time in the perceived journey time definition for the timetable-based assignment.

In-vehicle time (IVT) Time spent inside PuT vehicles including dwell times at stops.

In-vehicle time by TSys (IVTT)

Time spent inside PuT vehicles of a certain public transport system.

PuT-Aux time (XZ) Time spent in a vehicles of public transport systems of the PuT-Aux type.

Walk time (WKT) Walk time for transfer links between two stop points within a stop area or between different stop areas of a stop

Journey time (JRT) Time between the departure from the origin zone and the arrival at the destination zoneJRT = ACT + OWT + Σ IVT + Σ TWT + Σ WKT + EGTNote:For the timetable-based procedure, additionally the adapted journey time can be calculated (see "Adapted skims of time for the timetable-based assignment" on page 416).

Table 140: Skims of time

415 © PTV AG


Adapted skims of time for the timetable-based assignmentThe skims OWT, TWT, JRT and RIT in the form described above always refer to the real originwait 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, theadapted origin wait time can differ from 0 because it depends on the number of connectionsprovided in the assignment interval. The adapted transfer wait time depends on the usersettings for „transfer wait time” and can thus be limited. Furthermore, it can be transformedimplicitly by a polynomial for stronger weighting of extremely short wait times and for thedefinition of a certain wait time (for example five minutes) as the optimum.

6.4.1.2 Skims of lengthYou can select the metric units meters or kilometers (alternatively: imperial feet/miles) for skimmatrices. Table 141 shows all skims of the length provided in VISUM.

Ride time (RIT) Time between the departure from the origin stop point and the arrival at the destination stop pointRIT = Σ IVT + Σ TWT + Σ WKTNote:For the timetable-based procedure, additionally the adapted journey time can be calculated (see "Adapted skims of time for the timetable-based assignment" on page 416).

Perceived Journey Time (PJT)

Perceived journey time (see "Perceived journey time" on page 424)PJT = f(ACT, EGT, OWT, TWT, NTR, IVT, WKT, XZ)

Adaptation time (ADT) Difference DeltaT between desired departure time and actual departure time

Extended adaptation time (XADT)

User-defined adaptation time. Variant of the adaptation time which assumes that the entire demand of each time interval is assigned to the connection with the minimum impedance.

Skim Definition

Access distance (ACD) Length of the access route on the footpath from the origin zone to the origin stop point

Egress distance (EGD) Length of egress route from destination stop point to destination zone

In-vehicle distance (IVD) Distance covered in vehicle without transfer walk links

In-vehicle distance per TSys (IVTD)

Travel distance inside vehicles of a specific public transport system

PuT-Aux distance (AXD) In-vehicle distance for a PuT-Aux transport system

Walk distance (WKD) Length of a transfer link between the two stop points

Table 141: Skims of length

Skim Definition

Table 140: Skims of time

416 © PTV AG


6.4.1.3 Monetary skimsTable 142 shows the monetary skims available in VISUM.

6.4.1.4 Skims of frequencyTable 143 shows the available frequency skims.

Journey distance (JRD) Distance covered between origin and destination zoneJourney distance = Access distance + In-vehicle distance + Walk distance + Egress distance

Ride distance (RID) Covered distance from origin stop point to destination stop pointRide distance = In-vehicle distance + Walk distance

Direct distance (DID) Direct distance between origin and destination zone

Skim Definition

Fare (FAR) Fare for the PuT ride between origin and destination zone (see "Fares" on page 424)

Table 142: Monetary skims [Currency units]

Skim Definition

Number of transfers (NTR)

Number of transfers between origin and destination stop point (per connection). [-]

Service frequency (SFQ)

For the timetable-based procedure, the service frequency is defined as the number of different arrival times for connections departing within the assignment time interval or in the succeeding extension period past the end of the assignment time interval yet before a possible second occurrence of the start of the assignment period. The latter especially means that the succeeding period is not considered, if you do not use a calendar and define a 24-hour assignment time interval covering the whole day.For the headway-based assignment, a flow problem is solved on the graph of all determined routes. Service frequency thus depends on the "weakest" part in the transport supply.

Number of operator changes (NOC)

Number of transfers with different operators of previous and next path leg. [-]

Number of fare zones Number of traversed fare zones. The skim depends of the ticket type(s) used for the connection and returns zero if no zone-based ticket type is used. [-]

Table 143: Skims of frequency

Skim Definition

Table 141: Skims of length

417 © PTV AG


6.4.1.5 Skims of attribute dataTable 144 lists the provided skim that results from the values of the selected attribute.

6.4.1.6 Derived skimsDerived skims (Table 145) result from a combination of the above listed skims.

Skim Definition

Path leg attribute (PLA) Throughout the entire path aggregated value of the selected (direct or indirect) path leg attribute, for example Line route\AddValue1.

Table 144: Skims of attribute data

Skim Definition

Impedance in a time interval (IPD)

Impedance of a connection = f (perceived journey time, fare, temporal utility). For the skim matrix you can select whether the temporal component should flow into the impedance in minutes or seconds.

Journey speed (JRS) Ratio of the journey distance and the journey time between origin and destination zone [km/h]Journey speed [km/h] = journey distance [m] / 1000) / journey time [min] / 60)

Direct distance speed (DIS)

Ratio of the direct distance and the journey time between origin and destination zone [km/h]Direct distance speed [km/h] = direct distance [m] / 1000) / journey time [min] / 60)

In-vehicle distance as percentage by TSys (IVTP)

Distance covered in the TSys as a percentage of the total in-vehicle distance of the connection

Equivalent journey time (EJT)

Skim value which results from a user-defined formula according to the set parameters. The unit of the journey time equivalent is determined by the user-defined formula.

Extended impedance (XIMP)

The extended impedance is a component of the perceived journey time (PJT). It can be defined in the settings for the impedance of the timetable-based assignment and is thus only available in the timetable-based assignment.

Table 145: Derived skims

418 © PTV AG


Utility (UTL) The Utility is based on the following:• On the one hand, the utility is based on C, which is the set of connections

determined for an OD pair. • On the other hand, the utility is based on the set of time intervals T = (t1, ...,

tn) resulting from the time series relevant to the OD pair or from refined time series intervals, if applicable.

Per time interval t in T, each connection c in C has an impedance wt(c), which depends on t, since the impedance may contain the time interval’s distance from the connection’s departure time.Using an antitone utility function f, the respective utility ut(c) is calculated from the impedance wt(c) according to ut(c) = f (wt(c)).

In case of the Logit model f(x) = e-bx.The share of a connection c of the demand per interval t is then derived according to the following formula.

The denominator 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.

Here, dt is the total demand within time interval t.

Skim Definition


( ) ( )( )∑

∈′′

=

Ccctu

ctuctp

∑

∑

∈

∈=

Tttd

TttdtU

U

419 © PTV AG


6.4.1.7 Examples for skimsillustration 146 and Table 146 illustrate a few skims for the connections of an OD pair.


Discomfort due to capacity overload (DISC)

Time during which a passenger has no seat in the course of this journey.The skim is calculated as journey time weighted by service trip item. Its weight is a function of the volume/seat capacity ratio.For each individual PuT path C, the discomfort E(C) is defined as follows.

Herea = Index over all service trip items of a PuT path CFa = Journey time of the service trip item a (known from its time profile)Pa = Number of passengers on service trip item a (over all paths, determined by assignment)Sa = Number of seats on service trip item a (based on the total of the seats of all service trip sections which traverse the service trip item on the respective calendar day)A,B = free parametersPath legs covered by PuT-Walk or PuT-Aux TSys in the PuT path are ignored.NoteThe discomfort due to capacity overload is only calculated with a timetable-based assignment.

Connection 1 Connection 2

Used sequence of lines / route Bus1 Bus1, Train

Access distance [m] 300 300

Access time [min] 3 3

Table 146: Example of the connection skims of an OD pair

Skim Definition


( ) ∑∈

−⋅⋅=

Ca

BSPA

eaFCE aa

Station

Bus 1

Train

A-Village

X-City

Bus 1

420 © PTV AG


6.4.1.8 Availability of the skims in the PuT assignment proceduresTable 147 shows which skims can be calculated per PuT assignment procedure.

Run time [min] 45 28

Transfer wait time [min] 0 8

Egress distance [m] 500 500

Egress time [min] 5 5

Ride time [min] 45 36

Journey time [min] 53 44

Journey distance [m] 27.500 20,000

Direct distance [m] 18.385 18.385

Journey speed [km/h] 31.1 27.3

Direct distance speed [km/h] 20.8 25.1

Number of transfers [-] 0 1

Skim output by procedure Default ext. TSys-based

HWay-based

Timetable-based

Journey time JRT X X X

Journey time adapted JRTA X

Ride time RIT X X X

Ride time adapted RITA X

In-vehicle time IVT X X X

PuT-Aux time AXT X X X

Origin wait time OWT X

Origin wait time adapted OWTA X

Weighted origin wait time WOWT X

Transfer wait time TWT X X

Transfer wait time adapted TWTA X

Weighted transfer wait time WTWT X

Extended transfer wait time XTWT X

Walk time WKT X X X

Access time ACT X X X

Egress time EGT X X X

Perceived journey time PJT X X

Number of transfers NTR X X X

Service frequency SFQ X X

Table 147: Availability of the skims in the PuT assignment procedures

Connection 1 Connection 2

Table 146: Example of the connection skims of an OD pair

421 © PTV AG


6.4.1.9 Aggregation to mean skims per OD pairDepending on the chosen search procedure there are different possibilities to aggregate theskim values (Skim) of the connections to mean skim data (mSkim) by OD pair (Table 148):

Direct distance DID X X X

Journey distance JRD X X X

Ride distance RID X X X

Trip distance IVD X X X

PuTAux distance AXD X X X

Walk distance (transfer walk links) WKD X X X

Access distance ACD X X X

Egress distance EGD X X X

Journey speed JRS X X X

Direct distance speed DIS X X X

Fare FAR X X

Number of fare zones NFZ X X

Number of operator changes NOC X

In-vehicle distance per TSys IVTD X X X

In-vehicle distance percentage per TSys IVTP X X X

In-vehicle time per TSys IVTT X X X

Impedance IPD X X

Utility UTL X

Path leg attribute PLA X X

Adaptation time ADT X

Extended adaptation time XADT X

Extended impedance (XIMP) XIMP X

Equivalent journey time (user-defined) EJT X X X

Discomfort due to capacity overload (only calculated during assignment)

DISC X

Aggregation functions HWay-based

TT-based

Unweighted quantileFor 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 # {i : xi ≤ y } / n ≥ z.

X X

Table 148: Combination of skim data to the mean skim value per OD pair

Skim output by procedure Default ext. TSys-based

HWay-based

Timetable-based

Table 147: Availability of the skims in the PuT assignment procedures

422 © PTV AG


The skim service frequency SFQ does not refer to a particular route or connection, but to anOD pair.For the timetable-based procedure, the service frequency results from the number of differentarrival times.

ExampleFor an OD pair, three connections are determined:

Weighted quantileThe connections are weighted with the volume at the calculation of the quantile.

X X

Unweighted mean X X

Weighted mean X X

Unweighted mean restricted to paths of sufficiently low impedance X X

Weighted mean restricted to paths of sufficiently low impedance X X

mSkim = skim value for route with minimum impedance X

mSkim = skim value for route/connection with minimum perceived journey time X

Connection 1 2 3

Volume 50 % 20 % 30 %

Number of transfers 1 3 2

Aggregation functions HWay-based

TT-based

Table 148: Combination of skim data to the mean skim value per OD pair

sConnectionofNumber

ConnNum

iiSkim

mSkim∑== 1

∑

∑=

⋅

=Passengers

NumConn

iiPassengersiSkim

mSkim 1

j

j

jjSkim

mSkim′

′

==

∑1

∑

∑

′

=

′

=⋅

= j

jjdemandtotalofShare

j

jjSkimjdemandtotalofShare

mSkim

1

1

423 © PTV AG


By means of the different aggregation functions, the number of transfers by OD pair iscalculated as follows:

6.4.2 Perceived journey timeThe perceived journey time PJT results from the weighted components of the journey time andfurther components.Perceived journey time PJT [min]= In-vehicle time • FacIVT • (in)direct time profile item attribute 2)+ PuTAux time • FacAXT 1) + Access time • FacACT+ Egress time • FacEGT+ Transfer walk time • FacTWT+ Origin wait time • FacOWT+ Transfer wait time • FacTWT+ Number of transfers • FacNT+ Number of operator changes • FacNOC 1)+ Extended impedance • FacXIMP 1)

1) timetable-based assignment only2) headway-based assignment only, (in)direct vehicle journey item attribute in thetimetable-based assignment

The perceived journey time is used for the headway-based procedure and timetable-basedprocedure, to evaluate individual connections during the connection choice. Weighting thenumber of transfers strongly, for example, results in passengers preferring minimum transferconnections.• In both procedures, boarding events and transfers can be evaluated in addition. • Headway-based assignment does not yet regard PuT-Aux times.• For the timetable-based assignment, the following options are provided:

• the number of operator changes can be taken into account• the PuTAux time can be weighted with a TSys attribute• the extended impedance can be defined• Moreover, for each component a Lambda value can be entered and/or the option

BoxCox transformation can be activated.

6.4.3 FaresVISUM can be used to calculate fares (see "PuT fare model" on page 546). The fare perconnection results from the used ticket type(s). It includes the specific supplement by transportsystem (for ICE, for example). These fares are calculated for each connection and can beregarded in the impedance definition of the timetable-based assignment. They can also be

Mean value 50 % quantile

unweighted weighted unweighted weighted

(1 + 3 + 2) / 3= 2

1 • 0.5 + 3 • 0.2 +2 • 0.3= 1.7

Values: (1, 2, 3)50 % quantile = 2

Values: (1,1,1,1,1,2,2,2,3,3)50 % quantile = 1

424 © PTV AG

Chapter 6.5: PuT impedance functions

output as skim matrix and can be taken into consideration for the revenue calculation which isperformed by the PuT operating indicators procedure.

6.4.4 Temporal utilityFor the timetable-based assignment, the temporal utility of a connection is included as a furtherskim value in the definition of impedance (see "PuT impedance functions" on page 425).The temporal utility of a connection depends on the following parameters:• Desired departure time, which is indicated by the temporal distribution of demand• Time difference ΔT between provided time of departure and desired time of departure • Tolerance to differences between the provided time and the desired time of departure,

which is called the sensitivity to earlier or later departuresIn this way it can be modeled that also the temporal position of a connection has an effect onits attractiveness.The temporal utility of a connection is highest for that interval in which the connection is placed,because then T = 0 applies. The higher ΔT, the lower the temporal utility.In the timetable-based method, the temporal utility is included in the impedance definition indifferent ways – either by using a function N = f(DT) or by using ΔT directly. In both cases, thesensitivity towards early or late departure can be set by means of parameters.For both variants, the following applies. The shorter the period between the actual and the desired departure time, the higher thetemporal utility of the connection and the lower its impedance.

6.5 PuT impedance functions Like PrT assignment procedures (see "Impedance and VD functions" on page 200) the PuTassignment procedures derive the impedance of a connection (see "PuT skims" onpage 414)from several skims of this connection or route . Thus, the impedance is a user-defined combination of various skims. According to requirements, a malus or a bonus can bespecified for various properties of a connection. The general rule is "The lower the impedanceof 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 alsoto 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 temporalutility (see "Temporal utility" on page 425) at the connection choice of the timetable-based

Time series with hourly intervalsΔT (6-7) = 7:20 – 7:00 = 20 minΔT (7-8) = 0 minΔT (8-9) = 8.00 – 7.20 = 40 min

Table 149: Example for the determination of the time difference ΔT

6:00 7:00 8:00 9:00

Dep. 7:20

425 © PTV AG


procedure (see "Timetable-based assignment" on page 452), the impedance of a connectioncan be different from time interval to time interval.The actual definition of impedance differs in the various assignment procedures. Thetimetable-based procedure actually uses different approaches in two of the calculation-internalwork steps. An overview is given in Table 150. All factors can be set freely and also be set tozero, so that they are not considered in the assignment.

6.6 Distribution of the travel demand to PuT connectorsSimilar to the PrT origin and destination demand also the PuT origin and destination demandcan be distributed arbitrarily or by percentage (see "Distribution of demand of a zone to theconnectors" on page 35). Hereby, a distribution by percentage does not distinguish betweentwo variants of distribution; rather the overall demand is distributed. The distribution bypercentage may be used, for example, to assign transport demand to all stops situated withina community (modeled as zone).The proportional distribution of the PuT is effected similar to the distribution by percentage ofPrT. All origin and destination demand of the zone is distributed onto all connectors of the zoneproportionally to their respective current connector weights. For each connected node atemporary virtual zone is created whose overall demand receives the share of overall demandthat was originally defined for this connector of the original zone. The assignment is calculatedon the basis of the virtual zones. After terminating the assignment, the temporary zones aredeleted again and the results are allocated to the original zone.

ExampleTwo 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 5The connector weights for origin and destination are set according to Table 151.

Procedure Definition of impedance

Timetable-based –Branch&Bound Search

IMP = JRT • Fac1 + NTR • Fac2 + TSysIMP • Fac3

Timetable-based – Shortest path search

IMP = JRT

Timetable-based – Choice

IMP = PJT • Fac1 + Fare • Fac2 + ΔTearly • Fac3 + ΔTlate • Fac4

Headway-based – Search

IMP = IVT + TWT • Fac1 + NTR • Fac2 Here, TWT represents the expected wait time for the line the passenger wants to board for the transfer.

Headway-based – Choice

IMP = PJT • Fac1 + Number of fare points • Fac2

Table 150: Comparison of the impedance functions in the PuT assignments

426 © PTV AG

Chapter 6.7: Allocation of skims with reference to lines/links

• Transport demand from zone 100 to zone 200 = 1000 trips• Transport demand from zone 200 to zone 100 = 500 tripsFor the assignment, this leads to the temporary demand matrix displayed in Table 152.

The value of the temporary OD pair 1 4 is calculated from 1,000 • 0.2 • 0.9 = 180.

6.7 Allocation of skims with reference to lines/linksCertain attributes, for example the line network length of a transport system or the attributesnumber of service trips or PuT volume of a link are in an intermediate position, becausespatially their definition refers to a link and also to a line route. Since stop points may optionallybe placed on links, and both line routes and service trips extend from stop point to stop point,only certain sections of links may be traversed by line routes or service trips.In most cases, proportional allocation of these skim values to the link does not make sense,which is why the definition for those skims has been standardized:A link is regarded as being used (completely) by an object of the line hierarchy if the link sectiontraveled accounts for at least half of the link length (≥ 0.5). For skim values that refer to sectionsbetween stop points (for example volume), the following applies. To each stop point on a linkthe nearest node is allocated (either the FromNode or ToNode of the link). The skim value ofthe section between the last stop point, to which the FromNode is assigned, and the first stoppoint, to which the ToNode is assigned, is regarded as the skim value for the (entire) link.illustration 147 shows a skim value calculation example for such partially traversed links.

Connector node Weight (origin) Weight (destination)

1 20 0

2 30 80

3 50 20

4 40 90

5 60 10

Table 151: Connector weights for the example

Virtual zone 1 2 3 4 5

1 - - - 180 20

2 - - - 270 30

3 - - - 450 50

4 0 160 40 - -

5 0 240 60 - -

Table 152: Temporary demand matrix for the assignment in the example

427 © PTV AG


Illustration 147: Example for skim value calculation for partially traversed links

Line route 1 touches the links 2, 3, and 4 (because the section traveled accounts for at leasthalf of the link), not link 1 however, because the traversed section is < 0.5 on link 1. Vehiclejourney 1 only touches link 3. The volume between the stop points B and C is regarded as thePuT volume of link 2, while for link 3, volume C – D applies and for link 4, the volume betweenD and E.

6.8 Transport system-based assignmentThe 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 runtimes. 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 linesFrom the links of this basic network a graph is constructed which is the basis for a best-routesearch. Because individual lines are not distinguished, transfer stops with their respective transfertimes cannot be included in the search. It is possible, however, to include transition timesbetween different transport systems (transfer penalties for transport system changes, forexample between bus and train).The transport system-based assignment calculates exactly one route for each pair of originzone and destination zone, which consists of one origin connector and one destinationconnector for the PuT as well as of links and turns, which are permitted for a public transportsystem. Transfers are changes of the transport system which are considered in the form of atime penalty in the route search.• For links, t-PuTSys is considered• A transport system change can only take place at selected nodes• At nodes, where a transport system change is necessary, a transfer time penalty TP is

assigned• TP = node type-specific time penalty + penalty per transfer• At nodes, at which no turn for the public transport system is permitted between the links,

the time penalty TP is also added if option Consider prohibited turns is active.

Node Stop point

Links

Line route 1

Service trip 1

1 2 3 4

A B C D E

428 © PTV AG

Chapter 6.8: Transport system-based assignment

6.8.1 Evaluation of the transport system-based assignmentThe 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 anew line network. The procedure calculates the shortest routes (minimum time required) whichare then charged with the travel demand. The resulting volume flows represent the "desiredline network" of the passengers.The volumes resulting from the timetable-based assignment and the headway-basedassignment will differ significantly from the results calculated by the transport system-basedassignment. Under no circumstances neither a timetable-based nor a headway-basedcalculation should be replaced by the transport system-based procedure.

6.8.2 Example for the transport system-based assignmentFor the PuT supply in the example (see "Example network for the PuT assignment procedures"on page 409), the procedure determines the following shortest route given a transfer penalty of10 minutes for the transfer from bus to train.• 12 minutes from A-Village to Station with transport system Bus• 16 minutes from Station to X-City with transport system Train With a 10-minute transfer penalty, this results in a ride time of 38 minutes. All 90 trips from A-Village to X-City are assigned onto this route.This results in the volumes shown in illustration 148.

Illustration 148: Network volume after transport system-based assignment (parameters file TSys1.par)

90

90

0 0

Station X-City

A-Village

B-Village

429 © PTV AG


From a transfer time of 18 minutes onward, the TSys bus is used instead of the train for thesection between the Station and X-City (illustration 149).

Illustration 149: Network volume after transport system-based assignment (parameters file TSys2.par)

6.8.3 Steps of the transport system-based assignmentOn the links, connectors and turns which are permissible for public transport systems in thenetwork, the transport system-based assignment determines the routes with the minimumimpedance for each OD pair.

6.8.3.1 Route searchThe impedance of a route consists of the following components.• Run times of traversed links• Transfer penalty for every transport system transfer• Node type-specific or stop-specific transfer penaltiesFor links which may be used by several public transport systems with different run times, theminimum run time is used.

6.8.3.2 Route loadingThe 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 ODpair.

6.9 Headway-based assignmentFor the headway-based procedure, each line is described by the line route, the run timesbetween line stops, and the headway. Actually, it is the time profile which comprises thisinformation and the headway-based procedure works on this model level (see "Network

90

0

90 90

Train X-City

A-Village

B-Village

430 © PTV AG

Chapter 6.9: Headway-based assignment

objects of the line hierarchy" on page 46). In the following sections the term line is used for thesake of convenience. This emphasizes that the timetable of the individual service trips is notregarded.Transfer wait times are usually regarded globally, which means that the departures of differentlines are independent of each other. As a standard, a timetable coordination is not taken intoconsideration. By explicit modeling, however, it can be expressed that lines operate with thesame headway each on a shared section, or rather a fixed transfer wait time exists betweentwo lines (see "Matched transfers" on page 450). TSys of the PuT-Aux type are not yetregarded.The headway-based assignment procedure includes the three operational steps.1. Headway calculation (see "Headway calculation" on page 432)2. Route search and route choice (see "Route search" on page 446 and "Route Choice" on

page 447) 3. Route loadingIn the combination of search and choice, the headway-based procedure differs from thetimetable-based assignment. In this second step, possible paths between two traffic zones aredetected and simultaneously a distribution is specified between them. The paths do notrepresent connections, but routes (see "PuT paths" on page 412), as the calculation is notdone on the time axis, but merely regards travel times and headways. In the third step, theroutes found in the search are loaded with the demand from the demand matrix and stored inmemory (if desired).

6.9.1 Evaluation of the headway-based assignmentThe headway-based procedure is characterized by the following features.• The procedure, as is the case with the timetable-based assignment, not only determines

the optimum routes, but also those that are good enough. However, the transfer wait timegoes in only globally here.

• A co-ordination of the timetable is regarded only if the co-ordination has been modeledexplicitly (see "Coordination" on page 449).

• The number of transfers, journey time and the ride time can be estimated with sufficientaccuracy if all lines have short headways.

• The bandwidth of various choice models offers the big advantage of being able to configurethe procedure in such a way, that it precisely reflects the available passenger informationprovided in the analyzed network. Accordingly, you can apply different models to make anestimate of the benefit, which can be achieved by investing in passenger informationsystems.

• Compared to the timetable-based procedure, the headway-based procedure shows aconsiderable reduction of computing time for most PuT networks, this is especially the casefor networks with regular headways (fixed-time rhythm). In networks in which many linesconsist of only one trip, however, time savings are low.

• Because the headway-based procedure normally does not take the co-ordination of thetimetable 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 withscenarios for which no exact timetables exist yet. This procedure is not suited for PuT

431 © PTV AG


supply planning in rural areas or for long-distance transport, because in these cases longheadways occur, and it is an elementary planning task to provide connections.

• The headway-based procedure cannot regard the fares for the impedance calculation. Fora fare model-based impedance calculation, use the timetable-based procedure instead(see "Calculation of the fare revenues (revenue calculation)" on page 594).

6.9.2 Headway calculationYou can define the headway of a line in three different ways (see User Manual, Chpt. 6.2.3.1,page 956).• from a (usually user-defined) time profile attribute• from the mean headway according to the timetable• from the mean wait time according to the timetable (default setting)Each of the three methods can be applied separately by time interval. That way you can modelthat the transport supply varies within the assignment period – for example, because of thehigher demand during morning peak hours.

From time profile attributeIn 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 timetableVISUM can also automatically calculate the headway from the timetable of the time profile. Forthat purpose, the number of departures n is determined for each time interval l = [a,b) within theassignment time interval. The headway results as the quotient.

In the case of networks with short headways and sufficiently broad time intervals, this simplifiedapproximation is acceptable. Generally speaking, however, this approach is problematic fortwo reasons.On the one hand, the definition is too susceptible to shifts of individual departures beyondinterval limits, which leads to inconsistencies in the result. This problem always occurs whenthe actual headway of a line is not a divisor of the length of the demand time interval. For a linewith a 40-minute headway, for example, and the time interval l = [6:00,7:00), differentheadways are calculated for the particular departure times (Table 153).

On the other hand, this approach cannot reflect the following fact: For the passenger whoarrives at random, trips spread evenly throughout the time interval generally mean less waittime than trips that are piled up. The following third definition, therefore, is used as the defaultsetting for the headway-based procedure.

Departure times Trips in the time interval Calculated headway

5:55, 6:35, 7:15, ... 1 60 minutes

6:05, 6:45, 7:25, ... 2 30 minutes

Table 153: Example for headway calculation from mean headway according to timetable

τa b, b a–n

------------=

432 © PTV AG


From mean wait time according to timetableThe headway τa,b of a line is defined as double the expected wait time for the nextdeparture 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 existor can occur later, the fictitious departure x‘‘ = x1 + (b-a), which results from the cyclicalcontinuation of the timetable in l, is also considered. For the calculation of the wait time at theend of l the departure xn+1 = min{x‘,x‘‘} is used.

The headway is then defined as follows.

Here applies: , and to theremaining i ∈ {1, ..., n-1}. Δi is in each case the expected wait time in a sub-interval.

If you now look again at the example with the 40-minute headway and the interval l = [06:00AM,07:00 AM), you get a much more balanced picture.

Using the example in the first row, the calculation can be briefly explained as follows. In this case n = 1, x1 = 06:35 AM and x2 = 07:15 AM apply.

Therefore follows

and

Overall this results in minutes.

Compared to the case of the naive approach , this example shows that the calculatedvalues vary far less when shifting the specific departure times.

6.9.3 Generalized costs as impedanceFor route search and choice (see "Route search" on page 446 and "Route Choice" onpage 447), paths are assessed by their impedance or generalized costs (see "PuTimpedance functions" on page 425) respectively. This term contains the perceived journeytime, PJT, and a number of fare points.IMP = PJT • FacPJT + NumberFarePoints • FacNumFPThe perceived journey time, PJT, has the unit "Minutes" and consists of the following times.PJT [min] = in-vehicle time • FacIVT • weight attribute of the time profile item

Departure times Trips in the time interval Calculated headway

5:55, 6:35, 7:15 1 43’ 20’’

6:05, 6:45, 7:25, ... 2 33’ 20’’

Table 154: Example for headway calculation from mean wait time according to timetable

τa b, 1b a–------------ Δii 0=

n∑=

Δ0 x1 a–( )2= Δn xn 1+ xn–( )2 xn 1+ b–( )2–= Δi xi 1+ xi–( )2=

Δ0 6:35 6:00–( )2 1225= = Δ1 7:15 6:35–( )2 7:15 7:00–( )2– 1600 225– 1375= = =

τ6:00 7:00, 260060

------------ 43,3= =

τa b,

433 © PTV AG


+ PuT-Aux time • FacAXT 1)+ Access time • FacACT+ Egress time • FacEGT+ Transfer walk time • FacTWT+ Origin wait time • FacOWT+ Transfer wait time • FacTWT+ Number of transfers • FacNTHere, journey times, costs, etc. are deterministic. The origin wait time and the transfer wait timeresult from the previously specified headway of the PuT line which the passenger boards at theorigin stop or at the transfer stop. Within the limits of their headways, they depend - except inthe case of co-ordination (see "Coordination" on page 449) - in a random way on the transferlines' relative position to each other. PuT-Aux transport systems are not yet taken intoconsideration.The run time can be multiplied by a user-selected time profile item attribute in order to modelthe vol/cap ratio (for example the availability of seats) or other aspects of usability (for examplethe level of comfort) of a line.Other individual time penalties and weighting factors for boarding events or transfers can betaken into consideration as follows (see User Manual, Chpt. 6.2.3.4, page 962).• A boarding penalty from any time profile attribute• A mean delay from any time profile item attribute• A wait time factor from any stop area attributeWith the time penalties you can for example model, that some lines are favored by thepassengers – because of their better quality of traveling, or because they are usually punctual.Via the wait time factors you can model that the passengers prefer waiting at some stops thanothers.

6.9.4 Choice models for boarding decisionsIn the headway-based assignment it is usually assumed that passengers know line headwaysand times.Which additional information they have, is decisive for their choice behavior when boarding ortransferring. VISUM offers four different models.• No information and exponentially distributed headways• No information and constant headways• Information on the elapsed wait time• Information on the next departure times of the lines from the stopThe latter applies for example, when dynamic passenger information systems have beeninstalled at stops. The passengers can then see which of the departing lines in the currentsituation offer the least remaining travel time to their destination. As a result, they will forexample not board a line if the information system gives them the information, that shortly afterthis line there will be another much faster line.The individual choice models for the situation of a passenger waiting at a stop are introducedbelow. To describe the mathematical basis, we still require a few terms.

434 © PTV AG


NotationL = {1, ..., n} specifies the set of available lines. Each line i ∈ L has a certain remaining journey

time si ≥ 0 an a headway hi > 0. The frequency of the line is derived from the headway.

The term "remaining" should make it clear that we are talking about the remaining journey timefrom the currently considered stop to the destination zone. Only for the choice situation at theorigin 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 inascending order according to their remaining journey time. Thus the following applies s1 ≤ s2 ≤... ≤ sn. The set of the first i lines is abbreviated as follows: Li = {1, ..., i}.

Note, that the remaining journey time si in fact stands for the generalized costs of line i, whichcontain transfer penalties and further impedance components. For a better understanding wewill still be talking about "Times".On the basis of the available information the different choice models calculate the optimal setL* ⊆ L and for each line i ∈ L* a demand share πi ≥ 0.

It is clear that a line i must be part of L*, if another line j is contained in L* and if for theremaining journey times si < sj applies. From sorting the times it can be deducted that i* exists,

as a consequende 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.

The parameters are random variables because they depend on the random arrival of lines atthe 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 headwaysIf the passenger does not have additional information, he has to decide ad hoc whether toboard the arriving line or not. The choice model determines the optimal set of lines, and theoptimal strategy of the passenger is to choose the line in the set that arrives first.In addition to the missing passenger information, the model introduced in this section is mostnotably characterized by the fact, that the headway (the temporal gap between two departuresof a line) is not assumed to be a constant, but rather exponentially distributed. The expectedgap value is exactly the same as for constant headways 1 / λi, therefore the "Frequency" of theline. In contrast to constant headways, however, the headway times strongly scatter aroundthis value.Fundamental characteristic of the exponential distribution which is taken as a basis is that thewait time which has already elapsed since the last departure of the line, does not state howlong the passengers have to wait for the next departure. This property is called"Memorylessness". Thus, the greatest possible irregularity of the timetable is assumed.

λi1hi----=

CL' WL' πisii L'∈∑+=

435 © PTV AG


The optimal set under these model assumptions is composed as follows. The following is setfirst:

Then, the optimal line set 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) isnot 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 withthis 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 . 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 takenfrom the following formula.

Note, that the remaining travel times of the lines do not appear in the share definition. If linesare adequate enough to be contained in the optimal line set, their shares only depend on theirheadways. This property illustrates the heavily simplified construction of this choice model.The resulting expected wait time is as follows.

This choice model should only be used, if the line headways are extremely irregular, in otherwords, if the passengers face a high level of uncertainty.

6.9.4.2 No information and constant headwaysWith the same level of information, however, constant headways, the strategy of a passengeris 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) ofpotentially optimal line sets and to cancel exactly at that point when for the first time the

ui

1 λjsjj 1=

i∑+

λjj 1=

i∑----------------------------------=

λ λjj 1=

i 1–∑=

πiλi

λjj L∗∈∑-----------------------=

E WL∗( ) 1λjj L∗∈∑

-----------------------=

436 © PTV AG


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 guarantees, that the

optimal line set is composed exactly from those lines, which reduce the expected remainingcosts if being included in the selection.The shares assigned to the individual lines again correspond with the possibility of arriving first.

is the minimal occurring headway. This results in the following expected waittime.

If the timetable in the analyzed network is regular and only slightly irregular, and thepassengers do not have any information on departure times, this choice model is more realisticthan the model considered before.

6.9.4.3 Information on the die elapsed wait timeIf - in case of constant headways - the passenger makes use of the information on how long hehas 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 afterwaiting 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 assumethis is therefore not a strong assumption.

In this case, the optimal line set L* depends on the elapsed wait time and is therefore no longerconstant. Determining the set is more difficult than in the previous cases. It can be proven thatL* has the following shape.

Given are i* ≤ n and an orderly sequence of times 0 ≤ ti* ≤ ... ≤ tl. This means that the in timeinterval Ij = (tj+1,tj] just Lj = {1, ..., j} forms the optimal line set. tj is here the exact point in timet, from which onward the remaining journey time of line j ≥ the expected remaining costs(including wait time according to t) of the lines Lj-1. In other words, tj is the unique solution for tin .

The optimal strategy is as follows. If the passenger observes an arrival of a line from τ ∈ Ij, afterwait 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 thefollowing, it corresponds more with the real behavior of passengers than its abstract definition.

i∗ argmini ECLi{ }=

πi λi 1 λjw–( )j L∗∈ j i≠,

∏ wd0

h

∫=

h min hi{ }=

E WL∗( ) 1 wλj–( )j 1=i∗∏ wd

0

h

∫=

sj E CLj 1–W t>( ) t–=

437 © PTV AG


Because the passenger knows the headways of all lines, his knowledge on which availablelines are still worth taking, increases the longer he is waiting. Comparable slower lines may stillbe reasonable options at the beginning of the wait time. There is a time, however, when theevaluation „topples”. At a certain time, the expectancy for the remaining wait time for the fasterj-1 lines is less than the difference between their remaining travel time and the remaining traveltime of the line j. Exactly as of this time is it no longer worth it to take line j – even if it arrivesimmediately. The times tj mentioned above are exactly those moments where a line j is no

longer included in the optimal line set L*.

ExampleLet us regard the following simple situation of two lines.

The passenger waits maximum 15 minutes to continue his journey. After t minutes theexpected remaining travel time for line 1 is exactly 10 + (15 - t) / 2 minutes. To determine thepoint 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 minuteslonger 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 timesThis model is based on the assumption that a passenger does not only know the times andheadways of all lines, but can (at least at the stop) also get information on precise departuretimes. The optimal strategy can thus be formulated as follows.A passenger boards the line that offers the least remaining costs given the actualdeparture times.Unlike in previous cases, the passenger does not simply board the first arriving line of a certain(possibly time dependent) set. Because all wait times wi are known, the passenger's decisionis not subject to stochastic influences. He or she rather selects exactly that line whoseremaining costs si + wi are at a minimum.

The optimal line set thus consists of all lines, which have the least costs in some timetablepositions.

and

The optimal set of lines are those, which are optimal in border cases, since they arrive withouta wait time, whereas all other lines have to be waited for by a complete headway. The calculation of shares is as follows.

(59.1)

Line Run time Headway

1 10‘ 15‘

2 13‘ 15‘

Table 155: Considering elapsed wait time

i∗ max i: si minj sj hj+{ }<{ }= L∗ Li∗=

πi = P Ci Cj< j∀( )

438 © PTV AG


(59.2)

(59.3)

(59.4)

(59.5)

(59.6)

Explanation of the derivationIn row (59.1), the entire passenger information is used. Line i is selected if its remaining costsCi are lower than those of the other lines. Row (59.2) reformulates the expression, by using thedensity function of the random variable Ci. Due to constant headways Ci is equally distributedin [si,si + hi). (If the wait time is weighted with a factor, this should be put in front of hi, thecalculation otherwise does not change.)In row (59.3) we take advantage, that the departures of the lines are independent of eachother. In all choice models this is a basic assumption of the headway-based assignment. Toavoid case differences, the integration range in(59.5) is separated into sections, in which theinner 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 thebeginning, because the costs of line j > k sum up to at least sk+1. In the last step we then applythe distribution function of Cj which (59.6)again is an equal distribution. At the end of the

invoice, the result is a sum of polynomials with a maximum degree of i*.The expected wait time is achieved analogously.

= 1hi---- P Ci Cj< j Ci x=∀( ) xd

si

si hi+

∫

= 1hi---- P

j i≠∏ Ci Cj Ci x=<( ) xdsi

si hi+

∫

= 1hi---- P

j i≠∏ Cj x>( ) xdsi

si hi+

∫

= 1hi---- P Cj x>( )

j 1=j i≠

k

∏ xdsk

sk 1+

∫k i=

i∗

∑

= 1hi---- 1

x sj–hj

------------–⎝ ⎠⎛ ⎞

j 1=j i≠

k

∏ xdsk

sk 1+

∫k i=

i∗

∑

439 © PTV AG


To assume passenger information is no extremely strict requirement. Many places alreadyhave information systems which display the next departure times on the basis of real-timeoperating data. Alternatively, timetables could be hung up at stops. There are also no limitsregarding other technical resources.

6.9.5 The complete choice modelThe choice model for boarding decisions all apply to the situation of a passenger, who iswaiting at a stop for departures of suitable lines (see "Choice models for boardingdecisions" on page 434). Even if the assumed level of information varies strongly between themodels, it always applies that the passenger decides for one of the different lines, due toobservations (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 notbased on observations, but on estimates. However, when passengers rely on estimates or notagain depends on the passenger information available in the network. Below it is describedbriefly under which conditions observations are not restricted to the departures of the lines atthe current boarding stop.

6.9.5.1 Extended applicability of the departure time modelWith a suitable infrastructure, a stop-based departure display can also be seen by passengersin arriving lines – before alighting. In this case, the choice model Information on departuretimes (see "Information on departure times" on page 438) is not just applied to the possibletransfer lines, which are available after alighting. In fact, it already refers to the decision of thepassenger still on board, because by acknowledging the departure times early enough, thepassenger can judge whether continuing the journey on the same line is more profitable thangetting off. This also applies, if information on connections provided at the next stop isdisplayed in the vehicles.Another relevant difference in cases is the question, whether passenger information systemsat a stop only display departure times of those lines which depart from just this stop. In someplaces, displays are used which also include the departures of other lines, departing at stopsclose-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 thenext departure times of all potential transfer lines at the current stop and at those which can bereached by foot from this stop. The model is then applied to the total set of available lines. Thetechnical realization of such a level of information can for example be a service, which provides

E WL∗( ) 1hi---- x si–( ) 1

x sj–hj

------------–⎝ ⎠⎛ ⎞

j 1=j i≠

k

∏ xdsk

sk 1+

∫k i=

i∗

∑i 1=i∗∑=

440 © PTV AG


via cell phone the information on the current timetable and - on the basis of operational real-time data - a recommendation for the passenger. A completely different model assumption,which nevertheless leads to the same level of information, is the passenger's knowledge of thetimetable.The border case of complete passenger information is provided, if the situation describedabove 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 fromthere, again a mobile information service or complete knowledge of the timetable have to beassumed.

6.9.5.2 Modeling the choice on the basis of estimatesApart from the case of complete passenger information, there always are also decisions whichare made on the basis of estimates. The simplest example is the choice between severalboarding stops at the start of the journey or at a transfer. If passengers do not have anyinformation 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 alternativeThe second case reduces the expected remaining costs, however, does not reflect thefuzziness of the passengers' behavior. That is why a discrete choice model should be favorednormally. If the flexibility parameter goes towards infinity, the result comes close to the 0/1decision in favor of the alternative with the lowest expected remaining costs anyway.

6.9.5.3 Hierarchical structure of the choiceIn 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 discretechoice model to obtain a distribution between the alternatives. In the second case, one of thechoice models for boarding decisions is applied (see "Choice models for boarding decisions"on page 434).The result of the decision made on a lower level becomes part of the decision on a higher level,in form of expected remaining travel time.The different levels of information and the various decision situations produce differenthierarchical structures for the passenger's decision as a whole. Three examples illustrate theprocedure in principle (see "Example for the choice models" on page 441).

6.9.5.4 Example for the choice modelsLet us look at the following network.

441 © PTV AG


Illustration 150: Example network for choice models

We analyze the decision of a passenger, who is on board of line 1 and arrives at stop A. First,we will look at how the structure of the choice made changes, if the available informationvaries.The analyzed scenarios are the following.1. No information, constant headways2. Departure time information per stop, not available on board.3. Departure time information per stop, also available on board.4. Departure time information for all stops, not available on board.5. Departure time information for all stops, also available on board.

Hierarchical structureIn the first example we are looking at the situation in scenario 1.

Illustration 151: Structure of the choice in scenario 1 (no information)

In the illustration, circles represent lines and rectangles indicate stops.

A

B

C

Destination

Line 1

Line 2

Line 1

Line 3

Origin

Line 4

Line 5

+2‘ walk time

+1‘ walk time

4 54 54 54 543

1

2

?

Alight

A B C

442 © PTV AG


Here the passenger first decides between continuing the journey or getting off, though theremaining journey time resulting from the second alternative can only be estimated. Afteralighting a decision is made for the boarding stop (A, B or C), which again is only based onexpected values. Only after having arrived at this stop the passenger can make a definitedecision 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 decisionstructure then changes as follows.

Illustration 152: Structure of the choice in scenario 2 (local information)

In contrast to the example above, the passenger identifies the next departure times of line 2directly after getting off at stop A. The passenger is thus able to determine exactly what the waittime and the remaining journey time will be, if he continues his journey from there. Comparedto 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 outwhich connections are available from stop A. The decision tree then looks as follows.

4 54 54 54 654

1

2

?

Alight

B C

Change

443 © PTV AG


Illustration 153: Structure of the choice in scenario 3 (information in the vehicle)

The characteristic of the first decision now changes, because continuing the journey with line1 and a transfer to line 2 or 3 now represent alternatives on the same level, as all wait timesare known.

Comparison of the calculated sharesIt is informative to know what influence the applied choice model has on the shares of the linesand the mean remaining costs. Let us take the following definition of generalized costs tosimplify the calculation.Costs = 1.0 • In-vehicle time + 1.0 • Walk time + 1.0 • Wait time + 1 min • Number of transfersTravel times and headways of the lines in the example network are illustrated in Table 156.

The passenger's situation on board line 1 arriving at stop A is interesting, because there areseveral transfer options which assure a shorter remaining journey time. Table 157 shows, thatthe passenger can derive a much bigger advantage from these transfer alternatives, the moreinformation he has on the arising wait times.

Line Run time Headway

1 Start -> A 5‘A -> Destination 8‘

10‘

2 3‘ 15‘

3 5‘ 5‘

4 4‘ 5‘

5 3‘ 10‘

Table 156: Travel times and headways of the lines in the example network

4 54 54 54 654

1 2

?

Alight

B C

444 © PTV AG


The mean costs in the last row refer to the entire route. The difference between scenario 1 and 2 is very small, because information on departures atthe local stop is only an advantage if thereby one is able to ignore a line with a longer journeytime in favor of a more appropriate line arriving shortly after. In this network, this case onlyoccurs with a low probability – and only at stop B.If the same information is already provided on board (scenario 3), the shares of the individuallines 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 ondeparture times are not only provided for the local lines of a stop, but for all the lines of all stopsnearby (scenario 4). From the resulting relatively large set of possible lines, the passenger canchoose the line with the least remaining journey time. The effect becomes more clear if thepassenger can already make such a decision on board line 1 (Scenario 5). The mean costssavings in this example equals 1‘39 minutes - which means considerable 14 percent on thispath leg from A to destination.

6.9.6 The search in generalThe travel demand of an OD pair is entered at the origin zone. Several alternatives havingdifferent 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 allreasonable alternatives. How this happens exactly depends on the choice model used (see"Choice models for boarding decisions" on page 434 and "The complete choice model" onpage 440).Stochastic fuzziness becomes involved here in that all used lines possess a headway and thewait time for a line is thus random. Even a line which is less attractive due to its largerimpedance can be given a certain percentage of the demand. If passenger information ondepartures is available, this may occur exactly then for example, if the line with positiveprobability departs so much earlier than other, qualitatively better alternatives that this timeadvantage makes up for with its higher impedance.As a result of this fundamental model assumption, the route search in the headway-basedassignment is not based on shortest path searches, but creates a directed decision graph foreach destination zone. Stops at which passengers are provided with several alternativesrepresent the nodes of this decision graph, known as decision points. The paths in this graphrepresent the various options to reach the destination zone.

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5

Share of Line 1 [%] 60.1 59.7 32.3 45.4 28.2

Share of Line 2 [%] 9.0 9.0 11.7 13.8 22.7

Share of Line 3 [%] 10.3 6.8 12.1 9.6 9.2

Share of Line 4 [%] 10.3 14.4 25.7 22.4 27.6

Share of Line 5 [%] 10.2 10.2 18.2 8.8 12.4

Mean Costs [min] 18‘39 18‘38 18‘20 17‘36 17‘00

Table 157: Line shares and the mean costs depending on the information available

445 © PTV AG


The decisive factor is the assumption that, from the various options available, the passengerswill make their choice for the continuation of their journey at each stop on the basis of thisprobability 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 passengersto move from the stops of the network towards the destination zone. The mean impedances ofthe decision points for which a distribution has already been calculated are then used for theiterative 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 areloaded in the decision graph), which are positively assessed by the selected choice model. Inthe case of passenger information, this means that a path at each traversed decision point isprobably the best option amongst all available alternatives. Similar statements apply for theother choice models.Optionally, all dominated paths can be singled out from these. A path is dominated by anotherpath if it applies to the same OD pair, uses the same sequence of time profiles (in the sameorder), has the same start stop and end stop, yet has a longer total journey time (usually dueto the selection of less convenient transfer stops).

6.9.7 Example for the transport system-based assignmentHeadway calculationFor the PuT supply displayed in illustration 154 the headway-based procedure determines theheadways for the analyzed time interval from 5:30 a.m. to 7:30 a.m. (120 minutes) illustratedin Table 158 – if these are calculated according to the method from mean headway (see"Headway calculation" on page 432).

Route searchThe case is, that passenger information on departure times exists and is also available onboard of the bus line. At route search, the procedure then determines two routes from A-Villageto X-City, if each of the two alternatives is with (even low) positive probability better than therespective 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 withina range of between 0 and 60 minutes and no fixed transfer time has been assumed in advance.If no extremely high transfer time penalty is used, some of the passengers will certainly use thetransfer option. This is because the train will leave (with a certain level of probability) onlyshortly after the bus arrives and the passengers will thus arrive at their destination morequickly.

Line Mean follow-up time Headway

Bus 1 120 / 3 * = 40 min 40 min

Train 120 / 2 ** = 60 min 60 min

* 3 departures in analyzed interval (6:10, 6:55, 7:25) from A-Village** 2 departures in analyzed interval (6:25, 7:05) from Station

Table 158: Headway calculation for the example

446 © PTV AG


Because the probability of obtaining an unfavorable connection in this case is significantlyhigher, 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, thisis 30 minutes – but the complete range of possible wait times. Due to the existing passengerinformation, each of the two routes thus receives precisely that portion of the demand thatcorresponds to the chance of being the better of the two options.

Route ChoiceIn order to determine a distribution in the example given, specific impedance parameters haveto be used. These are set as follows.• Imp = PJT • 1.0 + number fare points • 0.0• Perceived journey time PJT = in-vehicle time • 1.0

+ Access and egress time • 1.0+ Walk time • 1.0+ Origin wait time • 1.0+ Transfer wait time • 1.0+ Number of transfers • 2 min

In this way, the impedances listed in Table 159 are calculated for a passenger arriving at therailway station on Bus 1 for the remaining route legs.

From the impedances Imp1 and Imp2, the following percentages P1 and P2 of the OD demand(in this case: 90 trips) result and thus the absolute number of trips on both routes (M1 or M2).This occurs as follows.The decision as to which of the routes is more attractive depends on whether the randomvariable Imp2 is greater or smaller than the constant variable Imp1. Because Imp2 is uniformlydistributed in the interval [18, 78[ and Imp1 is equal to 33, the probability for choosing Route 2is thus 0.25 according to the formula below.

This means that 90 • 0.25 = 22.5 passengers decide to travel by train and 90 • 0.75 = 67.5passengers to continue their journey by bus.This results in the volumes shown in illustration 154.

Route 1 Route 2

Egress time, walk time 0 min 0 min

Run time 33 min 16 min

Transfer wait time 0 min randomly in [0 min, 60 min]

Transfer time penalty 0 • 2 min = 0 min 1 • 2 min = 2 min

IMP = PJT • 1.0 33 min randomly in [18 min, 78 min]

Table 159: Impedance calculation for the routes in the example

25.06015

18781833

==−−

447 © PTV AG


Illustration 154: Volume for headway-based assignment, transfer penalty 2 min

With any variation in the transfer penalty, this portion changes as shown in Table 160. Forother impedance parameters, the same applies.

The indicators for the relation between A-Village and X-City are shown in Table 161. Thesevalues are mean indicators of both routes which – weighted with the number of passengers ofeach route – are summarized for the impedance parameters used here.

Please pay particular attention to the transfer wait time of 7.5 minutes for Route 2. In this case,the figure is not 60 / 2 = 30 minutes even though the train's headway is 60 minutes. This is dueto the fact that passengers will only take the train if the transfer wait time is short enough – tobe precise, when this time (as seen above) is within a range of zero and 15 minutes. In allother cases, there is no benefit in transferring. The 7.5 minutes transfer wait time in the choiceof Route 2 therefore represents a conditional expectancy value – it is the mean wait time forthose passengers for whom Route 2 is in fact the best alternative.

Transfer time penalty Portion of Route 1 Portion of Route 2

0 min 0.717 0.283

1 min 0.733 0.267

2 min 0.750 0.250

5 min 0.800 0.200

10 min 0.883 0.117

Table 160: Changes to shares with variation of the transfer penalty

Route Set Pass. • In-veh. time Pass. • TWT Pass. • Ride time Pass. • NTR

1 67.5 67.5 • 45 min 67.5 • 0 min 67.5 • 45 min 67.5 • 0

2 22.5 22.5 • 28 min 22.5 • 7.5 min 22.5 • 35.5 min 22.5 • 1

Total 90 3667.5 min 168.75 min 3836.25 min 22.5

Mean 3667.5 / 90= 40.75 min

168.75 / 90 = 1.875 min

3836.25 / 90 = 42.625 min

22.5 / 90 = 0.25

Table 161: Mean indicators for the headway-based assignment

90

23

67 67

Station X-City

A-Village

B-Village

448 © PTV AG


6.9.8 CoordinationIn VISUM, the coordination can be used for the headway-based procedure. This is realized byso-called coordination groups.

6.9.8.1 Function of coordination groupsA 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 aconsequence, the relevant line bundle is treated at the shared stops throughout the entireprocedure as a single line that operates with greater frequency. This results in a shorter meanwait time than is the case with the (by default) assumed stochastic uniform distribution of therelative position of the lines to each other.A coordination group is a bundle of time profiles on a conjointly used passage. Two stops markthe boundaries of the section. The significance of a coordination group lies in the calculation ofthe mean wait time in the context of the headway-based assignment. In this assignmentprocedure, it is usually assumed that the time interval between departures on different lineroutes (strictly speaking: time profiles) is coincidental. With the aid of coordination groups, youcan display that certain line routes run in a rhythm of equal intervals to the advantage of thepassengers – just like it is often the case in real life.

Please note that splitting up a line into two new lines, each with half the supply, does thereforenot lead automatically to the same result in calculation. It must not be assumed in advancethat a coordination exists. Coordinations have to be explicitly specified. illustration 155 showsan example.

Illustration 155: Coordination of lines

Considering only the red-blue line, a passenger arriving randomly has a mean wait time of 5minutes – precisely half the headway.

Note: In the timetable-based assignment, coordination groups bear no meaning as departuretimes can be gathered from the timetable here. In contrast, the headway-based assignmentcalculates with average wait times only. Coordination groups come into play when it ought tobe expressed that those wait times are shorter than those arising from a coincidentalarrangement of the line routes.

H e a d w a y H 2 = 2 0 m in

H e a d w a y H 1 = 2 0 m in

H e a d w a y H = 1 0 m in1 2

b lu e

re d

re d -b lu e

449 © PTV AG


If this line is split up into a blue and a red portion without defining a co-ordination, a mean waittime of 6:40 minutes results after the headway calculation. This is the expected value of theoffset to the next departure of one of the two lines – and, depending on the relative position ofthe 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 blueline remains constant at 10 minutes. As in the initial situation, this results in a mean wait timeof 5 minutes.

6.9.8.2 Matched transfersThe transfer time between two lines at a stop is normally a combination of the transfer walktime taken from the transfer walk time matrix (see User Manual, Chpt. 2.23.2, page 328) andthe random wait time for a trip of the successor line. This results from the fundamental modelassumption that passengers a priori have no information on the exact departure times of thelines, 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 notstochastic, but assumes a fixed value. This is particularly important in networks with longerheadways, in which the existence of coordinated connections is nevertheless assumed.In this case, for a pair of time profiles at a stop, a so-called matched transfer can be defined.Transfers from one time profile (see User Manual, Chpt. 2.23.2, page 328) to the other thenrequire precisely the specified duration each time (see User Manual, Chpt. 6.2.3.2, page 958).

6.9.8.3 Example for the coordinationFor a passenger, a single line route with headway of 20 minutes means a mean wait time of 10minutes. Whether the introduction of a second line route of the same headway means that thewait time will be reduced to 50% depends on its concrete temporal position. A sequence like8: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 assumesthat 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, allpositions in the timetable are considered equally probable. The expected value for the waittime 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 bundlestops at a stop, only the time profiles that stop are considered coordinated at that stop.

If there is an overlap between the coordination groups to be defined, only the first coordinationgroup of each time profile item is considered. In this case, a warning is triggered at thebeginning of the assignment.

Note: The coordination of time profiles ends at the ToStop, that is, the arrival times of the timeprofile are still coordinated at that stop but the departure times are not.

Note: If a network-wide coordination is assumed for a headway-based assignment, optionCoordination everywhere can be used during the assignment. Coordination groups arethen redundant.

450 © PTV AG


6.9.8.4 Assume coordinated time profiles to be undistinguishableFor identical headways, the coordination's mechanisms of action is clearly defined. Sincecoordination groups can be defined for arbitrary time profiles in VISUM, however, there is notalways 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 timeprofiles in a coordinated bundle and also make their choice against attributes of the respectivetime profile.The new approach, which is realized in the program via the option Assume coordinated timeprofiles to be undistinguishable, is based on the following algorithm. Ti are the headways ofthe 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/3which 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 446 and "Route Choice" onpage 447), the virtual aggregate time profile m* with headway T and impedance C iscompared with the other time profiles

Model approachHere, the general assumption is that the time profiles in the coordinated time profile bundlesare 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 usedas demand share per time profile. Passengers that cannot differentiate between the differenttime 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 thealternative's number of services.Furthermore, the aggregate impedance is defined as the weighted mean of the single timeprofiles’ impedances, this time using the service frequency shares βi as weights. This makessense because the resulting aggregate is the mean impedance of all services. For thepassenger, this is the expected impedance when boarding the first available service of the TPbundle.

ExampleThe 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 46seconds. The aggregate impedance is C = 22.77. This value is much larger than before sincethe high-impedance time profile 1 plays a more significant role now.

451 © PTV AG


6.10 Timetable-based assignmentA search method is called timetable-based if all services of PuT lines are taken into accountwith their precise departure and arrival times.Timetable-based methods are suitable for assignments and the calculation of indicators, whena line network plan and a detailed timetable are available for the PuT supply analyzed. Theytake the coordination of the timetable into account and thus ensure very precise results of theindicator data calculation.The timetable-based method calculates connections for each OD pair. In the Search it isassumed that the passengers have timetable information available and choose their accesstime according to the departure on the first PuT line. During the search, the user can influencethe kind of connections found in different ways by means of search impedance. For theconnection search, two variants (branch & bound search and shortest path search) are offeredthat represent the different compromises between the number of alternatives on the one handand the memory and computing time requirements on the other.During preselection of connections, the connections yielded by the search algorithm are re-analyzed by means of general criteria as to whether some of them are of a significantly lowerquality and can thus be deleted.During the choice, the demand is distributed to the remaining alternatives based on one of themodels described above. The independence of connections can be taken into account ifrequired.

6.10.1 Evaluation of the timetable-based assignmentThe timetable-based assignment is characterized by the following features.• Using the branch & bound option (see "The variant Branch and Bound" on page 453), the

procedure calculates all suitable connections throughout the entire analysis period. Thisalso includes the calculation of several connections with different impedances (for exampleshortest time and minimum transfer connections) for a departure time. In the case of amonocriterion shortest path search (see "The variant Shortest path search" on page 454),only one connection is calculated for each departure time, as this reduces the memory andcomputing time requirements. The search can be influenced by means of the searchimpedance definition.

• Branch & Bound search is suitable for the analysis of a period (see "The variant Branch andBound" on page 453) - for example the whole day or several hours. When performing asearch at a specific time (e.g. in the case of a graphical route search), the shortest pathsearch is recommended (see "The variant Shortest path search" on page 454).

TP Impedance Headway

Distinguishable (Standard) Undistinguishable

1 24‘ 1‘ 0.0166 0.7692

2 20‘ 5‘ 0.3366 0.1538

3 16‘ 10‘ 0.6466 0.0769

452 © PTV AG

Chapter 6.10: Timetable-based assignment

• The actual transfer wait time, and thus the coordination of the timetable, is taken intoaccount.

• All indicators in the analyzed time interval can be calculated.• The decision model for the connection choice (see "Connection Choice" on page 458)

models the actual decision behavior of the passengers realistically, because a passengerusually has some information on the PuT supply (connection search) and then makes hischoice from the connections offered (connection choice).

6.10.2 Connection searchFor the connection search, two variants are provided.

6.10.2.1 The variant Branch and BoundFor each origin zone, a search tree of suitable partial connections is generated which stores allsufficiently suitable connections from this origin zone. This means that not only the bestconnection is found for an OD pair, but a large number of good connections. In this way, a veryselective distribution of travel demand is possible.• A search impedance is used in order to evaluate the quality of connections. For all (partial)

connections found in the search, the search impedance is calculated using the followingequation.SearchIMP = JRT • FacJRT + NTR • FacNTR + TSys-Imp • FacTSys-Imp + VehJ-Imp •FacVehJ-Imp

• In addition to the journey time and the number of transfers, the equation includes faresclassified on the basis of the transport system in TSys-Imp, that is the influence of fares canalready be taken into account during the search. Via VehJ-Imp, also the vehicle journey-specific impedance is added. It results from two freely selectable attributes of the vehiclejourney items – as boarding supplement and as general discomfort term. In this way,individual vehicle journeys can be favored or penalized.

• For the evaluation of a newly found (partial) connection to a destination or a transfer node,the following rules apply. The new partial connection is deleted if the following applies (see"Bounding" on page 454).• Search impedance of the connection > minimum search impedance • factor + constant,

or• Journey time of the connection > minimum journey time • factor + constant, or• Number of transfers of the connection > minimum number of transfers + constant.

• These rules ensure that inconvenient partial connections can be eliminated while thesearch is progressing.

• It is possible to specify an upper limit for the number of transfers in a connection.

DominanceComparisons of connections in pairs help searching as efficiently as possible. This is feasibleif a connection is already found which fulfils both criteria.• It is temporally encompassed by the option.• It is not worse in any qualitative aspect.The previous definition of dominance was:

453 © PTV AG


A connection c’ dominates a connection c, if • c’ lies within the time interval of c• NTR(c’) ≤ NTR(c)• Imp(c’) ≤ Imp(c)• Real inequality applies to one of the three criteria above.This results in the following changes in the definition of dominance.• For comparisons of two connections without a defined temporal position, rule 1 changes to

RideTime(c’) ≤ RideTime(c). The other rules remain unchanged. Thus still applies for example: NTR(c) = Rounding up ((NumLegs(c) – 1) / 2 ).

• New connections with a departure time are always compared with all connections that donot have a departure time. Dominance may exist in both directions.

• New connections with PuTAux yet without a departure time are always compared with allother connections. Dominance may exist in both directions. This distinguishes theseconnections from pure walk links which cannot be dominated themselves as their numberof transfers is optimal.

BoundingFor the evaluation of a newly found (partial) connection to a destination or a transfer node, thefollowing rules apply. The new partial connection is deleted if the following applies.• Search impedance of the connection > minimum search impedance • factor + constant, or• Journey time of the connection > minimum journey time • factor + constant, or• Number of transfers of the connection > minimum number of transfers + constant.These criteria are not applied in pairs but always regarding the optimum to a destinationdetermined so far. As a basic principle, no connections are deleted that are optimal themselvesin any dimension – even if they break the rule in another dimension.No changes occur since SearchImp, journey time and NTR are also defined when PuTAux isused.

6.10.2.2 The variant Shortest path searchThis option uses the "best" route search strategy on the basis of the particular time of departureand the time of arrival. A shortest-path algorithm based on this data calculates the bestconnection between two traffic zones for a particular departure time. For different times ofdeparture, various "best" connections may be calculated which may differ by the used PuTlines and/or transfer stops. To determine all "best" connections within the analyzed timeinterval the shortest path algorithm is performed several times for all possible departure timeswithin the analysis time interval.Since in some cases several connections are possible for a given time of departure, a definitionof "best connection" is required for these search procedures. For this purpose VISUM providesan impedance function which increases the impedance of a connection for each transfer by thetransfer penalty. A low penalty has the result that connections which take the least time arefavored, while a high transfer penalty gives priority to connections with a lower number oftransfers.

454 © PTV AG


• Determination of all possible start times for trips which originate in traffic zone i. The starttimes result from the departure times of PuT lines at stops which can be reached from zonei via a connector.In the example, the start times correspond with the departure times of bus line 1 from A-Village (6.10, 6.55, 7.25), because A-Village is only serviced by one bus line and an accesstime 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 identifiesthe path with the lowest impedance as the best path. The impedance of the path ismeasured 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 linesand the exact departure and arrival times at boarding stop, transfer stops, and alightingstop are known.

• Or the connection with the minimum journey time (so-called bicriterion shortest pathsearch) 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 differentnumbers of transfers, the program only stores the connection with the lowest number oftransfers (dominance).

6.10.3 Connection preselectionThe preselection of connections compares and evaluates all found connections. This includesthe check, whether a connection could be replaced by a more suitable one and thus can bedeleted. Only convenient connections are offered to the passengers for the connection choice.In order to identify inconvenient connections, the following exclusion rules are applied in turn.• Search impedance of the connection > minimum search impedance • factor + constant, or

(no limitations; just branch & bound)• Journey time of the connection > minimum journey time • factor + constant

(unless the connection is optimal with respect to the number of transfers)• Number of transfers of the connection > minimum number of transfers + constant

(unless the connection is optimal with respect to the journey time)The factors and constants can be set by the user.

6.10.4 Perceived journey time PJT of a connectionThe impedance is a linear combination of perceived journey time (see "Perceived journey time"on page 456), fare, ΔT(early) and ΔT(late). ΔT(early) and ΔT(late) thus express the temporalutility of a connection (see "Temporal utility of a connection" on page 457).

455 © PTV AG


6.10.4.1 Perceived journey timePJT [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 • FacNTR+ Number of operator changes • FacNOC 1+ Extended impedance • Factor

Notes• PuT-Aux time

The time spent in a transport system of the PuT-Aux type enters the PJT as a separatevalue and can be weighted by any transport system attribute. It is furthermore required asa skim value.

• Modeling Bonus and MalusThe in-vehicle time can be multiplied by an attribute of the vehicle journey items (and thePuT-Aux time by a TSys attribute respectively) in order to model the vol/cap ratio (forexample the availability of seats) or other aspects of usability (for example the level ofcomfort).

• Number of transfersThe PuT line TSys and the PuT-Aux TSys enter the calculation of the number of transferson a par.

• Number of operator changesOperator changes cannot occur due to PuT-Aux path legs.

Origin wait timeWith the following equation, the origin wait time, OWT, can be determined from the servicefrequency 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 istherefore just like a constant supplement. The OWT output as a skim matrix, however, can beimportant for the network analysis.

Transfer wait timeThe transfer wait time models smooth transfers in zero time or slightly more than zero time.

456 © PTV AG


The extended transfer wait time models that transfers are ideal not in zero time (or slightlymore) but if they take a few minutes. A lot of timetable information retrieval systems also do notoffer connections that contain "smooth" transfers.With the extended transfer wait time, the user can also "penalize" transfers in VISUM that aretoo short. For this, the program uses a non-linear function which calculates a weighted waittime that depends on the user-defined ideal transfer wait time, which then enters the perceivedjourney time. Instead of the regular transfer wait time, the extended transfer wait time can enterthe PJT calculation. But it can also be saved as a separate skim.The used weighting function f takes the following shape. • As an argument, the actual transfer wait time t is set, which is the time that passes between

the arrival of the passenger at the stop point and the departure of the service trip.• The weighted wait time f(t) is thus defined as

• (t - t0)n + c, falls 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 thedifferentiable composition of both parts of the function at position t1.

• Essential is: t0 is the transfer wait time considered ideal. For the extended transfer waittime, this variable may depend on the required walk time and thus needs to beparameterized 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 positiont = t0.

Around t0, f(t) increases symmetrically.

If t increases, function f(t) approaches the linear asymptote t.• ExampleBy 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 theseparameters.• 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 connectionIn the timetable-based method, the temporal utility of a connection is modeled as follows.

457 © PTV AG


• ΔTaiEarly = amount of time that connection i departs earlier than desired for departure

interval a (→ time series); equals zero, if i departs within a or after a.

• ΔTaiLate = amount of time that connection i departs later than desired for the departure

interval a (→ time series); equals zero, if i departs within a or before a.

• ΔTaiEarly • FacΔTearly + ΔTa

ilate • FacΔTlate = temporal distance between connection i and

intervall a. The first factor controls the sensitivity of passengers towards earlier departures,the second the sensitivity towards later departures.

This temporal distance is included as a further summand in the definition of impedance, inorder to impede lower utilities.

Table 162 shows an example for the calculation of ΔTearly und ΔTlate in the time intervall [06:00AM;07:00 AM].

6.10.4.3 FareIf a zone-based ticket type is used, PuT-Aux path legs are disregarded. Distance-based tickettypes are evaluated analogously to PuT-TSys because fare points can also be assigned toPuT-Aux (see "Revenue calculation using the fare model" on page 597).

6.10.5 Connection ChoiceThe connection choice distributes the demand of a relation onto the found connections. Inorder to do this, the connection impedances are calculated; they include the perceived journeytime PJT, the fare and the temporal utility of a connection (see "Perceived journey time PJT ofa connection" on page 455). For the distribution models, these impedances serve as an inputfor calculating the shares of the connections in the travel demand (see "Distribution models inthe assignment" on page 289). The independence can also be included in the distribution rule,if required (see "Independence of Connections" on page 460).

Note: For connections with no temporal position, ΔT is always zero

Departure ΔT ΔTearly ΔTlate

5:30 30 30 0

6:00 0 0 0

6:40 0 0 0

7:00 0 0 0

7:10 10 0 10

Table 162: Calculation of the temporal distance

ΔTearly := { desired dep.Time – actual dep.T if actually < desired, else 0

ΔTlate:= { actual dep.Time – desired dep.T if actually > desired, else 0

458 © PTV AG


6.10.5.1 Distribution of trips onto connectionsThe impedance of a connection i used in the connection choice in a time interval a is calculatedas follows.

Optionally, each parameter which is input in the impedance can be individually Box-Coxtransformed. This does not affect the actual choice model. Any utility function can thus still beapplied to the total impedance even when using the BoxCox transformation.The impedance calculation is not linked to the actual connection choice, that is, even whencalculating the BoxCox transformation, Logit does not necessarily have to be used. Any otherutility 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 restrictionsare to be BoxCox-transformed (namely each into parameter λi). βi stands for the respectivecoefficient. Then the following applies

where

By including this impedance in one of the distribution models Kirchhoff, Logit, Box-Cox orLohse (see "Distribution models in the assignment" on page 289), VISUM then determines theutility of a connection in a given time interval and ultimately its percentage of the demand forthis interval. The independence can also be included in the distribution rule, if required (see"Independence of Connections" on page 460).As before, the proportion of a connection i of the total demand is calculated as follows.

Here, g is the selected utility function (always antitonic). In the case of Logit thus appliesg(x) = e-bx.

IMP = PJTi • FacPJT + Fare • FacFare + T aiΔ early • FacΔTearly + T a

iΔ late • FacΔTlate

( ) ∑∑+=

+=

=n

1miixi

m

1iixifiiW ββ

( )⎪⎪

⎩

⎪⎪

⎨

⎧≠

−

==0

1x

0xlogxifi

i

i

i

λλ

λ

λ

( )( ) ,

jjWg

iWg:ip

∑=

459 © PTV AG


6.10.5.2 Independence of ConnectionsAll distribution models (see "Distribution models in the assignment" on page 289) presentedcannot, in their basic form, take into account interactions between different connections in atimetable-based assignment. However, ignoring this aspect can be a drawback.In order to model interactions, one defines functions wi, which describe the impact of otherconnections on a connection i. The value range of wi is the interval [0.1]. If j has no impact oni, 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

• The advantage of i over j in terms of the perceived journey timeyi(j) := PJTj - PJTi

• The advantage of i over j in terms of the farezi(j) := Fj - Fi

Thus, wi is defined as follows.

,

where and s > 0 are internal parameters for controlling the influence of the three values. c is a constant thatcontrols 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 zeroand 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 themaximum temporal advantage or disadvantage of i, in which j can possibly have an impact.

Notes: As can be seen from the definition, when using the BoxCox transformation for xigenerally xi ≥ 0 needs to apply. In case of λi = 0, even xi > 0 needs to be true. If this rule isviolated during the run time, the assignment is terminated with an error message.Due to a BoxCox transformation or caused by negative coefficients, Wi itself can be negative.In that case, only the Logit utility function can be used, otherwise the assignment isterminated with an error message.

( )2

iANKjANKiABFjABFjix

−+−=

( ) ( ) ( ) ( )⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

⎪⎭

⎪⎬⎫

⎪⎩

⎪⎨⎧

⋅

⋅+⋅⋅−⋅

+

⎟⎟⎠

⎞⎜⎜⎝

⎛−=

zsysjizysjiyzs

,1minc1xsjix1:jiw

( )( )

⎪⎩

⎪⎨⎧ ≥

<=

+

−0

0:

jyifs

jyifsys iy

iy ( )( )

⎪⎩

⎪⎨⎧ ≥

<=

+

−00

: jzifsjzifs

zs iz

iz

460 © PTV AG


With regard to the fare, the same applies to sz. The default setting leads to the following

relation: sy- = 2sy

+ and sz- = 2sz

+. As a result of this asymmetry, in the case of two connectionswith temporal proximity, the better is favored, because its influence on the worse alternative isgreater than vice versa. In principle, users should always specify Independency coefficients forhigh 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 messagein the window).Overall, the following applies:sx = min (2 • mean wait time of a random passenger between the first and the last departure, maximumtime 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

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:

Here, n is the total number of connections.

Distribution models with independenceIf independence is used for connection choice, then this attribute must be integrated in thedistribution model. In the version described above, for each time interval a the utility Ui

a of aconnection i was calculated. From this, its percentage in terms of the demand was determinedper time interval. If independence is applied, Ui

a • EIGi replaces Uia, i.e. the following applies.

This linear dependence on the independence attribute ensures that k simultaneous, identicalalternatives are treated as a single connection. According to the definition of IND, theindependence of each of such k alternatives is precisely 1 / k (if no other connections withtemporal proximity have an effect). As a result, the total of its weights in the distribution formulais equal to the weight of a single, non-multiplied connection of the same kind.

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

( ) ( )∑∑≠=

+

=

=

= n

ij,1jjiw1

1n

1jjiw

1:iEIG

∑=

⋅

⋅= n

1jjEIGa

jU

iEIGaiUa

iP

461 © PTV AG


Comparison of the distribution models with independenceIn Table 164 to Table 167 the different distribution models are compared with each other, withand without independence. The procedure parameters are chosen as in Table 163.

Connection data that differs from the respective previous example is highlighted by bold typein Table 164 to Table 167 . All assignment shares are given as percentages.

Kirchhoff β = 4

Logit β = 0.25

Box-Cox β = 1 and τ = 0.5

Lohse β = 4

PJT formula PJT = JT + 2 • TWT + 2 • NTR

IMP formula IMP = PJT + 4 • fare

IND parameter c = 1

Table 163: Procedure parameters for the comparison of the distribution models

Connection data Distribution without IND Distribution with IND

No. Dep Arr

PJT

Fare

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

1 10 30 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3

2 30 50 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3

3 50 70 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3

Table 164: Example 1 – Initial situation


No. Dep Arr

PJT

Fare

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e1 10 30 20 3.00 25 25 25 25 33.3 33.3 33.3 33.3

2 30 50 20 3.00 25 25 25 25 16.7 16.7 16.7 16.7

3 30 50 20 3.00 25 25 25 25 16.7 16.7 16.7 16.7

4 50 70 20 3.00 25 25 25 25 33.3 33.3 33.3 33.3

Table 165: Example 2 – Isochronous, identical pair of connections


No. Dep Arr

PJT

Fare

Kirc

hhof

f

Logi

t

Box-

Cox

Lohs

e

Kirc

hhof

f

Logi

t

Box-

Cox

Lohs

e

Table 166: Example 3 – Identical pair of connections with high temporal proximity

462 © PTV AG


The fact that, without IND being applied the connections 1, 2 and 4 have the same number ofpassengers in all cases shows, that the interactions between different alternatives ought tobe taken into account to a higher degree in this case. It becomes apparent that then betterresults are achieved with all distribution models.

6.10.5.3 Example for the connection choiceThe effect of the connection choice for the timetable-based method is shown with the results ofthe connection search regarding a 10-minute transfer penalty. The branch & bound search isused. This search returns the five connections shown in Table 168. A monocriterion shortestpath search however would only find the connections 1, 3 and 5, as they have the lowestimpedance of all the connections of their departure times. The impedance (= perceived journeytime) results from the weighted sum of the following skims: journey time (JRT), transfer waittime (TWT) and number of transfers (NTR).

1 10 30 20 3.00 25 25 25 25 32.7 32.7 32.7 32.7

2 30 50 20 3.00 25 25 25 25 17.3 17.3 17.3 17.3

3 32 52 20 3.00 25 25 25 25 17.3 17.3 17.3 17.3

4 50 70 20 3.00 25 25 25 25 32.7 32.7 32.7 32.7


No. Dep ArrP

JTFare

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

1 10 30 20 3.00 25.9 26.7 26.2 25.1 31.9 32.6 32.2 31.2

2 30 50 20 3.00 25.9 26.7 26.2 25.1 20.2 20.7 20.4 19.8

3 32 47 20 3.30 22.3 19.8 21.3 24.6 16.0 14.1 15.2 17.8

4 50 70 20 3.00 25.9 26.7 26.2 25.1 31.9 32.6 32.2 31.2

Example 4 – Similar pair of connections with high temporal proximity (connection 3 now includes transfer)


No. Dep Arr

PJT

Fare

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

Kirc

hhof

f

Logi

t

Box

-Cox

Lohs

e

1 10 30 20 3.00 23.5 21.9 22.8 24.6 26.5 24.9 25.8 27.7

2 30 50 20 3.00 23.5 21.9 22.8 24.6 20.1 18.9 19.6 21.0

3 32 44 17 3.30 29.6 34.3 31.5 26.1 26.9 31.4 28.7 23.6

4 50 70 20 3.00 23.5 21.9 22.8 24.6 26.5 24.9 25.8 27.7

Table 167: Example 5 - Differing pair of connections with moderate temporal proximity


Table 166: Example 3 – Identical pair of connections with high temporal proximity

463 © PTV AG


Table 169 shows the impedances of the connections. As ΔT depends on the desired departuretime of the passengers, different impedance values result for the various time slices of traveldemand. 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 impedancedefinition is set in such a way, that the following applies:

Ria = PJTi • 1.0 + ΔTi

aearly • 1.0 + ΔTialate • 1.0

A distribution rule (here Kirchhoff with β = 3) is then used to calculate the shares Pia which are

allocated to the individual connections. The independence is ignored in this formula. As shownin Table 170, all five connections are assigned non-zero percentages of the travel demand pertime interval.

Conn. i Dep JRTi TWTi NTRi PJTi = JRTi + TWTi • FacUZ + NTRi • FacNTR

1 6:10 28 min 3 min 1 28 + 3 • 2 + 1 • 2 = 36

2 6:10 45 min 0 min 0 45 + 0 • 2 + 0 • 2 = 45

3 6:55 45 min 0 min 0 45 + 0 • 2 + 0 • 2 = 45

4 7:25 28 min 8 min 1 28 + 3 • 2 + 1 • 2 = 36

5 7:25 45 min 0 min 0 45 + 0 • 2 + 0 • 2 = 45

FacTWT = 2, FacNTR = 2

Table 168: Result of connection search (transfer penalty 10 min, parameter file TIMETAB1.PAR)

Conn. i Dep ΔTi1

5:30-6:30ΔTi

2

6:30-7:30Ri

1

5:30-6:30Ri

2

6:30-7:30

1 6:10 0 min 20 min 36 + 0 = 36 36 + 20 = 56

2 6:10 0 min 20 min 45 + 0 = 45 45 + 20 = 65

3 6:55 25 min 0 min 45 + 25 = 70 45 + 0 = 45

4 7:25 55 min 0 min 46 + 55 = 101 46 + 0 = 46

5 7:25 55 min 0 min 45 + 55 = 100 45 + 0 = 45

Table 169: Temporal distances ΔT and impedances R of the connections for the two analyzed intervals oftravel demand

Conn.i Dep Pi1

5:30-6:30Pi

2

6:30-7:30

Vehicle journeys Mi

1

5:30-6:30

Vehicle journeys Mi

2

6:30-7:30

Σ Trips5:30-7:30

1 6:10 57% 13% 30 • 0.57 = 17 60 • 0.13 = 8 25

2 6:10 30 % 8% 30 • 0.30 = 9 60 • 0.08 = 5 14

3 6:55 7% 27% 30 • 0.07 = 2 60 • 0.27 = 16 18

4 7:25 3% 25% 30 • 0.03 = 1 60 • 0.25 = 15 16

5 7:25 3% 27% 30 • 0.03 = 1 60 • 0.27 = 16 17

Table 170: Distribution of trips to the connections (Kirchhoff, β = 3)

464 © PTV AG


This results in the volumes shown in illustration 156.

Illustration 156: Network volume for timetable-based assignment (parameter file timetab1.par)

6.10.6 Handling of public transport systems of the PuT-Aux typeThe following applies for transport systems of type PuT-Aux.• They are considered in the timetable-based assignment and also via the menu Graphic >

Shortest path.• They are convenient for modeling inferior transport supply without timetables. These are for

example• Park & Ride• Local public transport with dense headway within a network that is otherwise timetable-

based• Taxis

• They are only relevant on links and turns. By defining permissions of PuT-Aux TSys tothese objects, the subnetwork which is enabled per PuT-Aux TSys is defined. Thisinformation 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 ofdemand 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 transportsystem is permitted. These nodes need to be accessed by walk links however, or be directlyconnected to a zone or stop area.During the assignment, a change to a PuT-Aux path leg counts as a transfer.The extended modularized procedure can be used for example, to export and import fares(see "Opening of the timetable-based assignment" on page 466)

S 100 % 100 % 30 60 90

Conn.i Dep Pi1

5:30-6:30Pi

2

6:30-7:30

Vehicle journeys Mi

1

5:30-6:30

Vehicle journeys Mi

2

6:30-7:30

Σ Trips5:30-7:30

Table 170: Distribution of trips to the connections (Kirchhoff, β = 3)

90

41

49 49

Station X_city

A_village

B_village

465 © PTV AG


Pre-calculation of path legsThe set of PuT-Aux TSys permitted in an assignment directly affects the path legs to becalculated because every start node of PuTAux paths represents a potential target of PuT walklinks. This is taken into account when pre-calculating the walk links and PuT-Aux paths.Adjustment of the connection searchAnalogous to walk links, a path leg is created for each PuT Aux path. In any case, the trivialPuT-Aux transfers at nodes appear as individual path legs in any case. Path legs are sortedseparately 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 referenceto 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 bytransport system are clearly defined. In particular the link attributes Imp/km, Imp/FarePointand Imp/AddVal are available for PuT-Aux TSys.

6.10.7 Opening of the timetable-based assignmentFor some projects particularly in connection with demand modeling (see "Demand model" onpage 103)a (time-consuming) timetable-based assignment is carried out several times withinthe same process.

ExampleFirst of all PuT skims are determined, then the mode choice is made and finally the actual PuTassignment is conducted. As the PuT skim calculation already determined all connections, itwould be advantageous to skip the repetition of the connection search - which is one of thesteps of the subsequent assignment by default - and to store and re-use the connections fromthe skim value calculation instead. The assignment would then be restricted to the Choice step(see "Connection Choice" on page 458).During the timetable-based assignment, the connections can either be determined by a Search(see "The variant Branch and Bound" on page 453 and "The variant Shortest path search" onpage 454) or alternatively be read from file or taken from a previously calculated assignment.

Connection export and importThe option of saving (see User Manual, Chpt. 6.2.4.8, page 984) connections to file in order toimport (see User Manual, Chpt. 13.3, page 1406) them later opens the assignment also forusers who want to use their own search and choice procedures. The timetable-basedassignment has such a modular structure that Search and Choice can be performedindependently of each other.• The import of already loaded connections is offered as a separate procedure called

Connection import. It provides a proper assignment result. All possible evaluations (flowbundle, path list, operational indicators etc.) are available as usual (see User Manual, Chpt.13.3, page 1406).

• If the Search is to be performed externally, the external procedure has to generate a file inthe VISUM connection format, which then can be loaded instead of theVISUM search.

• If the Choice is to be performed externally, the user exports the connections (withoutvolumes). The external choice then assesses the connections, allocating a specific volumeto each connection. Again the loaded connections are stored in the VISUM connectionformat and can be read from file in VISUM by the step Connection import. Like the usual

466 © PTV AG


assignment result, they are then available for all further analyses (flow bundle, networkgraphics, and lists).

• Variants of assignment results can be filed on hard disk and read from file, if necessary, foranalyses. It is no longer necessary to use several version files. For the export of pathshardly any additional computing time has to be assumed. Measurements have revealed anincrease of 3 to 5 percent.

Alternatives to the connection search Symmetrically, instead of the Search, path files can be imported, saving a lot of time in mostnetworks.Alternatively, a search can equally be replaced by using paths resulting from a previousassignment, which is also saving a lot of time. This method is similar to the option Use currentassignment result as initial solution known from PrT assignments (see User Manual, Chpt.5.6.2.2, page 891). However, unlike PrT, the path search may be dropped completely for publictransport.These options allow the following applications for example.• Paths from external sources can be taken as inputs to the VISUM assignment. This allows

a user-defined search without having to abandon the other advantages offered by theVISUM assignment.

• Replacing a connection search by a pre-calculated path file or by paths taken from analready existing assignment again saves time. Since generally the search parameters arenot modified between two assignments, redundant repetitions of the same calculation canbe omitted.

In almost all networks, a search takes up most of the time within the assignment. Takingexisting paths as a basis may reduce the search time required to approximately one tenth.

Illustration 157: Flow chart of a timetable-based assignment

According to illustration 157 the following is possible in VISUM.

(3)+(4)

Wege ausUmlegung oder

aus Datei

Paths fromassignment or

from file

(2a)

(2b)

(1)

Search

Preprocessing

Assessment

Choice + path volumes

Network volumes

belastete Wegeaus Datei

Paths with volumesfrom file

Wegeexport mitBelastungen

Path export withvolumes

Wegeexport ohneBelastungen

Path export withoutvolumes

467 © PTV AG


1. External choice / Connection importConnections with volumes are imported and stored like an assignment result, therefore inform of paths and network volumes.

2. Connection exportIn order to provide the external choice with data, connections can also be exported. Thiscan be done either with or without volumes, in one or several files, and with or without farepoints or fares.

3. Use of existing connections for the searchAs alternative to the internal VISUM search already existing connections can also be takenas a basis, i.e. on paths of a previously performed assignment. This assignment may evenbelong to different demand segments than the current one. This feature is of major interestif the search parameters have not been modified, but a choice is to be carried out withdifferent settings.

4. Import of connections for the searchAlternatively to the internal VISUM search connections can equally be imported at the startof the assignment. However, contrary to item (1) no complete assignment result will beproduced based on the imported paths, the paths will only be used as input for theassignment to be calculated.

6.10.7.1 Steps of the timetable-based assignmentWhen importing or exporting connections, the following has to be noted.• Due to the amount of data the steps are performed by OD pair. Only the connection search

is run per origin zone.• All connection attributes which are relevant for the choice at least depend on the demand

segment, the impedance of a connection additionally from the time interval. Adding up allvolumes of a connection over all time intervals, the total volume per OD pair can bedetermined.

• Optionally, the paths can be stored. The paths can be saved as routes or as connections.• The skim matrix can only be calculated if detailed connection skims are available, i.e. it is

only possible if the connection choice is performed within VISUM.

Import and export of connectionsAfter the pre-selection, connections are available per OD pair. The quality skims for theseconnections will be calculated later.• This is therefore the right time to export (2) or to import (4) all determined connections per

OD pair, if volumes do not have to be known.• If connections including volumes have to be exported, this needs to be done after the

internal assessment.

External choiceDue to lacking asynchronous control the external choice cannot be fitted in between VISUMconnection search and path storage. In fact, the following three steps are necessary.

468 © PTV AG


• VISUM MethodTimetable-based assignment with Connection export option(see User Manual, Chpt.6.2.4.8, page 984). An assignment does not have to be calculated at the same time.

• External choice• VISUM Method

Connection import (see User Manual, Chpt. 13.3, page 1406)

6.10.7.2 ImplementationFile format for connection import and exportFor the importation and exportation of paths a uniform file format is used. Due to the hugeamount of data, only a binary format has been used so far. In the medium term, a text formatwill also be realized.Since the assignment is carried out per OD pair, the connection files have to be structured inthe same way, that is, all connections of the same relation have to be read or written in one go,ordered according to zone numbers.During a connection import to multiple files, the data is distributed to several files.

Data format of the connection fileA connection file contains the following data in the following order.1. A version number is written, which later allows the format to be modified.2. Number of path files so that VISUM identifies when re-importing whether or which

additional files need to be searched for.3. Indication on whether the file contains the number of fare points at the path leg.4. Indication on whether the file contains the connector nodes.5. Level of fare data contained in the file (0 = no fares).6. Codes of the assigned demand segments, for future allocation of volumes when re-reading

them. If connections are exported without volumes, no demand segments are stored, whichmeans the number of demand segments is = 0. Thus, it can be recognized whether a fileincludes volumes or not.

7. The keys of all public transport systems and time profiles of the network in assorted order.Thus, later (generally numerous) references to public transport systems of time profiles nolonger 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 networkand the connection file. The term PuT transport systems comprises all PuT-Line TSys,PuT-Walk TSys and PuT-Aux TSys.

8. All connections are stored separately per OD pair.• Each connection consists of several PuT path legs.• Pure walk link connections only have zero PuT path legs.• A path leg is either of type PuT-Line or PuT-Aux. In the first case it connects time profile

items, in the second case nodes.

Example: Connection file in binary data formatBinaryVersionNo (4 byte-integer)NumberOfFiles (4 byte-integer)ContainsFarePoints (1 byte-integer)LevelOfFareInformation (1 byte-integer)//value in {0,1,2}

469 © PTV AG


ContainsConnectorNodes (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:{

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)

}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{

LegFare (8 byte-real)}

}for each contained DemandSegment in key order:{

Volume (8 byte-double)}if LevelOfFareInformation = 1{

ConnectionFare (8 byte-real)}if ContainsConnectorNodes

{FromNodeNo (4 byte-integer)ToNodeNo (4 byte-integer)

}}

470 © PTV AG


-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 TSysSetof the assignment.

• In contrast to the internal connection search it will not be checked whether the PuT vehiclejourney sections used in the connections read from file are active.

With regard to the exact format the following has to be considered.• The Intel order ("Little Endian") has to be kept.• There is no alignment, which means 4+1+2 bytes are actually exported as 7 bytes.• Strings are written as follows.

• Length as 2-byte integer• Signs as sequence of characters (each 1 byte)

Consistency check during the data importIf a data conflict is detected, the procedure will be aborted. Conflicts can occur in the followingcases.• Unknown keys in the network

• DSegCode• Combined time profile ID• Zone number• Time profile item index

• Different sets of transport systems or time profiles in network and connection file• Improper time profiles (TSys not in TSysSet of the assigned mode)• Invalid departure times (no trip on time profile at indicated time(s) or only outside the

assignment time interval plus extension)• Invalid transitions (transfer walk time exceeds the difference between departure and last

arrival)• Negative volumes

Realization (1) External choice / Connection importThe external choice allows the user to assign volumes to a given number of connectionsaccording to variable rules and to import them again into VISUM so that an assignment resultof usual structure is available (see User Manual, Chpt. 13.3, page 1406).In the chart in illustration 157 this is scheduled above the network loading. The paths containedin the connection file are converted into the internal data structure and therefore no longerdiffer from paths calculated within VISUM. Thus, connection import has the same effect as anassignment.This means the following.• Existing assignments for those demand segments whose volumes are contained in the

connection file are deleted.

471 © PTV AG


• A joint path container for the demand segments given by the connection file is created.• On the basis of the procedure parameters selected for path storage (as connections / as

routes / do not save), paths are generated in VISUM from the imported connections (seeUser Manual, Chpt. 6.1.1.2, page 944).

• At the same time the path volumes read in are transferred into network volumes.• If according to the currently set assignment parameters the volume of a demand segment

contained in the file is to be stored for another DSeg, this parameter is set back to thedefault value (storing for the DSeg itself), i.e. the settings of the connection file overwritethe VISUM settings.

• The current setting of the procedure parameter Number of decimal places is set to thevalue specified in the file (see User Manual, Chpt. 6.1.1.1, page 943).

Realization (2) Connection exportConnection export aims at providing data for external tools to calculate the connection choice(1) independently from VISUM. If the volumes are considered, the export can also serve thepurpose of saving complex assignment results in a file in order to load them into the storage, ifnecessary (see User Manual, Chpt. 6.2.4.8, page 984).Connections can be exported with or without volumes.• With volumes

If, together with the connections, the volumes calculated in VISUM are to be exported aswell, the export may only be done after the choice has been completed. When exportingvolumes, only demand segments with volumes that shall not be stored onto other demandsegments are considered.

• Without volumesFor an external choice, the connections are exported directly after the search. Whenexporting connections without volumes, users can now specify the following for the searchof connections and the export of the result.• Either on all relations• Or only on relations with demand > 0 (as before VISUM 9.3)

Option Regard all relations is only available when selecting Export of paths withoutvolumes. Otherwise the option is disabled.• If the option is checked, a connection search is run for all relations. More paths are

exported accordingly. This option should be used if it is unknown which relations have anexisting demand, yet the user would like to save the paths at an early stage (e.g. in thecontext of a skim matrix calculation).

• Otherwise the logic used so far applies, meaning that no connection needs to be built onrelations with no demand and, in the case of origin zones without any demand, a searchcan remain undone altogether, which has an advantageous effect on the calculating timeand the size of the connection file. The option is useful, if the result of the connectionsearch is to be saved to a file merely as a base for later assignment and if the OD matrixdoes not need to be edited in the meantime.

The exported connection file can - independently of the options above – also contain thefollowing:• Fare points of the path leg (cannot be imported) and/or • Fares per path or path leg (can be imported)

472 © PTV AG


For fare calculations in the context of the external choice, option with fare points has to beenabled since the fare is based on the number of fare points per path leg of the connection.• Extended binary format of the exported file *.con

Under ContainsFarePoints you can find the information, if the file contains fare points (1byte required). If the file contains fare points, the number of fare points (4-byte integer) isalso exported for each path leg (thus in the inner ConnectionLeg loop) together with theprevious indices for time profile, start item and end item.

• Please note, that this information is not read from file. It is only an output value whichsupplies the external choice.

Optionally, the connection export can also include the fares.• The program thus offers the path leg attribute Fare which, just like the fare of paths (i.e. per

connection), is calculated with the assignment and includes the proportional fare of thepath leg.

• Depending on the setting, fares are not saved to the connection file or either on path levelor on path leg level. Only fares of those paths that need to be exported anyway are saved.The amount of exported paths does therefore not depend on the fares of the individualpaths.

• For the export of fares in the *.con file, the current setting for the save fares option (seeUser Manual, Chpt. 6.1.1, page 943) is not relevant. If currently Do not save is set for thisoption, the connection fares will indeed be calculated during assignment, but they will notbe stored with the paths. The calculation itself is performed as described for the operationalindicators.

• Fares per path or path leg can be imported and exported with the connection file (see UserManual, Chpt. 13.3.1, page 1406).

It is possible, but not necessary, to deactivate the option Calculate assignment for theconnection export. If deactivated, no paths or volumes are stored (as is the case for a pureindicator calculation). Instead, existing assignments for the selected demand segments willthen be maintained.For connection export without volumes the following assignment parameters are relevant.• Origin zone interval• Assignment time interval with extension• All search parameters• All pre-selection parametersAll other parameters are only effective if an assignment is actually performed, a skim matrixstored or a connection export carried out.During the export, connections can be saved to one file for all OD pairs or to several files. Thisguarantees that large files with a great number of paths (size > 4GB) can be read in again.

Alternatives to the internal connection search (Implementation (3) / (4))At the beginning of the calculation, predefined connections can be added instead of calculatinga complete connection search. Within the framework of the choice (see "Connection Choice"on page 458) added connections will be dealt with in the same way as those determined by theinternal search.There are two alternatives to connection search.

473 © PTV AG


• Usage of available paths resulting from a previous assignment (3)• Reading in a set of connections from file (4)These options have several advantages.• Reduced computing time for the assignment• Reduced storage capacity required during the assignment• Use of external search algorithms

Realization (3) Use of existing connections for the searchIn this option the user indicates a demand segment for which an assignment has already beenperformed.If this assignment matches the assignment procedure currently to be calculated, the paths canbe re-used. The assignment and the procedure currently to be calculated fit, if the followingrequirements have been fulfilled.• The existing assignment must fulfill the following requirements.

• It has to be timetable-based.• Furthermore, it has to have been calculated with a connection-based path storage.

Attention, this is not the standard setting (see User Manual, Chpt. 6.1.1.2, page 944).• The selected demand segment has to fulfill the following requirements.

• The DSeg has to belong to the same mode as the DSegs currently to be assigned.• The DSeg can (but does not have to) belong to the DSegs currently to be assigned. In

each case, the demand segments to be assigned are allocated to the path container ofthe selected demand segment, this means paths will not be duplicated, but the existingones are used by several demand segments.

Realization (4) Import of connections for the searchIn this option the user indicates a connection file, as also is used for the Connection importprocedure (see User Manual, Chpt. 13.3.1, page 1406). In this context, however, the volumesstored in the file are ignored, only the paths are read in.During the import, the level of the contained fare information is read from the header of the*.con file (see "Implementation" on page 469). Please note, that the current option setting Saveimported fare data (see User Manual, Chpt. 6.1.1.2, page 944) determines whether and howthese fares are taken on (see "Implementation" on page 469). Therefore, the performance isidentical to the one affected by setting Save paths during the connection import. If the filecontains fares per path or path leg, the required attributes are loaded in the same way asduring assignment with an appropriately set Save fares value. By combining Connection import (1) and use of existing paths (3) the same reaction can beproduced. However, it requires more storage capacity and the operation is more complicated.If after the importation no assignment is to be calculated, but a skim matrix has to bedetermined, a different proceeding would be conceivable. The connections could be importedincluding volumes which are directly used as weights for the skim calculation. This has notbeen planned yet, but it is assumed that such an import will be performed only in connectionwith a real assignment (where skim matrices can be calculated, too).

474 © PTV AG

Chapter 6.11: Assignment analysis PuT

6.11 Assignment analysis PuTAssignment analysis is used for calculating the correlation (Goodness-of-Fit Report) betweencalculated and observed attribute values of a selected network object type.• The calculated value is derived from the assignment or the network model. • The observed value may be count data or measured data.Here are some examples:• Journey time comparisons between PrT and PuT• Journey time comparisons of different scenarios• Calculated and counted volumes (links, turns or main turns)• Calculated and measured speedsAny 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• PathsPrerequisite 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 threepossibilities:• All objects of the selected network object type • Only active objects • Only objects with observed value > 0For the assignment analysis, as an option, you can consider user-defined tolerances for user-defined value ranges of the calculated attribute.The quality of the correlation can be determined and issued in two ways:• in groups (for each value of the classification attribute)• collectively for all included network objectsFor the output, the data model of the network object types above has been supplemented withthe calculated attribute Assignment deviation (AssignDev) of type real. Alike all otherVISUM attributes, the attribute can be graphically displayed and issued in lists of the respectivenetwork object.In addition, VISUM calculates various indicators (per group or collectively) that can be issuedin a list or in a chart.

475 © PTV AG


Table 171 shows the calculation rules for the output attributes of the assignment analysis. Thefollowing applies to the formulas:

Note: An assignment result is no longer necessary in order to calculate the correlationcoefficient.

Z Observation (count or measurement)

U Calculation (assignment or network model)

N Number objects with an observed value > 0

AbsRMSEAbs RMSE

Absolute root of mean square deviationSignificant differences between counted and modeled values have a higher impact according to

InterceptIntercept

Coefficient b in linear regression Cf. Excel function: Linear Regression (y = ax + b)

Percent acc GEHPercent with acc GEH

Percentage objects with acceptable GEH value (per network object)

Percent avg rel EPercent with avg rel error

Percentage objects within tolerance

N ObsNumber of observations

Number of observations per class (objects with observed value > 0)

N classNumber 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)NotesThe value range lies between -1 and 1, where the following applies:• -1 = observation opposed to modeling• 0 = no correlation (at random)• +1 = very good correlationThe 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.


( ) ( ) 21N

1iN2

iUiZ⎥⎥⎦

⎤

⎢⎢⎣

⎡

=−= ∑ϑ

( ) ( )( ) 2iUiZ

2iUiZ

iGEH+

−=

abs Zi Ui–( )Ui

------------------------------ Tolerance U( )≤

476 © PTV AG

Chapter 6.12: PuT Passenger surveys

6.12 PuT Passenger surveysPassenger sample surveys - interviews and counts - are essential for public transport supplyplanning. Usually the passenger’s route within the PuT line network is not describedcompletely by interview data. This applies especially to passengers who have to transferseveral times or those who need to walk for transfers.Survey personnel usually count the passengers boarding the surveyed line at the boardingstop 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. Alsothe time of departure from either the boarding stop or the origin terminal of the survey line haveto be recorded in a questionnaire. The VISUM add-on Passenger Onboard Survey contains the following basic functions.• Read survey data

MeanAbsE Mean absolute errorMean deviation of absolute values(δa) (Difference between observed and modeled value)

MeanObs

Mean observed value

MeanRelE Mean relative errorMean deviation of absolute values in % (δp) according to

R2 Coefficient of determination r2 Cf. Excel function RSQ

RelRMSE Relative root of mean square deviation

StdDev Standard deviation

Slope Coefficient a in linear regression Cf. Excel, Linear Regression (y = ax + b)


( ) ( )∑ −⋅= iUiZAbsN1

aδ

∑⋅ iZN1

( ) ( )∑

∑ −=

iZiUiZAbs

pδ

( )( )

∑

∑−

−

NiZ1N

2iUiZ

477 © PTV AG


Loading data from file and conversion of data records into PuT paths (see User Manual,Chpt. 6.12.3, page 481).

• Plausibilization of survey dataVerification and completion of the survey data records which contain the basic passengertrip data (see User Manual, Chpt. 6.12.4, page 481).

• Direct assignmentAssignment of the survey data records (calculating network volumes from pathvolumes),optionally OD matrices and skim matrices can be generated (see User Manual,Chpt. 6.12.5, page 487).

After direct assignment of the survey data, the full range of the VISUM functionality for analysisand display of results is available, e.g. flow bundle display (see "Interactive analyses" onpage 655) or PuT operating indicators (see "PuT Operating Indicators" on page 568).

6.12.1 Basic data of a passenger trip

Note: From each survey data record (which means per questionnaire or per ticket,respectively), a passenger trip is generated and stored as PuT path.

Note: Subsequently, indicator data on path level (by survey data record) is automaticallyprovided in the PuT paths list.


Survey line Designation of the line, where the passenger is encountered

Origin terminal Line i

Origin terminal Line j

Origin terminal Line k

Dest. terminal Line i

Dest. terminal Line j

Dest. terminal Line k

DestStop

OriginStop

2nd Transfer

1st Transfer

Preceding line Survey line Succeeding line

AlightStopBoardStop

Origin / Destination of a line

Route of passenger trip

Passenger‘s origin, boarding, transfer, alighting or destination stop

478 © PTV AG


Standard questionnaire

Illustration 158: Standard questionnaire

The replies obtained in a passenger survey are noted down in questionnaires. Such aquestionnaire form usually consists of parts.• Features which identify the questionnaire are entered in the header, such as the

interviewer's number, vehicle class and service trip number.

Preceding/Succeeding Path legs traveled by passenger before or after the survey line

A path leg is the transfer-free part of a passenger trip on a line, from boarding to alighting (number of path legs = number of transfers + 1)

Origin terminal First stop of a service trip

Destination terminal Last stop of a service trip

OrigStop Starting stop (origin) of a passenger trip: first boarding stop entering a PuT line per PuT path

DestStop Destination stop of a passenger trip: last alighting stop leaving a PuT line per PuT path

BoardStop Boarding stop of the survey line: stop at which the passenger enters the survey line

AlightStop Alighting stop of the survey line: stop at which the passenger leaves the survey line


Questionnaire

Route

Ticket

Line:

Orig.Term:

Departure:

Preced. 2:

Preced. 1:

Boarding:

Alighting:

Suceed. 1:

Suceed. 2:

One-Way

Season

Group

…

Number of Persons:

42

20

30

Y town

Station

B village

Bus 1

A village

6:10

1

479 © PTV AG


• In the main section, codes for the boarding and alighting stops of the survey line areentered, plus information on any preceding or succeeding lines.

illustration 158 displays a schematic example for a questionnaire. With this questionnaire, upto 5 path legs (2 preceding legs + survey line + 2 succeeding legs) can be recorded.

6.12.2 Passenger onboard survey: Basic approachThe general procedure for the PuT passenger onboard survey is as follows. illustration 159illustrates this procedure schematically.1. VISUM first reads from a text file a set of survey records which closely resemble the

information in the PuT Path Legs list. For each surveyed trip, the following information issupplied:• 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 thedeparture times of the services), if the stated values do not form part of a validconnection.

• A comprehensive log file tags each survey record with a status describing whichsubstitutions were performed and how reliable the resulting information is.

• A new version of the survey file is written which contains all the additional informationthat could be determined automatically.

• Users can review the survey records which are flagged as inconsistent and decidewhether 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.

480 © PTV AG


Illustration 159: Processing of PuT passenger surveys

6.12.3 Read survey dataThis method loads survey data records from text files (one per PuT demand segment) intoVISUM for future plausibilization. Since VISUM stores survey data records as PuT paths, thedata can be accessed via listings as well as via COM interface or flow bundle analysis andother VISUM functionalities provided for PuT paths (see User Manual, Chpt. 6.12.3, page 481).

6.12.4 Plausibilization of survey dataFor plausibility purposes the correctness of the path stated by the passenger is verified foreach survey record. By comparing each survey record with the timetable information of theVISUM network model it is possible to identify and correct survey records which state anincorrect path. Incorrect lines or line routes or time profiles are replaced by correct lines or lineroutes or time profiles. Furthermore, additional data is added to each data record, such astimes of departure and of arrival, travel time and trip distance, used lines and walk links.

Note: The same functionality can be applied to data extracted from e-ticketing applications, ifthe data contain at least check-in information per leg with line route, stop point, and departuretime. In this case, a path leg needs to be marked as surveyed path leg.

Survey Records

file

Importsurveyrecords

Incompletesurvey records

in memory

Check andcompletesurveyrecords

Completesurvey records

in memory

DirectAs signment

Assignmentresult

in memory

any post-assignmentanalysis

Survey Records

file

Logfile

The user checks the survey data records that are not plausible and

discards or corrects them manually. Subsequently, the plausibilization can

be repeated.

481 © PTV AG


Plausibilization: Basic approachAs a rule, the plausibilization includes the following steps.1. Validity check of the survey path leg (illustration 160)2. Validity check of the preceding section (illustration 161)3. Validity check of succeeding sectionFor each of these steps, the validity check can be run several times, in order to check thesurvey data successively with hard-to-meet criteria, which become easier and easier with eachrun.

Note: The boarding and alighting stops stated in the interview data records of the surveyedline 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 thesestops will get lost.

Note: In single-row data records, the preceding section as well as the succeeding sectionmay consist of one or two path legs each (see User Manual, Chpt. 6.3.1.1, page 987).• Inner path leg leading from PreStop to BoardStop and from AlightStop to SucStop

respectively. • Outer path leg leading from OrigStop to PreStop and from SucStop to DestStop,

respectively. In multi-row data records, the previous section as well as the succeeding section may consistof any number of path legs (see User Manual, Chpt. 6.3.1.2, page 988).

482 © PTV AG


Validity check of the survey path leg

Illustration 160: Validity check of the survey path leg

* In case of multiple vehicle journeys, the one with the minimum sum of run time and waittime is chosen.

NONONO

not plausible

YESYES

Check for a vehicle journey from BoardStop to AlightStop in surveyedtime profile (or line route or line) with

departure within the valid range.*

Other criteria for direct validity check?

YESYES

YESYES

Path leg of survey linefrom data record

plausible

NONONO

NONONO

neinneinnein

Connection search permitted? Check for (in)direct connection from BoardStop to AlightStop

with departure within the valid range.

E1E1

E2E2

E3E3

E5E5

State of plausibilization: Survey line

E1E1 E2E2 E3E3 E5E5

E7E7 E8E8 E9E9

plausible

not plausible

Check for a vehicle journey from BoardStop to AlightStop in all of the time profiles of the survey line or in all time profiles of the network.*

YESYES

YESYES

NONONOE7E7E8E8

E9E9

Cf. list of survey path leg states 0..9 below

483 © PTV AG


Validity check of prec. section (Example with 1 or 2 prec. path legs)

Illustration 161: Validity check of the preceding section

* In case of multiple vehicle journeys, the one with the minimum sum of run time and waittime is chosen.

Validity check of succeeding sectionThe validity check of the succeeding path leg(s) is performed accordingly (illustration 161).

Status IDs for the plausibilization qualityIn a result file and also in lists (PuT paths and PuT path legs), a status ID (range 0...9)describes the quality determined by validity check and plausibilization for each survey record:• for the surveyed path leg E in Table 172,• for the preceding section V in Table 173,

Find vehicle journey from PreStop to BoardStop in preceding time profile (or line route or line) matchingthe survey line‘s departure time from the BoardStop.*

Check inner path legPreStop - BoardStop, regard given

arrival time at BoardStop

Survey line is plausible (i.e. departure time

and preceding stops and further information

available)

NONONO

Plausibilization state of preceding path legs:

V1V1 V2V2 V3V3 V4V4

V9V9

plausible

not plausible

V5V5 V6V6

YESYES

V1V1

Other criteria for direct validity check?

Find vehicle journey from PreStop to BoardStop in one of the time profiles of the preceding line or in all TPs of the network.*

V2V2

V3V3

Connection search permitted for a single path leg?

Find (in)direct connection from PreStop to BoardStop matching the survey line‘s

departure from the BoardStop.NONONO

Find another preceding path leg

V5V5

YESYES

NONONO V9V9

YESYES

Find another preceding path leg

YESYES

Check outer path legOrigStop - PreStop,

regard given arrival time at PreStop

Find vehicle journey from OrigStop to PreStop on preceding time profile (or line route or line)

matching the departure time of the inner path leg from the PreStop.* plausible

YESYESYES

not plausible

NONONO

ViTViT

ViT = Status of the inner path leg

Is option Connection search active for remaining preceding section?

NONO

Find an (in)direct connection from OrigStop to BoardStop

with arrival at BoardStop matching the survey line´s

departure time from the BoardStop.

V9V9

V9V9

Find (in)direct connection from OrigStopto PreStop with arrival at PreStop

matching the inner path leg´s departure time from the PreStop.

Is option Direct connection active?

Find direct connection from OrigStop to BoardStop with Journey

time • Factor + constant < Journey time of multi-part preceding section.

Vm = Max (Status of inner path leg / Status of outer path leg)

NONONO

NONOYESYESYES

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 leg´s departure time from the PreStop.*

NONONO

Connection search permitted for a single path leg?

NONO

V9V9

YESYES

YESYESYES

Is the found connection an indirect one?

YESYES

NONONO

NONO

ViTViT

VmVm

YESYESV4V4

NONO

NONO

VmVm

VmVm

YESYES

V6V6YESYES

YESYES

YESYESYES

YESYES

Cf. list of preceding/succeeding path leg states 0..9 below

484 © PTV AG


• for the succeeding section N in Table 174,• for the entire survey data record G in Table 175.

Status indicators for the surveyed path leg (E)

0 Not yet checked

Plausible

1 A vehicle journey could be found in the surveyed time profile (or surveyed line route or line, depends on preciseness of input data), which connects boarding stop and alighting stop of the surveyed path leg and starts within the time tolerance interval defined for the time of departure from the boarding stop.

2 A vehicle journey could be found in another time profile (or line route) of the surveyed line, which connects boarding stop and alighting stop of the surveyed path leg and starts within the time tolerance interval defined for the time of departure from the boarding stop.

3 A vehicle journey could be found in a time profile (or line route) of another line, which connects boarding stop and alighting stop of the surveyed path leg and starts within the time tolerance interval defined for the time of departure from the boarding stop.

5 For the surveyed path leg, an indirect connection could be found by timetable-based search (shortest path search) which departs from the boarding stop within the tolerance interval defined for the departure time from this stop and includes at least one transfer (and walk links, if applicable).

Not plausible

7 Implausible, because none of the line routes (which are valid due to current parameter settings) connects boarding stop and alighting stop and connection search is not permitted either.

8 Implausible, because the time profiles of the line routes (which are valid due to current parameter settings) connecting boarding and alighting stop do not include a departure within the time tolerance interval defined for the time of departure from the boarding stop and connection search is not permitted either.

9 Implausible, because no connection from boarding to alighting stop starting in the given time frame could be found during connection search calculation.

Table 172: Status indicators for the surveyed path leg

Status indicators for the preceding section (V)

0 Does not exist

Plausible

1 A vehicle journey could be found in the preceding time profile (or preceding line route or line, depends on preciseness of input data), which meets the condition defined for the permitted time span.

2 A vehicle journey could be found in another time profile (or line route) of the preceding line, which meets the condition defined for the permitted time span.

3 A vehicle journey could be found in a time profile (or line route) of another line, which meets the condition defined for the permitted time span.

4 A direct vehicle journey from OriginStop to BoardStop with a shorter journey time (Factor • Journey time of Direct connection + constant < Journey time of preceding section) compared to the plausible (multi-part) preceding section could be found and is used instead.

Table 173: Status indicators for the preceding section

485 © PTV AG


5 Replacing at least one of the preceding path legs by an indirect connection which was found by timetable-based connection search (incl. transfer(s) and walk link(s), if applicable).

6 Replacing the implausible (multi-part) preceding section from OriginStop to BoardStop by a connection with an arrival time matching the departure time of the survey line from the BoardStop.

Not plausible

9 Implausible, because no path leg (or sequence of path legs) could be found meeting the given validity check criteria.

Status indicators for the succeeding section (N)

0 Does not exist

Plausible

1 A vehicle journey could be found in the succeeding time profile (or succeeding line route or line, depends on preciseness of input data), which meets the condition defined for the permitted time span.

2 A vehicle journey could be found in another time profile (or line route) of the succeeding line, which meets the condition defined for the permitted time span.

3 A vehicle journey could be found in a time profile (or line route) of another line, which meets the condition defined for the permitted time span.

4 A direct vehicle journey from AlightStop to DestStop with a shorter journey time (Factor • Journey time of Direct connection + constant < Journey time of succeeding section) compared to the plausible (multi-part) succeeding section could be found and is used instead.

5 Replacing at least one of the succeeding path legs by an indirect connection which was found by timetable-based connection search (incl. transfer(s) and walk link(s), if applicable).

6 Replacing the implausible (multi-part) succeeding section from AlightStop to DestStop by a connection with a departure time matching the arrival time of the survey line at the AlightStop.

Not plausible

9 Implausible, because no path leg (or sequence of path legs) could be found meeting the given validity check criteria.

Table 174: Status indicators for the succeeding section

Status indicators for the entire survey data record (G)

0 Not processed

Plausible

1 All of the sections (preceding leg(s), succeeding leg(s) and/or survey leg) are plausible.

Not plausible

9 Implausible because of one (or more) implausible sections (preceding leg(s), succeeding leg(s) and/or survey leg).

Table 175: Status indicators for the entire survey data record

Status indicators for the preceding section (V)

Table 173: Status indicators for the preceding section

486 © PTV AG


6.12.5 Assignment of survey dataDirect assignment means assignment of a demand segment’s plausible paths to the PuT linenetwork (see User Manual, Chpt. 6.3.4, page 1002).Subsequently, any of the post-assignment analyses provided for public transport can becarried out.• Volume display as bars along links (see "Tabular and graphic display" on page 679)• Flow bundle calculations (see "Flow bundles" on page 655)• Skim matrix calculation on the basis of directly assigned paths (if not already calculated at

the direct assignment),(see "PuT skims" on page 414)• Calculation of PuT operating indicators, for example for the line costing and revenue

calculation (see "PuT Operating Indicators" on page 568)

487 © PTV AG


488 © PTV AG

7 Operator model PuT

The PuT operator model in VISUM comprises the PuT operating indicators and the PuT lineblocking procedure.

Subjects• Application areas and scope of operations• Network objects in the operator model• Typical work flow in the PuT operator model• Line blocking• PuT fare model• PuT Operating Indicators• Calculation of the fare revenues (revenue calculation)

7.1 Application areas and scope of operationsThe results of the procedures PuT operating indicators and Line blocking are saved inattributes, which are overall designated as operating indicators. These can be divided into thefollowing categories:• General indicators for bundling line data (for example the number of service trips per line

route)• Indicators for the measurement of the operating performance (for example the service

kilometers to be run by an operator)• Indicators for the measurement of the transport performance (for example the passenger

hours for a service trip)• Indicators for the calculation of the operating costs (for example the stop point costs per

line). The cost model permits modeling of vehicle type-based costs as well as infrastructurecosts.

• 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 calculationin VISUM.

• Indicators of vehicle requirement and of line blockingTypical application areas of the operator model are:• Assessment of the economic efficiency of an existing PuT supply and derivation of

improvement potentials• Analysis of the effects of supply changes on the economic result (cost coverage)• Comparison of costs for establishment and maintenance of PuT supply and fare revenues• Calculation of the cost coverage on different aggregation levels of the line hierarchy (for

example cost coverage per line, line route or trip)• Distribution of the fare revenues onto operators of a PuT supply• Distribution of the fare revenues onto local authorities (counties, municipalities)

489 © PTV AG

Chapter 7: Operator model PuT

• Performance check down to the trip and vehicle levelThe second module of the operator model is line blocking. A line block contains all (see UserManual, Chpt. 7.1, page 1019) vehicle journeys which are run successively by one vehiclecombination or by several similar vehicle combinations. The objective of line blocking is toassign the total number of trips to vehicles, so that costs are reduced. Also line blockingprovides indicators such as empty kilometers of a line block. In the following, these aredesignated as indicators of the vehicle requirement and line blocking. In most cases lineblocking 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 PuTinterlining matrix is provided in addition to the line blocking procedure. It calculates transportsystem-specific skim matrices for interlining trips between stop points of a transport system.

7.1.1 Calculation of indicators on different aggregation levelsVISUM allows indicators to be calculated in different granularity. Passenger kilometers, costs,and revenues, for example, can be calculated for trips served by a specific line using low-floorbuses between 6 and 7 a.m. in the municipal territory. Or have the passenger kilometerscalculated for each operator in your model, to divide the fare revenues between the operators.The indicators can be calculated as follows.• Differentiated according to territory, for example local authorities such as counties or

districts (see User Manual, Chpt. 7.3.1, page 1075)• According to operating companies• Temporal distinction through freely adjustable time intervals within a day, or – if a calendar

is used – within a week or a year. This is independent of the PuT operating indicatorsprocedure (see User Manual, Chpt. 4.2, page 823)

• Differentiated according to the objects of the line hierarchy. These include main lines, lines,line routes, line route items, time profiles, time profile items, service trips and service tripitems

There are different levels of detail for breaking down indicators to territories. To calculateindicators on these levels of detail, apply the procedure PuT operating indicators (see UserManual, Chpt. 7.3, page 1075). The results of the procedure can be found in the PuT Detail list.In detail, the indicators can be calculated for territories on the following levels (this concernsindicators from the PuT assignment as well as from the procedure PuT operating indicatorsand the line blocking procedure):• Territory• Territory x Transport system• Territory x Main line• Territory x Line• Territory x Line route• Territory x Time profile• Territory x Vehicle journey• Territory x Transport system x Vehicle combination• Territory x Main line x Vehicle combination• Territory x Line x Vehicle combination

490 © 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 combinationIf 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 levelterritory x transport system.

7.1.2 Introductory examples for PuT indicatorsFor 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 hierarchyis described below. The examples are there to give an impression on the applicationpossibilities and the performance of the PuT operator model. The documentation also containsexample calculations for the individual indicators (see "Description of the PuT interlining matrixprocedure" on page 545). Which indicators are available on which evaluation levels, can befound in the files IndicatorSource.xls and IndicatorAvailability.xls under \VISUM115\Doc\Eng.The values were created with the example KA_dyn.ver, which is provided in your VISUMinstallation, and can thus be reproduced.

7.1.2.1 Indicator data by territoryUsing territory-related evaluations, you can calculate indicator data for territories whichrepresent fare zones, urban districts, municipalities or counties for example. The territorypolygon is decisive for the calculation; and the indicator´s share, which applies to the polygon(see "Territories" on page 40) will be returned. The example network of Karlsruhe contains sixterritories (illustration 162). In the example, the territories correspond to the PuT fare zonescreated in the VISUM fare model. This means, that the polygons (territory boundaries) weremodeled 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 becalculated by fare zone. Some examples for possible territory-based analyses are introducedbelow.

Territory TSys ServiceKm PassengerKm

East Bus 2,776.88 17,219.-58

East Train 1,611.57 21,094.72

East Tram 6,796.78 187,312.42

West Bus 538.57 9,671.80

West Train 323.14 5,803.08

West Tram 5,703.52 214,538.25

Table 176: Level Territory x Transport system

Note: Not every indicator is available for all aggregation levels. In the IndicatorAvailability.xlsfile under \VISUM115\Doc\Eng you will find tables which will tell you on which aggregationlevels the indicators are available.

491 © PTV AG


Illustration 162: Territories in the example

Using the indicators Number of stop points Total, Line network length (directed) and theNumber of service trips, information can be obtained on the line routes and the timetable of themodel for each territory. Within the territory polygon Center there are 182 stop points. The linenetwork length is calculated per transport system. The directed line length (the total link lengthof the links traversed via line routes) of the bus network in the city center is 54 km. In theanalysis period of one day, 3154 service trips (number of service trips with at least one stopwithin the territory polygon) stop in this territory. Using these indicators as a basis, the firststatements regarding the PuT connectivity of the territories can be made.

Territory Stop points total Line network length directed (Bus) [km]

Number of service trips (AP)

Center 182 54.015 3.154

North East 53 34.993 814

South 14 8.716 350

East 73 90.188 1.776

West 157 66.749 1.779

Suburbs 96 58.474 1.888

Table 177: Indicators for line route analysis by territory

492 © PTV AG


The performance indicators represent the efforts required for the PuT supply provision inlength units or in time units. The most used indicator is called service kilometers or servicemiles, if applicable. These are the main drivers for costs, which arise for the operator of a lineThe ratio between the service miles and the revenues, which are generated in a territory, canprovide information on how efficient the performance is in this territory. In the example, thisratio is stored in the user-defined attribute Revenue_per_ServiceKM. For that purpose, thevalue 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 providetransport performance. In the outer regions of the example (suburbs), where fewer passengershave to be transported, however, longer distances have to be covered, less revenues probablyaccumulate than in the center. Such a view is useful, if no costs have been modeled in VISUMand simply tendency statements on the cost-effectiveness in a territory are desired.

7.1.2.2 Territory-based evaluation on different aggregation levelsThe indicator data can be refined even more, if the territory is evaluated on differentaggregation levels. Indicators can for example, be calculated like this for each line within aterritory.In the field of transport performance, the indicator Passenger kilometers of a line within aterritory is often used for analyses. On attainable PuT revenues, the passenger kilometerspermit statements by trend, especially in case there are no data on the exact revenues andthese are therefore not modeled in VISUM. Table 179 shows the passenger kilometers andthe number of passenger trips (number of passengers boarding) for line 2 in the territories,which are traversed (illustration 163). For this evaluation, the aggregation level Territory xLine was selected (see User Manual, Chpt. 7.3, page 1075). This is how you can determinehow many passenger kilometers of the line apply to the fare zones.

Territory ServiceKm(AP) [km] Revenue length-proportional (AP) [CU]

Revenue per ServiceKM [CU/km]

Center 16.648 143,945.75 8.65

North East 2.918 8,674.07 2.97

South 1.379 7,416.01 5.38

East 6.615 24,371.61 3.68

West 6.328 40,159.07 6.35

Suburbs 11.191 4,736.75 0.42

Table 178: Territory-based indicator data for transport performance and revenue analysis

493 © PTV AG


Illustration 163: Line 2 traverses several territories

7.1.2.3 Indicators at the line hierarchyIf you are not interested in the territory-based evaluation of indicators, you can also carry outevaluations directly at the line hierarchy levels. For a PuT operator it is important to know forexample, what the volume/capacity ratio of the vehicles is along the course of the line routes.Based on this, the operator can decide to lengthen or shorten a line route. Table 180 showsthe beginning and the end of the line route course of line 002 and the saturation of seatsbetween stops. Between Siemensallee and Lassallestraße, the average volume/capacity ratiois only 4 %, so that shortening the line may be a possibility.

Territory Line PassengerKm(AP) [km] Passenger trips unlinked

Center 2 80.590 30.533

East 2 21.021 9.479

West 2 4.356 6.021

Table 179: Territory-based analysis on aggregation level Territory x Line

494 © PTV AG


.

The service kilometers are often taken into account for the distribution of the calculatedoperating costs between an infrastructural operator and the provider of the PuT supply. In thisexample, Line S3 uses the infrastructure of the Deutsche Bahn (German Rail). In the Lines list,the service kilometers can be displayed per line..

Index Line route name

Direction code

Node number Stop point name Vol/Cap ratio Seats [%]

1 2_H > 105497581 Wolfartsweier Nord 8

2 2_H > 105224474 8

3 2_H > 105224473 8

4 2_H > 105497580 Durlach Zündhütle 10

5 2_H > 105497579 10

6 2_H > 105226816 10

7 2_H > 105226814 10

8 2_H > 105226812 10

9 2_H > 105222467 10

10 2_H > 105497578 Aue Friedhof / Steiermärker Str.

11

... ... ... ... ... ...

106 2_H > 100521 Kussmaulstrasse 41

107 2_H > 100522 Hertzstrasse 26

108 2_H > 100523 Feierabendweg 21

109 2_H > 100524 Neureuter Strasse 9

110 2_H > 105496077 9

111 2_H > 100525 Siemensallee 4

112 2_H > 100526 Lassallestr 0

Table 180: Analysis of the Vol/Cap ratio of seats on the line route level

Line name Transport system Service kilometers [km]

R92 TRAIN 243.612

S1 TRAM 2,468.828

S11 TRAM 1,080.146

S2 TRAM 3,273.128

S3 TRAM 835.176

S31 TRAM 577.254

S4 TRAM 2,129.673

S5 TRAM 4,074.132

S8 TRAIN 53.920

Table 181: Service kilometer analysis on the level of lines

495 © PTV AG


VISUM supports you when making a decision on the line bundle to be run by a bus operator("To which operator, which of the lines are allocated?"). For each line, typical indicators suchas costs, total revenue, revenue per passenger trip, total cost coverage and cost coverage perpassenger 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 balancingthe high-profit lines and low-profit lines as fair as possible, this data can be used to form linebundles, for which PuT operators then can apply in the framework of a tender.

Line name

Transport system

Costs [CU] Revenue total [CU]

Revenue PTrip [CU]

Cost cov. total [CU]

Cost cov. / PTrip [CU]

Cost cov. [%]

21 BUS 433,831.31 773,477.34 0.56 339,646.03 0.25 178.29

22 BUS 254,736.07 314,551.88 0.53 59,815.80 0.10 123.48

23 BUS 487,624.88 214,824.83 0.55 -272,800.05 -0.70 44.06

30 BUS 515,029.02 1,818.301.46 0.63 1,303.272.44 0.45 353.05

31 BUS 705,276.05 872,187.83 0.59 166,911.78 0.11 123.67

32 BUS 452,384.95 425,354.17 0.4 -27,030.78 -0.03 94.2

42 BUS 361,669.22 868,201.73 0.52 506,532.51 0.0 240.5

43 BUS 276,488.08 215,746.49 0.50 -60,741.59 -0.14 78.03

44 BUS 333,456.14 54,659.89 0.53 -278,796.26 -2.69 16.39

45 BUS 429,574.91 330,818.45 0.61 -98,756.46 -0.18 77.01

46 BUS 188,345.74 261,343.71 0.51 72,997.98 0.14 138.76

47 BUS 339,342.42 189,913.11 0.71 -149,429.31 -0.56 55.97

50 BUS 509,071.08 988,980.88 0.58 479,909.80 0.28 194.27

51 BUS 88,748.77 195,342.70 0.57 106,593.93 0.31 220.11

52 BUS 328,666.85 335,666.87 0.52 7,000.01 0.01 102.13

55 BUS 0.00 0.00 0.00 0.00 0.00 0.00

60 BUS 337,039.94 2,004,260,28 0.51 1,667,220,34 0.43 594.67

62 BUS 0.00 0.00 0.00 0.00 0.00 0.00

70 BUS 717,616.46 1,375,946,79 0.53 658,330.33 0.25 191.74

71 BUS 83,309.71 171,403.50 0.52 88,093.79 0.27 205.74

73 BUS 384,722.03 1,809,097,37 0.52 1,424,375,34 0.41 470.23

74 BUS 265,425,27 1,151,942,68 0.53 886,517.42 0.40 434.00

75 BUS 52,673.44 243,368.34 0.47 190,694.90 0.37 462.03

107 BUS 231,821.70 77,805.81 0.52 -154,015.89 -1.04 33.56

108 BUS 59,030.88 0.00 0.00 -59,030.88 0.00 0.00

123 BUS 397,079.54 40,164.47 0.99 -356,915.07 -8.76 10.11

151 BUS 216,990.34 41,625.77 25,569.00 -175,364.57 -7.16 19.18

222 BUS 244,624.05 23,291.90 2.16 -221,332.15 -20.56 9.52

Table 182: Cost and revenue computation on the level of lines

496 © PTV AG


7.1.2.4 Evaluation of indicators on the operator levelSplitting up the revenues from fares to various operators of a transport association oftenregards the service kilometers or the seat kilometers as a basis. VISUM returns this data byoperator. For the three operators in the Karlsruhe example, the following values apply.:

7.1.2.5 Indicator data by time sliceIf you are working with analysis time intervals (see User Manual, Chpt. 4.2, page 823), you canevaluate most indicators broken down in time slices (see "PuT Operating Indicators" onpage 568). This means, that the share of an indicator value which falls in a time interval, iscalculated. In the example KA_dyn.ver, this is used to determine the service kilometers for 1-hour-intervals. In this way, the bus operator can determine operational performance peaks andhas an indicator for the evaluation, how evenly the vehicle fleet is utilized in the course of theday. The example shows time intervals of one hour from 5:00 a.m. to 10:00 p.m. For the busoperator, the operator-related evaluation via all time intervals returns the following servicekilometer values.

551 BUS 142,190.73 306,929.17 0.59 164,738.44 0.32 215.86

Operator name Service kilometers [km] Seat kilometers [km]

TOK Tram Operator 12,71 1,092.238

DB German Rail 23,906 2,165.751

KBB Bus Operator 9,096 454,811

Table 183: Evaluation of transport performance indicators on the level of operators

Operator name KBB Bus Operator

ServiceKm (05:00) 227.0

ServiceKm (06:00) 622.2

ServiceKm (07:00) 689.9

ServiceKm (08:00) 602.4

ServiceKm (09:00) 487.2

ServiceKm (10:00) 443.0

ServiceKm (11:00) 461.7

ServiceKm (12:00) 537.2

ServiceKm (13:00) 604.5

ServiceKm (14:00) 541.9

ServiceKm (15:00) 608.7

Table 184: Evaluation of service kilometers per time interval for the bus operator

Line name

Transport system

Costs [CU] Revenue total [CU]

Revenue PTrip [CU]

Cost cov. total [CU]

Cost cov. / PTrip [CU]

Cost cov. [%]

Table 182: Cost and revenue computation on the level of lines

497 © PTV AG


If the operator additionally compares the passenger kilometers, the statements by trend can bederived, for example the efficiency level by time interval. The time intervals 9 to 12 p.m. andafter 6 p.m. show very low values for this indicator. Thus, in opposition to a relatively hightransport supply performance (ServiceKm) there is a relatively low passenger demand..

7.2 Network objects in the operator modelIn connection with the operator model, the following network objects are of particularimportance: operator, vehicle combination and vehicle unit. Correlations among these networkobjects and their relations to other network objects are illustrated by illustration 164.

ServiceKm (16:00) 710.2

ServiceKm (17:00) 695.7

ServiceKm (18:00) 626.8

ServiceKm (19:00) 406.1

ServiceKm (20:00) 263.1

ServiceKm (21:00) 203.1

Time interval Service kilometers [km] Passenger kilometers [km]

05:00 227.0 3,101.9 13.7

06:00 622.2 14,034.9 22.6

07:00 689.9 24,411.3 35.4

08:00 602.4 15,663.0 26.0

09:00 487.2 4,785.9 9.8

10:00 443.0 5,518.6 12.5

11:00 461.7 7,902.9 17.1

12:00 537.2 7,785.6 14.5

13:00 604.5 13,961.9 23.1

14:00 541.9 14,275.4 26.3

15:00 608.7 12,241.2 20.1

16:00 710.2 11,603.5 16.3

17:00 695.7 7,215.4 10.4

18:00 626.8 4,747.2 7.6

19:00 406.1 1,731.9 4.3

20:00 263.1 672.1 2.6

21:00 203.1 258.4 1.3

Table 185: PassengerKm-to-ServiceKm ratio for the Bus operator

Operator name KBB Bus Operator

Table 184: Evaluation of service kilometers per time interval for the bus operator

Passenger kilometersService kilometers

--------------------------------------------------------- -[ ]

498 © PTV AG

Chapter 7.3: Typical work flow in the PuT operator model

Illustration 164: Allocation of vehicles and operators in the line hierarchy

• An operator can be allocated as the standard operator to a complete line. When creating anew 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 inthe timetable editor.

• A vehicle combination can be allocated as the standard vehicle combination to a completeline or an entire time profile. When creating a new vehicle journey later, the standardvehicle 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 trainscan be more accurately modeled, because they can be made up of different coaches. Themaking-up means creating or editing a vehicle combination.

7.3 Typical work flow in the PuT operator modelTypically, the following steps have to be carried out for analyses by means of the PuT operatormodel. Depending on the indicators to be calculated, not all of the steps are always necessary.1. Parameterization and calculation of PuT assignment procedures (see User Manual, Chpt.

6.2, page 951).2. Creating PuT vehicles (see User Manual, Chpt. 2.27, page 370) and allocating vehicle

journeys (vehicle combinations, vehicle units).3. Creating a fare model (ticket types, fare zones, fare points) (see User Manual, Chpt. 7.6,

page 1087).4. Definition of a cost model (hourly costs, kilometer costs, vehicle costs, stop point costs, link

costs, operator costs) (see User Manual, Chpt. 7.2, page 1072).

VehCombOperator Line

Time profile

VJ section

Vehicle journey

VehUnit

Transport system

0..1

0..1

0..1

Standard Op. StdVehComb

0..1

StdVehComb

0..1

Operator

VehComb

0..n

Read: at the vehicle combination, 0 to n vehicle units are allocated.

1..n

VehComb VehUnit0. .n

Standard Op.

StdVehComb

Operator that is suggested when creating a new vehicle journey.

Vehicle combination that is suggested when creating a new vehicle journey.

Legend

Vehicle and Operator allocation at the line hierarchy

499 © PTV AG


5. Parameterization and calculation of the PuT Line blocking procedure (see User Manual,Chpt. 7.1, page 1019).

6. Definition of the reference frameworks for evaluations• Definition of territories (see User Manual, Chpt. 2.21.1, page 302) and selection of the

aggregation level for evaluations by territory (see User Manual, Chpt. 7.3.2,page 1076).

• Definition of analysis time intervals for evaluations by time slice (see User Manual,Chpt. 4.2, page 823).

• Definition of operators (see User Manual, Chpt. 2.26.1, page 369) and allocation tovehicle journeys.

• Definition of the projection factor (see User Manual, Chpt. 2.41, page 550).7. Calculation of the Territory indicators procedure (see User Manual, Chpt. 4.4.3, page 844).8. Calculation of the PuT Operating indicators procedure for the desired indicator classes (see

User Manual, Chpt. 7.3, page 1075).

7.4 Line blockingSubjects• Introduction into the line blocking procedure• Application example for line blocking• Data model• Line blocking description without vehicle interchange• Line blocking description with vehicle interchange• Vehicle requirement and line blocking indicators• Description of the PuT interlining matrix procedure

7.4.1 Introduction into the line blocking procedureApplication areasOne of the main tasks of strategic PuT planning is to determine the number of vehicles, whichare 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 theindividual vehicle combinations and the demand on vehicle journey level. To do so, the lineblocking procedure with vehicle interchange can be used.If VISUM is applied within an overall context of a PuT operating line costing and revenuecalculation, the line blocking results can then provide a cost model module. With the vehicledemand, line blocking provides an input parameter for determining the vehicle type dependentcosts, 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 theattribute Cost Time, the empty kilometers into the attribute Cost Distance. An overview on thePuT cost and revenue model can be found in illustration 191.

500 © PTV AG

Chapter 7.4: Line blocking

Fundamental termsStarting point of line blocking is the timetable with the service trips, which are to be run by theblocks (VISUM creates the blocks on the level of service trip sections). Blocks are created bylinking individual trips to trip chains, which can each be serviced by a vehicle combination. Inthe simplest case, a vehicle journey is concatenated at its last stop with a subsequent servicewhich starts at the same stop. If such a linkage is not possible nor useful, an Empty Trip cantransfer the vehicle combination to another stop point. Only the empty trips with a real changeof location between two stop points count as interlining. If a vehicle changes from one stoppoint to the depot, at the same stop point or vice versa, this is referred to as pull-in or pull-out.This difference is important when selecting the option Interlining permissible (see User Manual,Chpt. 7.1.3.2, page 1030). For pull-in or pull-out without change of location, neither empty tripsnor empty kilometers accumulate.As displayed in the illustration 165, the following times are included.• Interlining times

Time required for interlining trips between two service trips which end/start at different stoppoints.

• LayoverLayover time at a stop until next service trip departure time.

In VISUM, those unproductive empty times without passenger transport can be calculated bymeans of the line blocking calculation and will then be considered during cost calculation forlines. The same applies to empty kilometers or empty miles.Once line blocking has been calculated, the empty times and empty kilometers/miles of eachline block are known and can be displayed in the Line Blocks list.

Illustration 165: Example line block with pull-out trip, interlining trip and pull-in trip

6:006:00 7:007:00 8:008:00 9:009:00 10:0010:00 11:0011:00

Interlining

Stand

Service

Service

Pull-Out

Stop1

Stop2

Stop3

Stand

Service

Service

Stand

Pull-In

1 432

501 © PTV AG


Optimization problemFor the optimization task of line blocking, there is always a conflict between the number ofempty trips (or more so the sum of empty kilometers covered on the empty trips) and thenumber of vehicles to be used. By creating empty trips, the number of required vehicles canusually be reduced, however, costs accumulate for the additional empty trips (illustration 166bottom). On the other hand, empty trips can be saved when implementing more vehicles(illustration 166 top). Depending on how costs are assessed by the user regarding empty tripson the one hand and additional vehicles on the other side, line blocking can return variousoptimum solutions. In addition to these two basic parameters, VISUM offers more indicatorswhich can be integrated into the cost function. The detailed cost function which is minimized inthis context can be found in the line blocking procedure description (see "Construction of thegraph" on page 529). The solution principle of line blocking in VISUM, which includes creatinga graph and the solution as a flow problem, is also described here.

No. Action FromStop

ToStop Dep Arr Line Time Length

1 Pull-Out Stop3 06:00 06:30 30 min 10 km

2 Service Stop3 Stop1 06:30 07:15 BUS1-1> 45 min 30 km

3 Interlining Stop1 Stop2 07:15 07:30 15 min 10 km

4 Layover Stop2 Stop2 07:30 08:00 30 min 0 km






10 Pull-In Stop1 10:15 10:45 30 min 10 km

Table 186: Example line block with pull-out trip, interlining trip and pull-in trip

502 © PTV AG


Illustration 166: Conflict between empty trips and vehicle demand

Line blocking evaluationCompared to previous VISUM versions, the data model for line blocking as well as theprocedure itself have been developed significantly The advantages of the new procedure areevaluated below.• The solution as a graph flow problem now makes it possible to include long-lasting

downtimes of vehicle combinations – for example in depots - in the process. Thus, themaximum dwell time no longer exists, since a vehicle is permitted to stay in the depot oranywhere else any period of time. The dwell time can now be evaluated by a cost rate freelydefined by the user and can thus be included in the objective function of the optimizationproblem (see "Construction of the graph" on page 529).

• The estimate of the number of vehicles required to run the blocks is more precise.• If closed blocks are created, the empty trips can be determined which are required to

return those vehicles shifted from one location to another, to their starting point. Thisproblem of returning vehicles was not taken into consideration in the previous lineblocking model.The item and effort for relocating vehicles was not considered whendetermining the vehicle demand. This could result in an underestimation of the vehicledemand and the empty kilometers or the empty time.

6:00 7:00 8:00 9:00 10:00 11:00

SP1

SP3

SP2

SP4

1 2

3 4

6:00 7:00 8:00 9:00 10:00 11:00

SP1

SP3

SP2

SP4

1 2

3 4

Dwell time Vehicle 1

Vehicle journey Vehicle 1


3

4 vehicle journeys are completed with 2 vehicles and 0 empty trips

4 vehicle journeys are completed with 1 vehicle and 2 empty trips



Empty trip Vehicle 1

3


1

503 © PTV AG


• In the previous model, multiple blocks of a block version could be run by the sameinstance of the vehicle combination, which could thus result in an overestimation of thevehicle demand. In the new model, the block runs as long as the line blocking timeinterval lasts, thus determining the number of vehicles correctly.

• Blocks can be reedited manually. For that purpose, you can also create user-defined blockitem types. This is how you can manually include maintenance tasks or washing cars inblock planning, for example.

• Many parameters which were procedure properties in the previous model, can now be setper block version. This enables different variants of line blocking to be compared with eachother and even afterwards the parameter settings which were used for the calculations arestill obvious.

• At any time, a line block is consistent with its vehicle journey sections . Possibleinconsistency only applies to reduced pre and post preparation times or empty trips in thecase of changes to the network after line blocking.

• Blocks are only subject to the demand of correctness when they are being used, they donot necessarily have to be free of errors. This means: In many cases, you can edit the basicnetwork whereupon existing line blocks are not discarded. Only when evaluating them inother procedures, line blocks have to be free of errors - for example as a basis for vehiclerequirement, empty kilometers and empty trips computation for the calculation of vehicle-dependent costs by means of the PuT operating indicators procedure (illustration 191).Check line block (see "Check line block" on page 525) thus helps finding and correctingpotential errors.

7.4.2 Application example for line blockingThe example below illustrates the effects caused by different parameters and rules of thumbfor planning. The simple example network (see "Demonstration example" on page 569) is usedas a basis, where additional bus lines have been inserted. You can find the example filesExample_LineBlocking_Closed.ver and Example_LineBlocking_OpenClosed.ver in theVISUM installation.

504 © PTV AG


7.4.2.1 Closed blocks according to different criteriaThe first example is based on a symmetrical timetable.

Illustration 167: Line network of the example with three bus lines (red, blue and yellow)

Illustration 168: (Graphical) timetable of the example, color codes as above

505 © PTV AG


Line blocking is performed three times. For each run, different criteria are set. In either case,closed blocks are created. The results are stored in three block versions in parallel.• Line blocking by line

Only the trips of the same line are joined in a block. Vehicle demand is thus 5 vehicles.• Line comprehensive with expensive empty trips

All bus trips can be linked jointly in blocks, but empty trips are expensive compared to thecosts 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 tripsFor this solution, the vehicle requirement is only 2 vehicles, where 2 empty trips arehowever necessary.

Below, the resulting blocks are illustrated graphically and in tabular form.

Line blocking by lineFor this planning variant, the option "Same line" was selected for line blocking. Because thereare two trips running at the same time, lines BUS1 and BUS2 each require 2 vehicles, anotherone is required for line BUS3.

Block No. Block version code Number of blocking days

Mean operating time

Mean operating km

1 NoLineInterchange 1 1h 30min 55

2 NoLineInterchange 1 1h 30min 55

3 NoLineInterchange 2 21min 26

4 NoLineInterchange 1 56min 40

5 LineInterchange_Expensive 2 1h 51min 81

6 LineInterchange_Expensive 1 56min 40

7 LineInterchange_Cheap 1 2h 32min 111

8 LineInterchange_Cheap 1 2h 32min 111

Table 187: Block data of the three approaches

506 © PTV AG


Illustration 169: Covering the timetable through pure line blocks

Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name

End time ToStopPoint Name

1 1 1 Layover 0 00:00:00 X City 07:20:00 X City

1 2 1 Vehicle journey

BUS1 2 07:20:00 X City 08:05:00 A Village

1 3 1 Layover 0 08:05:00 A Village

08:40:00 A Village


BUS1 3 08:40:00 A Village

09:25:00 X City



06:59:00 A Village



07:55:00 X City





00:00:00 A Village


Table 188: Block items of the line blocks in block version 1

507 © PTV AG


Line blocking without empty tripsThis planning option assumes, that empty trips are more expensive compared to the costs forusing another instance of the vehicle combination. This was achieved by increasing the factorfor the cost shares (which result from empty time and empty km) in the evaluation function. Inreturn, the restriction to pure line blocks was dropped.The line blocking procedure uses the possibility of switching from line to line to run a BUS2service between each two BUS1 services. This is how both lines can be covered by twovehicles simultaneously.




00:00:00 A Village


08:15:00 A Village



08:36:00 X City



06:25:00 A Village



06:53:00 B Village

4 3 1 Layover 0 06:53:00 B Village

10:00:00 B Village


BUS3 32 10:00:00 B Village

10:28:00 A Village


00:00:00 A Village

Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name



508 © PTV AG


Illustration 170: Covering the timetable through blocks without empty trips

Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name


5 1 1 Layover 0 00:00:00 A Village 06:25:00 A Village


BUS1 1 07:10:00 A Village 07:55:00 X City










509 © PTV AG


Line blocking with empty tripsThis planning approach permits line changes and also empty trips since they are attractive withregard to cost evaluation. Accordingly, the services of line BUS3, which has a diverging endpoint, 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 thetheoretical minimum, because there are (repeatedly) two service trips running at the sametime.












BUS3 31 06:25:00 A Village 06:53:00 B Village

6 3 1 Layover 0 06:53:00 B Village 10:00:00 B Village


BUS3 32 10:00:00 B Village 10:28:00 A Village


Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name



510 © PTV AG


Illustration 171: Covering the timetable through line comprehensive blocks with empty trips

Note: The empty trips in illustration 171run from B Village to X City following the first trip ofthe day, in reverse direction before starting the last trip of the day. They are not graphicallydisplayed.

Block no.

Index Blocking day

Block item type

Line name

ServiceTrip

Start time FromStopPoint Name










511 © PTV AG


7.4.2.2 Open and closed blocksIndependent of the selected calendar type, open and closed blocks can be generated. Openblocks start on the first day of the line blocking time interval (or later) and end by the latest onthe last day. For closed blocks, the last day is again followed by the first day of the line blockingtime interval, so that each end of a sequence of block items is connected with a start. This ringclosure is analog to timetable-based PuT assignment and is used to include the costs forcreating the initial situation into the model. The creation of closed blocks assures that thecreated line block schedule "in perpetuo" can be traversed. The following example with anextremely unsymmetrical timetable makes this clear.



7 7 1 Empty trip

0 09:25:00 X City 09:38:00 B Village

7 8 1 Layover 0 09:38:00 B Village 10:00:00 B Village


BUS3 32 10:00:00 B Village 10:28:00 A Village




BUS3 31 06:25:00 A Village 06:53:00 B Village

8 3 1 Empty trip

0 06:53:00 B Village 07:06:00 X City











Block no.

Index Blocking day

Block item type

Line name

ServiceTrip

Start time FromStopPoint Name



512 © PTV AG


Illustration 172: Unsymmetrical timetable with trips beyond 24 hours

If open blocks are created in this example, then one vehicle is sufficient, because the trip fromA Village to X City plus the empty trip in the opposing direction will require 66 minutes and thedeparture of this cycle in A village is every 2 hours. The vehicle can therefore reach the startingpoint before the start of the next trip.When creating closed blocks however, two vehicles are required. The reason for this lies in thelast trip, which is scheduled for 26:05 and thus still belongs to the previous day. Only one hourlies between the departure of this service trip and the subsequent first trip on next day, so thatthe vehicle cannot return to the starting point in the meantime. When creating open blocks, thistransition to the following day is not regarded, which may result in underestimating the vehicledemand.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. Ineach case it has to be decided, whether the empty trip which is required to form the ring closurehas to be included in the model or not.

Note: Open blocks can be created, if the model represents the planning situation for a certainsingle day or period. If the line blocking time interval however, represents a longer cyclewhich is to be repeated (for example a standard day), closed blocks should be created, tocorrectly determine the costs for restoring the initial state in the model.

513 © PTV AG


Block No. Block version code Number of blocking days

Block closed Mean operating time

Mean operating km

1 OpenBlocks 1 0 12h 51min 616

2 Self-ContainedBlocks 2 1 6h 36min 321

Table 191: Open block and closed block for the unsymmetrical example (illustration 172)

Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name




1 2 1 Empty trip 0 03:50:00 X City 04:11:00 A Village






... ... ... ... ... ... ... ... ... ...







2 1 1 Layover 00:11:00 A Village 02:05:00 A Village














Table 192: Block items of both blocks in the example – Block items in the recurring rhythm were omittedfor a better overview. Block 1 is open, block 2 is closed.

514 © PTV AG


7.4.3 Data modelThis section describes the data for the following key points:• Block version• Block• Block item and block item type• Attributes of the line blocking cost function• Downtimes in depots and at stops• Check line block• Coverage check

7.4.3.1 Block versionIn VISUM multiple line blocking results can be kept simultaneously. These are stored in so-called block versions. In this way, alternative plans with different parameter settings can becompared easily to one another. For example, a block version where interlining is allowed andanother one where this is not allowed, can be maintained in the model. Procedures such as thecalculation 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 thatthe parameter settings are still known afterwards, and especially the check line block can usethem for comparisons with the same parameters after changes. The block version attributesare described in Table 193.

... ... ... ... ... ... ... ... ... ...




Block No.

Index Blocking day

Block item type

Line name

Service trip no.

Start time

FromStopPoint Name


Table 192: Block items of both blocks in the example – Block items in the recurring rhythm were omittedfor a better overview. Block 1 is open, block 2 is closed.


Start day index First day of the line blocking time interval. The line blocking time interval has to lie inside of the calendar period.

End day index Last day of the line blocking time interval.

Valid from Date of the start day, if a calendar is used.

Valid to Date of the end day, if a calendar is used.

Create empty trips Specifies, whether line blocking and check line block (see "Check line block" on page 525) should create empty trips .

System routes application Specifies, whether system routes should be used for generating empty trips.

Table 193: Block version attributes

515 © PTV AG


7.4.3.2 BlockA block means, constant application of N vehicles throughout the entire line blocking timeinterval. N is the number of blocking days. It is not dependent on the line blocking time intervalor the length of the calendar. The attribute Number of blocking days reflects the vehicledemand which arises for a block. In illustration 173, a train travels from Hamburg to Vienna onblocking day 1. On blocking day 2 the same train is not available again to travel the sameroute, but has to travel in the opposite direction from Vienna to Hamburg first. It is thereforenecessary to implement a second train, thus the vehicle demand is two vehicles.

Only use active system routes Specify, if only active system routes or all system routes should be used to create empty trips.

Regard preparation times Specifies, whether pre- and post-preparation times should be considered for line blocking and check line block.

Short turn permitted Specifies, whether short turns should be permitted for line blocking and check line block. This means that the layover time is allowed to differ from the pre- and post-preparation times. The short turn properties are set in the attributes for the maximum dwell time, the reduced pre-preparation time and the reduced post-preparation time.

Attribute for maximum dwell time

Specifies the stop point attribute, where the values of the maximum dwell time is contained.

Attribute for pre short turn Specifies the vehicle journey section attribute, where the values of the reduced pre-preparation time is contained.

Attribute for post short turn Specifies the vehicle journey section attribute, where the values of the reduced post-preparation time is contained.

Link attribute for shortest path Specifies the link attribute, which is used as a criterion for the shortest path search for empty trips.

Total vehicle demand Number of required instances of vehicle combinations for all blocks of the block version

Vehicle demand (per vehicle combination)

Number of required instances of a certain vehicle combination for all blocks of the block version

Required vehicles for standard vehicle combination

Number of required instances of the vehicle combination "no vehicle combination". If no vehicle combination is specified at the vehicle journey section, this specification is evaluated as an own vehicle combination, whose required vehicle is accounted for by this attribute.

Vehicle unit requirement (per vehicle unit)

Number of required instances of a certain vehicle unit for all blocks of the block version


Table 193: Block version attributes

516 © PTV AG


Illustration 173: Blocking days and vehicle demand

A block possesses the attributes described in Table 194.


Block version ID / code Reference to the block version, which the block belongs to.

Vehicle combination number

Vehicle combination which is used to run a block. A block can be run by only one vehicle combination, but possibly by several exemplars of this type.

Number of blocking days Specifies, how many (similar) vehicle combinations are being used simultaneously for this block, how high therefore the vehicle demand is for the block. Closed blocks have arrived back at the starting position after this number of days.

Closed Specifies, whether the block was generated for a closed time axis, if therefore after the last day of the line blocking time interval, the first day will follow analogously to the assignment.

Depot number Refers to a stop point, which is used as a depot for this block.

Empty trip transport system code

Specifies which transport system should be used within check line block when calculating the empty trip. The value is applied from the procedure parameters for line blocking. It can also be inserted directly for manual planning.

Not checked Specifies, whether the block was checked (0) or not (1).

Has vehicle fault Specifies, whether an incorrect vehicle was used in the block (see "Check line block" on page 525).

Has layover time fault Specifies, whether pre- and post-preparation times were exceeded (see "Check line block" on page 525).

Has blocking day fault Specifies, whether a blocking day without block items exists (see "Check line block" on page 525).

Has time fault Specifies, whether a time fault exists (see "Check line block" on page 525).

Has location fault Specifies, whether a location fault exists (see "Check line block" on page 525).

Has limit fault Specifies, whether one of the thresholds for the length or the threshold for the duration of a user-defined block item was exceeded (see "Check line block" on page 525).

Has forced chaining errors Specifies, whether a valid forced chaining which was not adhered to, exists (see "Check line block" on page 525).

Table 194: Block attributes

517 © PTV AG


Has vehicle interchange Specifies, whether the block was created with or without vehicle interchange, if therefore the vehicle combination has to be compared against the vehicle journey section attribute vehicle combination or against the attribute vehicle combination set.

From stop point number and name

Specifies at which stop point the block starts. For closed blocks, this complies with the To stop point.

To stop point number and name

Specifies at which stop point the block ends. For closed blocks, this complies with the From stop point.

Start day index Starting day index of the block referring to the line blocking time interval of the block version. For closed blocks, the value is always 1.

End day index Ending day index of the block referring to the line blocking time interval of the block version. For closed blocks, the value is always equal to the number of days in the line blocking time interval.

Start time Starting time of the block, therefore starting time of the first block item. For closed blocks this is usually 00:00:00, unless a service trip block item exceeds 24 hours on the last day.

End time Ending time of the block, therefore end time of the first block item. For closed blocks this is usually 24:00:00, unless a service trip block item exceeds 24 hours on the last day.

Block time Total block time.Number of the line blocking time interval • Number of blocking days

EmptyTime Cumulative time, which is accumulated by layovers and layover times, as well as by empty trips and user-defined block item types of the block.

Mean empty time Empty time / (Number of blocking days • Number of line blocking time interval days)

Empty trip time Cumulative time, which is accumulated by empty trips and user-defined block item types of the block.

Mean empty trip time Empty trip time / (Number of blocking days • Number of line blocking time interval days)

Empty Kilometers Cumulative distance, which is covered by empty trips and user-defined block item types of the block.

Mean empty kilometers Empty kilometers / (Number of blocking days • Number of line blocking time interval days)

Operating Time Cumulative time, which is accumulated by block items of a block. Layovers are not taken into consideration.

Mean operating time Mean operating time per blocking day and calendar day (cumulative operating time divided by the number of blocking days and the number of days of the line blocking time interval).

Operating Kilometers Summed up distances covered by all block items of a block.

Mean operating kilometers Operating kilometers / (Number of blocking days • Number of line blocking time interval days)

ServiceTime Sum of journey times of the service trips of a block.



518 © PTV AG


7.4.3.3 Block item and block item typeEach block is made up of individual sections, which are called block items. Each block item hasa start and an end, and a start stop and an end stop. Table 195 shows the attributes of a blockitem and their meanings.

Mean service time Service time / (Number of blocking days • Number of line blocking time interval days)

Service Kilometers Sum of the length of all service trip block items of a block.

Mean service kilometers Service kilometers / (Number of blocking days • Number of line blocking time interval days)

Number of lines Number of lines, which are used by the block.

Number of line routes Number of line routes, which are used by the block.

Number of time profiles Number of time profiles, which are used by the block.

Number of service trips Number of service trips, which are run by the block.

Cost distance Kilometer costs of the block, which result from the traversed service and empty kilometers (illustration 191).

Cost vehicle Vehicle costs, which result from the number of required vehicles and the fixed costs for a vehicle unit (illustration 191).

Cost vehicle referring to the line blocking time interval

Cost vehicle projected to the line blocking time interval

Cost Time Hourly costs, which result from the time required for service trips and empty trips.

Cost time with layover Hourly block costs which arise from the service trips and empty trips, as well as from downtimes within or outside of a depot accumulated time periods.

Leading depot number Depot with the longest dwell time. For ambiguity, the depot with the smallest number.


Blocking day Specifies, to which blocking day the block item has been assigned.

Block item type / name Number and name of the block item type of the block item. By default, the four block item types service trip, empty trip, layover time and layover time are defined.

Line name Line which is run by this block item. The attribute only displays a value, if the block item is a service trip.

Line route name Line route which is traversed by this block item. The attribute only displays a value, if the block item is a service trip.

Direction code Direction of the line route which is traversed by this block item. The attribute only displays a value, if the block item is a service trip.

Table 195: Block item attributes



519 © PTV AG


Each block item is of a certain type (block item type). By default, there are the block item typesservice trip, empty trip, stand and layover time in VISUM. You can also create user-definedtypes and manually integrate them into your blocks (for example, maintenance or washingvehicles). Table 196 shows the attributes of block item types.

Time profile name Time profile which is used by this block item. The attribute only displays a value, if the block item is a service trip.

Service trip number Service trip which is run by this block item. The attribute only displays a value, if the block item is a service trip.

Service trip section number

Vehicle journey section which is traversed by this block item. The attribute only displays a value, if the block item is a service trip.

Start day index Specifies the calendar day for the start of the block item referring to the start day of the line blocking time interval (attribute start day index of the block version).

End day index Specifies the calendar day for the end of the block item referring to the start day of the line blocking time interval (attribute start day index of the block version).

Start time Start of the block item

End time End of the block item

From stop point number / name

Stop point where the block item starts. Complies with To stop point, if it is a block item of type layover or layover time.

To stop point number / name

Stop point where the block item ends. Complies with From stop point, if it is a block item of type layover or layover time.

Duration Time period of the block item. For block items with a user-defined block item type (for example maintenance) this duration can be edited manually.

Length Block item length. For block items with a user-defined block item type and block items of type empty trip, you can edit the length manually.

Is in depot Indicates a downtime (item of type layover) as taking place in depot. Has no effect for other block items.

Length until next occurrence

Length until a block item of the same type appears in this block again. Only available for block items of a user-defined block item type.

Time until next occurrence

Time until a block item of the same type appears in this block again. Only available for block items of a user-defined block item type.

Departure minute Only the minute value of the attribute start time is displayed (for example start time: 07:20:00, departure minute: 20).

Arrival minute Only the minute value of the attribute end time is displayed (for example end time: 07:20:00, arrival minute: 20).

Chain number Number of the chain. A chain represents a complete run through the block, throughout the entire line blocking time interval. There are as many chains as blocking days, and the N-th chain starts on the first day of the line blocking time interval on blocking day N.


Table 195: Block item attributes

520 © PTV AG


7.4.3.4 Attributes of the line blocking cost functionTo find the optimum line block, a cost function is reduced in line blocking (see "Line blockingdescription without vehicle interchange" on page 528). The attributes found in Table 197 areregarded by this cost function.


Created by the system

Specifies, whether the block item is user-defined.

Default duration Default value for the time period of block items of this type (default setting when creating such a block item).

Default length Default value for the length of block items of this type (default setting when creating such a block item).

Time limit Maximum value for the duration between two block items of this type. If a value >0 is specified here, the time elapsed between the occurrence two items of this type may not exceed this threshold. If this is not the case, the check line block will return a limit fault (see "Check line block" on page 525).

Length limit Maximum value for the distance being traversed by a block between two block items of this type. If a value >0 is specified here, the distance traversed between the occurrence two items of this type may not exceed this threshold. If this is not the case, the check line block will return a limit fault (see "Check line block" on page 525).

Table 196: Block item type attributes

Note: Up to and including VISUM 10 the different cost rates at vehicle units and vehiclecombinations were not used in line blocking. Because of this, existing networks do notcontain this data. For the new line blocking model this means that for each activity costs = 0accumulate, independent of prefactors. This thus leads to an unnecessary use of vehiclesand empty trips. When changing from the old model, make sure that - at least for vehiclecosts and empty trips - positive costs rates are set.

Attribute Object Description

Vehicle requirement Activity in the block (= service trip, layover in depot, layover at stop point, pre and post preparation time, empty trip)

Total number of vehicles required for the block version.

Cost Rate Vehicle Unit Total

Vehicle combination Total cost which accumulates for all vehicle units of the vehicle combination for each instance of the vehicle combination. The cost rate referring to the AP is projected to the duration of the line blocking time interval.

ServiceTime Activity Service time which accumulates during the activity.

Table 197: Attributes of the line blocking cost function

521 © PTV AG


7.4.3.5 Downtimes in depots and at stopsAt stop points you can specify for each vehicle combination, whether the stop point should beused as a depot by the vehicle combination. A capacity and a minimum downtime time can bespecified for each vehicle combination. The capacity is restricted to the number of vehiclecombinations, which are allowed to stop at the same time at the stop point (as a depot), as longas the capacity > 0; for capacity = 0 the depot capacity is unlimited. Depots are therefore stoppoints with downtime function. The downtime in the depot is evaluated with a cost rate that isdifferent (usually lower) from the cost rate for the downtime at a stop point, though bothdowntimes belong to the block item type layover. A difference is made between the same stoppoint in its role as a depot and as a stop point.

Cost Rate Service Hour Total

Vehicle combination Costs which accumulate for a service hour of the vehicle combination.

Service Kilometers Activity Service kilometers which accumulate during the activity.

Cost Rate Service km / mi Total

Vehicle combination Costs which accumulate for a mileaged service kilometer/mile of the vehicle combination.

EmptyTime Activity Empty time which accumulates during the activity.

Cost Rate Empty Hour Total

Vehicle combination Costs which accumulate for an empty hour of the vehicle combination.

Empty Kilometers Activity Empty kilometers which accumulate during the activity.

Cost Rate Empty km / mi Total

Vehicle combination Costs which accumulate for a mileaged empty kilometer of the vehicle combination.

Number of empty trips Activity 1 = activity is an empty trip, otherwise = 0.

Layovers Activity Layover at stop points which are no depots for the vehicle combination, accumulating during the activity.

Cost Rate Hour Layover total

Vehicle combination Costs which accumulate for a layover hour of the vehicle combination at a stop point, which is not a depot for the vehicle combination.

Layover in Depot Activity Layover in depots of the vehicle combination, which accumulates during the activity.

Cost Rate Depot Hour Total

Vehicle combination Costs which accumulate for a layover hour of the vehicle combination in a depot.


Is Depot Specifies that the stop point is a depot. A stop point is a depot, if either at least one vehicle combination is permissible or the entry Default values is permissible.

Is depot for default vehicle combination

Specifies whether the entry Default values (No combination = Not vehicle combination specific) is permissible.

Minimum Depot Layover Minimum downtime per vehicle combination in the depot.

Table 198: Depot attributes of stop points

Attribute Object Description

Table 197: Attributes of the line blocking cost function

522 © PTV AG


7.4.3.6 Empty tripsEmpty trips are used for interlining a vehicle, if the end stop point of the vehicle journey sectionto be carried out, does not correspond with the start stop point of the vehicle journey sectionfollowing in the block. The generation of empty trips is carried out according to the sameprinciples, in the check line block and in both procedures of line blocking, and has direct effecton the data model.The generation of empty trips via the attribute Create empty trips can basically be deactivatedat the block version. Line blockings for this block version, as well as the check line block for lineblocks in this block version, can therefore not calculate empty trips. If end and start stop pointof consecutive block items do not correspond with each other, this is characterized as alocation break.If the generation of empty trips is generally allowed, VISUM tries calculating an empty trip tochange of location. This is always carried out regarding the empty trip transport system of theblock. For check line block this is the specified empty trip transport system (input attribute). No

Minimum layover in the depot for the default vehicle combination

Minimum downtime in the depot for default vehicle combination (entry Default values).

Depot Capacity Capacity per permissible vehicle combination. This is the number of vehicles per combination, which is allowed to simultaneously be at the depot. For the value = 0 the capacity is not limited for the respective 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.

Cost Rate Depot Hour Cost rate for downtimes at depots

Cost Rate Layover Hour Cost rate for downtimes at stop points, not at depots

Table 199: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in Table 197 referto this)

Cost Rate Layover Hour Cost rate for downtimes at stop points, not at depots

Cost Rate Layover Hour Units Sum of cost rates of the vehicle units for downtimes at stop points

Cost Rate Layover Hour Total Total cost rate for downtimes at stop points (= cost rate per layover hour + cost rate per layover hour from vehicle units)

Cost Rate Depot Hour Cost rate for downtimes at depots

Cost Rate Depot Hour Units Sum of cost rates of the vehicle units for downtimes at depots

Cost Rate Depot Hour Total Total cost rate for downtimes at depots (= cost rate per depot hour + cost rate per depot hour from vehicle units)

Table 200: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates inTable 197 refer to this)


Table 198: Depot attributes of stop points

523 © PTV AG


blocks exist a priori for line blocking. Dependent on the parameter settings for eachconfiguration (see "Partitioning" on page 528) of a block which could occur, an empty triptransport system is predefined and saved to the actual generated blocks. This ensures, thatwith a later check the same empty trip transport system is used.With the attribute Use system routes the block version can be defined in more detail, how theempty trip calculation should be carried out:• Do not use system routes

Empty trips are generated through shortest path search in the network regarding the emptytrip transport system. The shortest path regarding the distance or the run time (t_PuTSys)are calculated, for example.

• Use system routesIf there is a system route for the empty trip transport system, from the origin to thedestination point, the lengths and run time are applied as values for the empty trip. If thereare vehicle combination-specific run times, these have priority. The empty trip block itembeing generated has a relation to the system route used. System routes are not usedtransitive. If there is no suitable system route, a shortest path search is carried out in thenetwork.

• Use system routes exclusivelyThe possible empty trips are solely described through system routes, a shortest pathsearch is not carried out. If there is no suitable system route for an OD-pair, interlining is notpossible.

With the selection of the suitable option, the generated empty trips can be controlled in detail.

7.4.3.7 Forced chainingsFor line blocking it is determined from the start, which incoming trip has to be connected towhich outgoing trip. Especially in rail services, such pre-connections are often produced due tothe short time between the connected trips. The reason being, that changing the vehicle poolbetween arrival and departure is not possible. Desired through-connections between trips area source for such forced connections.Forced chaining is a relation of a vehicle journey section to a follow-up vehicle journey sectionon a calendar day. Forced chaining means that this transfer in the line blocking result has to beadhered 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 bedifferent for each calendar day. They therefore connect occurrences of vehicle journeysections.By definition a maximum of 24h to 1s. is allowed to lie between the arrival of the vehicle journeysection and the departure of the successor. The calendar of the successor is therefore clearlydetermined by the arrival time, consequently by the calendar day of the origin vehicle journeysection. Forced chaining is valid, if the origin vehicle journey section is even operating on thecalendar day of the forced chaining, if in the described time interval, an occurrence of thedestination vehicle journey section starts after the occurrence of the origin vehicle journeysection, and if in addition the vehicle combinations of the origin vehicle journey section and thedestination vehicle journey section coincide (block does not have vehicle interchange) or therespective vehicle combination sets have a non-empty intersection (block has vehicleinterchange).

524 © PTV AG


Forced chainings are optionally considered in line blocking. In this case, as long as none of thefollowing 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 stoppoint of the destination vehicle journey section, and the time between is not enough for anempty trip or empty trips are not allowed to be generated. The block then has a forcedchaining 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 checkline block, to comply with (potentially reduced) pre- and postpreparation times. Entering aforced chaining has priority before a possible contradicting minimum layover time. Therequired time for an empty trip has to be met. Downtimes at depots are not allowed betweenforced chainings connected by service trip block items.

7.4.3.8 Check line block In the previous VISUM version of line blocking, the blocks always had to be correct, whichmeans that they were not allowed to have time or location breaks. The result was, that theblocks were deleted when making important changes in the network (for example at servicetrips). This cannot be tolerated, especially when blocks were edited manually and thereforecannot simply be restored by carrying out line blocking again. In the block data model nowavailable in VISUM, the consistency of line blocks with the network is assured and in return theconstant correctness of the block itself is no longer required. Instead, you have the possibilityof performing a check line block to calculate the status which codes the information onconsistency (called error flags below) for each block. These error flags provide you withinformation on whether the blocks are error free and if not, in which respect there areinconsistencies. All together there are seven error flags.The state model in illustration 174 shows the possible states of a block and how the sevenflags are set.

525 © PTV AG


Illustration 174: State model for blocks

The blocks react if the network database changes. Changes to the block version, the blockitems and the vehicle journey sections are taken into consideration. Furthermore, blocks reactto changes made to the basic network parameters, especially to calendar settings.• Location break (LocationFault)

Two successive trips in a block do not match, because the successive trip does not start atthe same stop point, where the preceding trip ends.

• TimeFaultTwo successive trips in a block overlap with regard to time. This means, that the precedingtrip arrives later than the successive trip departs.

• LayoverTimeFaultTwo successive trips overlap each other in time only if for arriving trips the post-preparationtime and for departing trips the pre-preparation time is included in a block. This means, thatthe planned layover time is not sufficient. In practice such an error can be ignoredsometimes, 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, becausethe forced chaining has priority.

• VehicleFaultThe block includes vehicle journey sections to which a vehicle combination was allocatedwhich does not match the block. This error can occur for example, if line blocking hascalculated a block for a standard bus and later on the user manually assigns a low-floor busto one of the trip sections. The attribute Has vehicle interchange is used for the evaluationof this error. This decides whether the vehicle journey section attribute vehiclecombination or the vehicle combination set are used for comparison.

• Blocking day fault (EmptyDayFault)If there is an empty blocking day, this error is set. This means, that there is a blocking day

Adjustment toaltered data


Line Blocking

Unchecked

New Block Block Check

MinorFaults

VehFault

No Fault Major FaultsLocation

Fault

All Minor Faults

Edit Block

Time Fault

Empty Day Fault

Limit Fault

LayoverTime Fault

ForcedChaining

Fault



526 © PTV AG


without a block item on any calendar day (except for layover items). In this case, an extravehicle has unnecessarily been planned.

• LimitFaultThis error can only occur, if there are user-defined block items with time or length limitvalues >0. The length limit value thus specifies the length, which is allowed to be coveredat a maximum, between two actions of this type within a block. The time limit value isanalog for time periods. If one of the thresholds are exceed in the block, this is indicated bythis error flag.

• ForcedChainingFaultIn the block there is a vehicle journey section, which is the starting point of a valid forcedchaining, which however is not realized in the block. The vehicle journey section successoris therefore not the destination vehicle journey section of the forced relation.

If a block contains the flag unchecked or time break or location break, it is not allowed to beregarded by subsequent evaluations (for example in the PuT operating indicators procedure).The other five flags however, do not restrict usability. This is necessary to be able to alsotransfer plans from other systems and to be able to use it for the line performance and linecosting calculations in the procedure PuT operational indicators (see "Description of the PuTinterlining matrix procedure" on page 545), which often contain such errors (partiallydeliberately).

Common check line block and forced check line blockBetween the network basis and blocks, two types of inconsistencies can occur throughsubsequent changes, which are not found in common check line blocks. To check consistencyin all respects, the so-called forced check can be carried out as an option (see User Manual,Chpt. 7.1.1.5, page 1025). These are the two inconsistencies in detail:• When using reduced layover times, it could occur that no error flag is displayed, although

the block contains a layover time error (LayoverTimeFault). This is the case, if the value ofone of the three attributes describing the reduced layover time was subsequently edited orthe selection of one of these attributes changed. These user-definable attributes of stoppoints and vehicle journey sections are: reduced pre-preparation time, reduced post-preparation time and maximum dwell time. The reason for this being, that these threeattributes can be specified dynamically by the user (in particular, also indirect or user-defined attributes can be used). Due to calculation times, it is not efficiently possible toreact to changes in these attributes and to automatically set the error flag. That is why youhave to carry out the forced version of the check line block, to make sure that all layovertime undershoots (layover time fault) are determined in the checked blocks, if subsequentchanges have been made. If no reduced layover times are used (block version property),this problem can not occur.

• Subsequent changes to the network do not cause automatic adjustments of potentiallyconcerned empty trips (for example when changing PuT run times of links or when blockinglinks 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 tonetwork changes. That is why only a forced check can assure that the blocks do not containsuch errors, if the network used by empty trips has been changed subsequently.

527 © PTV AG


7.4.3.9 Coverage checkFor a block version it can be determined, if the version covers all trip sections in a given timeframe (from day to day, generally the analysis period) ((see User Manual, Chpt. 7.1.1.4,page 1024)). If there is a trip section which is - for a calendar day - not bound by a service tripin the block of the block version to be checked, the check has failed.

7.4.4 Line blocking description without vehicle interchangeThe 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 vehicleinterchange. Alternatively, you can also calculate line blocking with vehicle interchange (see"Line blocking description with vehicle interchange" on page 538).The solution algorithm for the line blocking procedure is based on the formulation of a graphflow 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 PartitioningLine blocking regards the vehicle journey sections of the model for planning, the generatedblocks thus successively traverse vehicle journey sections. For planning, either all or all activevehicle journey sections, or - orthogonally thereto - either all sections or only those not yetbeing bound in the target block version can be regarded (see User Manual, Chpt. 7.1.3.2,page 1030). Prior to the graph construction, the problem is broken down into subproblems, so-called partitions, which are to be solved separately. A partition consists of all vehicle journeysections to which the same vehicle combination has been assigned. The decomposition intothese subproblems is possible, because a block is always run by exactly one vehiclecombination and there is therefore no vehicle change within the block. Also the vehicle journeysections 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 constructedand solved for each partition and each result will be decomposed into blocks.As an option, line blocking can be partitioned further according to operator, transport systemand line (see User Manual, Chpt. 7.1.3.2, page 1030). If for example the same operator isrequired for the next vehicle journey, operators are partitioned additionally. In this case eachpartial problem and thus each resulting block only contains vehicle journey sections of avehicle combination and of an operator. Operator changes can therefore not be made within ablock. Within the procedure, a separate graph is set up for each combination of vehiclecombination and operator, and the other procedural steps are carried out for each of thesegraphs. illustration 175 shows an example of partitioning. These are vehicle journey sectionsrun by three vehicle combinations: articulated bus, standard bus, and tram. The articulated busvehicle journey sections are run by operator 1 and 2, whereas the tram vehicle journeysections are run by operator 1 only. If line blocking is additionally partitioned according to

528 © PTV AG


operators, five graphs will be built, for which the flow problem has to be solved separately andthe decomposition into blocks needs to be carried out separately.

Illustration 175: Example for partitioning according to vehicle combination and operator

7.4.4.2 Construction of the graphThese 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 withan edge. The following nodes are called real events. Departure and arrival in each case isthe time including poss(see User Manual, Chpt. 7.1.3.2, page 1030)ible pre- and post-preparation times, insofar as these are taken into consideration .

Note: Capacity restrictions in depots can only be considered, if the graph is not petitionedfurther than after the vehicle combination, if therefore none of the options Same operator fornext vehicle journey, Same transport system for next vehicle journey or Same line for nextvehicle journey has been selected. The reason for this being, that the capacities in depots areeach defined per vehicle combination. If a more detailed partitioning is carried out forexample according to operators, the procedure does not have the possibility of distributingthe capacity, even further to the level Vehicle combination x Operator.

Standard Bus TramArticulated Bus

Operator1

VehComb

Operator Operator 2 Operator 1 Operator 2 Operator 1

Graph 1Graph Graph 2 Graph 3 Graph 4 Graph 5

529 © PTV AG


Illustration 176: Inserting the nodes and edges for vehicle journey sections

2. For each permissible depot for the vehicle combination as well as for each stop point, whichis the start of a vehicle journey section of the current partition (empty trips between stoppoints), enter an arrival event for the time of arrival and an edge for the empty trip from thedeparture 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 graphthere is one node for the stop point and another one for the depot, although the depot isrepresented by the same stop point in the network.

A

B

C

depot ( = C‘)

"real" arrival or departure event vehicle journey section

time

530 © PTV AG


Illustration 177: Inserting the edges for entering the depots and for empty trips between stop points

3. Analogously, insert also a departure event and an edge from there to the departure eventof the trip, however, only for each permissible depot, not for other stop points (these meanmoving out of the depots, so-called fake departure events are created in this way).

A

B

C

depot ( = C‘)

"real" arrival or departure event

"fake" arrival or departure event

vehicle journey section

empty trip between stop points trip to depot

time

531 © PTV AG


Illustration 178: Inserting the edges for leaving from depots

4. Insert an additional edge (the so-called Timeline or Waiting edge) between each pair ofsucceeding 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 blockcan 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 thegeneration of closed blocks, each timeline, therefore each sequence of timeline edges fora stop point or a depot, generates a closed ring. Service trip edges and empty trip edgescan also cross the transition from the last to the first day of the blocking time interval. Ablock has as many blocking days as it makes "rounds" through the calendar period, until ithas 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 atimeline, from an auxiliary node to all depots. Inflow and outflow only takes place via thisauxiliary node. In this case it may occur, that no flow can be determined. This happenswhen the total capacity of all depots is smaller than the number of vehicles required tocover all actions. In such a case, line blocking is canceled with an error message.Also in the introductory example (see "Open and closed blocks" on page 512) you can finda note concerning open and closed line blocks.

Note: If interlining is prohibited (see User Manual, Chpt. 7.1.3.2, page 1030), only edges fromand 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 adepot and subsequently return to the same stop point for the start of the next trip.

A

B

C

depot ( = C‘)

1

2

3

4

5

6

7



vehicle journey

empty trip between stoo points

trip from depot

trip to depot

time

532 © PTV AG


5. The graph is now simplified, by combining nodes with the same accessibility and bydeleting equivalent empty trip edges (which provide access to the same departure). Thegraph after the edge reduction can be seen in illustration 179.

Illustration 179: Example graph after inserting the timeline edges and edge reduction

6. For the formulation as a flow problem, it is necessary to define a lower capacity limit and anupper capacity limit to the edges (which is the number of vehicles which can maximally orminimally 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 werecombined).

• Edges along the Timelines, if we are talking about a depot, use the depot capacity asupper 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 inthe last step. These are described by a cost function analog to the perceived journey timefor PuT assignments (see "Perceived journey time" on page 456). This cost function ismade up of summands, which each multiply one property of the edge (therefore the activitydescribed by the edges) by a factor and a cost rate. The cost function is as follows:

Costs = Required vehicles • Coefficient • Cost rate vehicle unit total

A

B

C

depot ( = C‘)

1

2

3

4

5

6

7



vehicle journey

empty trip between stop points

trip from depot

trip to depot

time

timeline edge

533 © PTV AG


Which cost components have an effect on an edge, depends on the edge type. The costcomponents for the individual edge types are the following.• Service trip edges

• Service time describes the duration of the vehicle journey section (The costs for the tripitself are irrelevant for solving the problem, because each edge is allocated with exactlyone flow of 1 and there is thus no alternative allocation. To display the result, servicetrip edges are still evaluated with the service trip cost rates of the vehicle combinationfor duration and distance.)

• ServiceKm/Mi describes the distance covered by the service trip• Layover describes the duration between the FromNode's point in time and the

departure from the FromNode plus the duration between the arrival at the ToNode andToNode'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 andthe 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 thedeparture from the FromNode plus the duration between the arrival at the ToNode andthe 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 vehiclecombination has to traverse this evaluation point in time exactly once, the vehicle demandis thus counted and evaluated.

As an interim result, an evaluated graph is available, for which a flow with minimum costs isdetermined in the following step.

7.4.4.3 Flow problem solutionWith the graph constructed above including the evaluation, the cost minimum flow is nowdetermined. The target cost function can thus be parameterized as described in the previous

+ Service time • Coefficient • Cost rate hour service+ ServiceKm/Mi • Coefficient • Cost rate Km/Mi service+ Space • Coefficient • Cost rate hour empty+ LeerKm/Mi • Coefficient • Cost rate Km/Mi empty+ Number of empty trips • Coefficient+ Layover • Coefficient • Cost rate hour layover+ Service time depot • Coefficient • Cost rate hour depot

Note: The coefficients also have an effect on the cost rate for "no vehicle combination".

534 © PTV AG


procedure step. The user can thus especially control modeling of the basic conflict betweenminimizing empty trips and minimizing vehicle demand, which is described in the introduction.illustration 180 schematically shows such a cost minimum flow, where multiple flow units(vehicle combinations) are indicated on an edge with lines piled on top of each other. To makeit easier, neither costs nor capacities are noted here. The illustration however shows, that allvehicle journey sections are traversed by exactly one vehicle combination. The graph alsoshows, which empty trips even have to be traversed at a minimum cost flow (i.e. all edgescrossed by the flow). Altogether there are two empty trips – one from C´ to A and one from Bto C´. The evaluation line cuts three edges, that is why the vehicle demand is 3.

Illustration 180: Optimal cost flow in the example graph

As a result of this step, a cost-efficient flow exists, the vehicle demand is known and which arethe necessary empty trips. Not known yet however, are the blocks themselves, therefore atwhich stop points blocks start and end, and the routes of the blocks in the optimal flow.

7.4.4.4 Decomposition of the flow into blocksThe cost-efficient flow in the graph from the previous step can be displayed as blocks indifferent ways. Regarding the costs, each of these solutions is of equal quality and thusoptimal. The decomposition step has to break up the flow into chains in the graph, by allocatingan outgoing flow unit at each node. Each generated chain thus corresponds to one block.illustration 181 and illustration 182 show two possible examples, how the cost-efficient flowcan be decomposed into blocks.

A

B

C

depot ( = C‘)

1

2

3

4

5

6

7



vehicle journey section


trip from depot

trip to depot

time

timeline edgeoptimum flowevaluation line

535 © PTV AG


Illustration 181: Example 1 for the decomposition into blocks

A

B

C

depot ( = C‘)

1

2

3

4

5

6

7



vehicle journey


trip from depot

trip to depot

time

timeline edgeblock 1 block 2 block 3

536 © PTV AG


Illustration 182: Example 2 for the decomposition into blocks

This independent optimization problem can be resolved according to different criteria. InVISUM there are two criteria, which can also be combined with each other:• The structure of the transitions between vehicle journey sections in the block can be

influenced by the following options• Differentiated duration of standstills: The distribution of the standstill times is as

irregular as possible, in other words, there are more short and long standstills thanaverage standstill times. The aim of this is to obtain long standstills which can be usedas maintenance time slots.

• Even duration of standstills: The distribution of the standstill times is as even aspossible. 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 avoidline changes within a block as often as possible.

• No specific requirements: In this dimension, no requirements are set concerning theresult.

• If closed blocks are generated, the duration of the blocks can also be influenced with theoptions• Preferably, build long blocks: Blocks have as many blocking days as possible. This

means that the single vehicles traverse multiple line paths. In the most extreme case,all service trips of a partition are covered by a single line block.

• Preferably, build short blocks: Blocks have as few blocking days as possible.• No specific requirements: In this dimension, no requirements are set concerning the

result.

A

B

C

depot ( = C‘)

1

2

3

4

5

6

7



vehicle journey


trip from depot

trip to depot

time

timeline edgeblock 1 block 2 block 3

537 © PTV AG


7.4.5 Line blocking description with vehicle interchangeLine blocking with vehicle interchange differs from that without vehicle interchange, in that thevehicle 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 theattribute vehicle combination set. Different criteria are possible, which can be weightedagainst 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 providedby the capacity, is included in the objective function.

• Selection according to availability: The number of available vehicles can be predefined byunit level. The selection is made, so that this restriction is adhered to. The number ofvehicles 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 blockingwithout vehicle interchange (see "Line blocking description without vehicle interchange" onpage 528) and also covers the following application areas.• Planning the vehicle use depending on the demand, at the same time considering block-

related restrictions.• Reduction of the calculated vehicle requirement by making the vehicle use more flexible,

with the (possibility of) replacing a vehicle combination with another, for example becauseof technical restrictions.

The procedure is based on the line blocking without vehicle interchange and integrates this asa procedural step into its entire process. Compared to this one it is not about an analyticalprocedure, but an iterative search procedure which in general finds very good solutions, butnever an optimal one regarding the objective function.As another distinctive feature, several complete and equal solutions of the given line blockingtask (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 objectivefunction value (convergence) or if the defined maximum number of iterations has beenreached, the procedure is stopped and the best solution is provided.The procedure is divided into the following steps.1. Initial selection of the vehicle combination from the specified vehicle combination set for

each vehicle journey section and each solution.2. Line blocking without vehicle interchange for this selection for each solution3. 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 hasbeen achieved.

Because the line blocking is carried out as in the procedure without vehicle interchange (see"Line blocking description without vehicle interchange" on page 528), for defined selection ofthe vehicle combinations, the following additional components are necessary to understandthe procedure:

538 © PTV AG


• Selection principles of vehicle combinations• Solution evaluation via objective function• Parameters and convergence

7.4.5.1 Selection principles of vehicle combinationsThe selection of vehicle combinations from the set specified for each vehicle journey section,of the vehicle combinations which can be used, is the central component of the procedure. Thechallenge as a search procedure is to produce as many different selections and to avoid suchselections which lead to poor solutions. This task can be compared with the connection searchper Branch&Bound within the timetable-based assignment.In the initial step of the procedure there are no solutions yet. Heuristic procedures play a biggerrole for the selection. In all other iterations the selection is always made on the basis of asolution from the preceding iteration, so that this solution can be further developed. But hereparts of the solution are also discarded and rebuilt. The selection is carried out initially, tocreate the start solutions for the first iteration according to the following criteria:• For an individual occurrence of a vehicle journey section the selection is carried out

• randomly• according to the volume of the service trip and capacity of the vehicle combination - i.e.

a selection which probably leads to good coverage of the demand,• according to the specified number of vehicles, considering the vehicles already used,

by edges without selection or already selected edges - therefore a selection whichprobably leads to an equal volume,

• according to the neighboring service trips without selection - i.e. a selection whichprobably lead to productive blocks.

• Based on individual occurrences of vehicle journey sections, for which a selection hasalready been made, analog choices are made as far as possible• for all service trips of a line,• for all other occurrences of the same vehicle journey section,• for individual neighbors or entire chains neighboring below each other,• for the compliance of the flow conditions particular favorable occurrence of vehicle

journey sections.• The selection can be applied from the attribute Vehicle combination number of the

vehicle journey section, alternatively for all vehicle journey sections from the specificationsfor the line blocking without vehicle interchange, if the vehicle combination in the set isincluded in the permitted vehicle combinations set. Without vehicle interchange, the lineblocking solution thus becomes a starting solution.

• If a reference solution is specified and the proximity is required, the selection can beapplied from this reference solution.

In all later iterations, each solution is generated from an existing solution. The relativeinefficient parts of the solution are determined, who's selection is discarded and based on thenew 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:

539 © PTV AG


• Replace empty trips of a vehicle combination, so that for this vehicle combination a suitabletemporal and local service trip is selected, for which another vehicle combination has so farbeen selected.

• Change the choice simultaneously for entire blocks, so that the configuration regarding thecosts is convenient.

• Change the choice simultaneously for entire blocks, so that the configuration regarding theOD demand coverage is convenient.

• Change the choice simultaneously for entire blocks, so that the configuration regardingretaining the available number of vehicles is convenient.

7.4.5.2 Solution evaluation via objective functionLine blocking with vehicle interchange uses an objective function for evaluating the quality of asolution. The objective function measures solution properties, where there is room forimprovement. It comprises the objective function of line blocking without vehicle interchange(see "Construction of the graph" on page 529) as a component.The following solution properties are evaluated:• Costs: Objective function of line blocking without vehicle interchange. This especially

comprises the number of vehicles per vehicle combination as well as the service km andempty km and service times and empty times, as well as the layovers within and outside ofa 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 journeysections

The following function is used as an objective function (OF), which is based on the comparisonbetween the calculated and the estimated values for each of the objective functioncomponents:

where

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

OFci ofi⋅

cj comparisoni⋅j∑

--------------------------------------------------⎝ ⎠⎜ ⎟⎛ ⎞

i∏=

540 © PTV AG


The individual component properties are apply as follows:

Component Calculation

Costs The objective function component costs evaluate the solution according to the same criteria as the line blocking without vehicle interchange.It therefore appliesofCosts = Σ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 unitThe comparison value comparisonvehicle is 1 (Note: This is how you achieve very strong penalization, because this criteria must apply "strongly", if it is even used)

Consideration of volumes

The volume of a trip section is defined according to the parameter setting asVolVJS = Ø (Volume(ST item) / Number of vehicle journey sections via this ST item)orVolVJS = max (Volume(ST item) / Number of vehicle journey sections via this ST item)Then CapVJS = selected capacity (seat or total) of the vehicle combination:ofVolume = ΣVJS with VolVJS > CapVJS ( VolVJS - CapVJS)The value of this objective function component, which applies for the random solution, used for cost estimation, is used as a comparison value.

Line purity, local definition

The number of line changes between successive service trips in the block are measured. The benchmark is the number of occurrences of vehicle journey sections in total (therefore the number of all transitions between successive service trip items).

Line purity, global definition

The number is calculated minus 1 of the line per block, summed up over all blocks.The comparison value is the number minus 1 of the lines per partition, summed up over all partitions.

Regularity Dispersion of the occurrences of vehicle journey sections is measured for different blocks or optionally for different blocking days. The following applies:ofregularity = Sum of vehicle journey sections |{Blocks / blocking days which contain the VJS}| - 1comparisonregularity = (Sum of occurrences of the VJS in the line blocking time interval – 1)

Distance to starting solution

The number of transitions from vehicle journey section to vehicle journey section, which differ from the comparison solution, are measured.The comparison value is the number of all transfers from vehicle journey section to vehicle journey section in the comparison solution.

Table 201: Objective function components for line blocking with vehicle interchange

Note: Objective function components, which are not relevant for the specific planning task,can be switched off by setting the respective coefficient to 0. This is recommended, becauseoptimization up until the solutions, considering the hidden properties, is thus suppressed.Finding good solutions regarding the remaining criteria is accelerated accordingly.

541 © PTV AG


7.4.5.3 Parameters and convergenceThe 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 improvedstep by step. If there is no improvement within a specified number of iterations, convergencehas been reached and the procedure is ended.As a heuristic procedure, coincidence plays a decisive role, especially as there are manyequivalent solutions. By using a random number generator, the procedure is deterministic inthe 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 forotherwise identical data calculate alternative solutions.These are the following parameters for controlling the procedure run:

7.4.6 Displaying and editing blocks in the timetable editorIn VISUM blocks are illustrated as Gantt charts (block view). Compared to the time-distancediagram, which only displays blocks in as far as the bound trips can be illustrated on the stopsequence, a natural view on a block as a whole is possible. All block actions are displayed aswell 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 canbe configured extensively with graphic parameters in the usual way.Alongside the pure display, block display also allows blocks to be edited. Besides the blockactions, vehicle journey sections are also displayed, which can be inserted or removed from ablock via drag&drop. It is thus possible, to reedit the blocks, generated with one of the two lineblocking procedures, or completely manually generate blocks. All other block-related functionssuch as check line block, coverage check and definition of forced chainings can be initiatedfrom the line block view.

Parameters Meaning and notesUse reference solution

A reference solution is a block version containing blocks. If this option is selected, a solution is searched which can be compared with this reference solution. A different block version should be selected as reference solution, than the current one used.

Maximum number of iterations

Number of iterations, after the procedure is ended, if convergence occurs. This value should be a multiple of the number of iterations without improvement.

Number of iterations without improvement

If for N iterations no improvement of the target function value is determined, the procedure regarded as converged and is ended. Reasonable values depend on the task size, should not however, exceed 10 to 20.

Number of solutions per iteration

Number of simultaneous existing solutions per iteration. The more freedom the planning task offers, the greater this value should be. The minimum permissible value is 10, generally however 20 to 100.

Random seed By changing this value, the random item of the procedure can be influenced to achieve, with otherwise same data and parameters, a different procedure und thus a different result.

542 © PTV AG


Illustration 183: Example for block display of a block with 5 blocking days

Line block view is part of the timetable editor. The display details as well as editing aredescribed there (see User Manual, Chpt. 7.1.5, page 1043).

7.4.7 Vehicle requirement and line blocking indicatorsThe vehicle requirement and line blocking indicators, are also used to asses the economicefficiency of an existing PuT supply and to derive improvement potentials for the operator.

7.4.7.1 Vehicle requirementThe vehicle demand can be displayed both as length proportional and time proportional. Itis output for the objects of the line hierarchy as well as for territories precisely broken down toboundaries. Fr the following network objects, both sets of indicators can be calculated for theanalysis period, the analysis horizon and by analysis time interval.• Vehicle journeys• Time profiles• Line routes• Lines• Main lines• Operators• Transport systems• Territories• Territory PuT detail

Indicator Description

Number of Vehicles (in proportion to length)

Length of the vehicle journey section divided by the total length of all service trip block items in the block, multiplied by the number of blocking days of the block.

Table 202: Line blocking and vehicle requirement indicators

543 © PTV AG


The allocation of the indicator value for the precise calculation by territory is performed asfollows.

• The time proportion of a vehicle journey section in the total time of all vehicle journeysections of the block (called NumBlocksVJS below) is determined.

• For each link that - after a temporal intersection of the vehicle journey section with analysisperiod or time interval - is identified as traversed, the proportional number of vehicles isdetermined according to the time proportion of the link at the VJS • NumBlocksVJS. Thisvalue 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 linkin a territory • NumBlocksVJSOnLink per link. Here, VISUM always uses the length-oriented proportion since the precise link calculation by territory is always based on thiscriterion. The "error" resulting from this is minimal however, because it only affects linksthat lead across a territory border. The proportion of all other links is 1.0.

7.4.7.2 Distribution of empty trips and empty times to service tripsAs line costing is based on service trips, empty times and empty kilometers of a line block haveto be allocated to the service trips served by the block. Based on this, costs can be calculatedby the PuT operating indicators procedure. The example below illustrates the impact of the four variants provided for distribution of emptytimes and empty distances to service trips. The operating time is calculated from empty timeand service time. Similarly, the operating distance results from empty distance and servicedistance. Operating time and operating distance are required for cost calculation.• Hourly costs = Operating time • Vehicle-Hour cost rate• Kilometer costs = Operating distance • Vehicle-Kilometer cost rate

Number of vehicles (in proportion to time)

Duration of the vehicle journey section divided by the total duration of all service trip block items in the block, multiplied by the number of blocking days of the block.

Note: To get a result for the indicators number of vehicles (length proportional) and numberof vehicles (time proportional), you have to first calculate the line blocking procedure and thenthe procedure PuT operating indicators.

Variant 1: EmptyTime from Pre+PostPrepTime (2+3 min) of veh. journey / no EmptyKm

ServiceTrip ServTime EmptyTime

OpTime ServKm EmptyKm OpKm

1. 6:30 – 7:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km

2. 8:00 – 8:15 0:15:00 0:05:00 0:20:00 10 km 0 km 10 km

3. 8:30 – 9:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km

4. 9:30 – 10:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km

Total 2:30:00 0:20:00 2:50:00 100 km 0 km 100 km


Table 202: Line blocking and vehicle requirement indicators

544 © PTV AG


7.4.8 Description of the PuT interlining matrix procedureThe procedure PuT interlining matrix calculates transport system-specific skim matrices forinterlining trips between the stop points of a transport system. For each generated relationbetween two stop points, the specific value calculated for the shortest path between the stoppoints 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, whichare start or end stop point of a service trip of the transport system. Optionally, system routescan be considered. In this case, the indicator values for a relation are determined from the bestsystem route, which leads directly from the start stop point to the destination stop point andwhich is permissible for the transport system. Transitive search via the system routes is notcarried out. For each relation it is thus possible, to individually overwrite the O-D value,determined from the network.

Variant 2: From EmptyTime/EmptyKm of line block weighted by service trips



1. 6:30 – 7:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km

2. 8:00 – 8:15 0:15:00 0:33:45 0:48:45 10 km 7.5 km 37.5 km

3. 8:30 – 9:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km

4. 9:30 – 10:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km

Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km

Variant 3: From EmptyTime/EmptyKm of line block weighted by service time



1. 6:30 – 7:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km

2. 8:00 – 8:15 0:15:00 0:13:30 0:28:30 10 km 3 km 13 km

3. 8:30 – 9:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km

4. 9:30 – 10:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km

Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km

Variant 4: From EmptyTime/EmptyKm 50% before and 50% after service trip



1. 6:30 – 7:15 0:45:00 0:52:30 1:37:30 30 km 15 km 45 km

2. 8:00 – 8:15 0:15:00 0:30:00 0:45:00 10 km 5 km 15 km

3. 8:30 – 9:15 0:45:00 0:15:00 1:00:00 30 km 0 km 30 km

4. 9:30 – 10:15 0:45:00 0:37:30 1:22:30 30 km 10 km 40 km

Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km

Table 203: Example illustrating different variants of distribution of empty time and empty kilometers onindividual service trips.

545 © PTV AG


In the line blocking procedure (see User Manual, Chpt. 7.1.3, page 1029), the interlining matrixis used to determine the duration and length for each empty trip between stop points. The PuTinterlining matrix procedure is also provided as a separate procedure, so that the outputmatrices can be imported in external timetable or crew scheduling systems, as interliningmatrices for line blocking.Table 204 shows an example of a PuT interlining matrix, where the values of the shortest path(determined on the basis of the attribute t-PuTSys) between all relations between two stoppoints are listed. If in a cell the value is 999999, this means, that there is no path between thetwo stop points.

7.5 PuT fare modelSubjects• Short overview• Ticket types• Fare systems• Fare calculation• Application of fares

7.5.1 Short overviewillustration 184 offers an overview of the network objects which belong to the fare modeling inVISUM.

SP20 SP21 SP22 SP24 SP50 SP56 SP71 SP74 SP86

SP20 0 16 36 61 34 73 121 108 999999

SP21 16 0 20 45 50 89 137 124 999999

SP22 36 20 0 25 70 109 157 144 999999

SP24 61 45 25 0 95 134 182 169 999999

SP50 34 50 70 95 0 39 87 74 999999

SP56 73 89 109 134 39 0 48 35 999999

SP71 999999 999999 999999 999999 999999 999999 0 999999 999999

SP74 108 124 144 169 74 35 13 0 999999

SP86 121 137 157 182 87 48 999999 13 0

Table 204: PuT interlining matrix with t-PuTSys between stop points

546 © PTV AG

Chapter 7.5: PuT fare model

Illustration 184: Possibilities of fare modeling in VISUM

The VISUM fare model is based on fare systems and ticket types.A fare system is a set of lines, for which a joint fare system exists. Each PuT operator oftenhas his own fare system, in transport associations a fare system can also include lines ofdifferent 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" onpage 550).For each demand segment you can determine which ticket types are used in a fare system.In particular for each demand segment, several ticket types may exist for each fare system.With the allocation of lines (and PuT-Aux transport systems) to fare systems, each path leg ofa PuT connection belongs to one or more fare systems.Fare systems are generally independent. The total fare for a connection is normally the sum ofthe fares to be paid for the individual fare systems. With specific transfer fares you can

547 © PTV AG


however model, that a change between fare systems costs extra or a reduction is given (see"Initial fare and transfer fare" on page 556).

Determining the ticket to be used for each fare systemWithin 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 hasto be bought for each individual path leg or if it can be used for successive or even all path legsof a connection. All three cases are more often found in practice.As mentioned, several ticket types (per demand segment) may be available within a faresystem. Let's take for example, a fare system is composed of fare zones and the normal faredepends on the number of traversing fare zones. For trips of maximum ten minutes, aninexpensive short-distance ticket applies independent of the fare zones. For trips from and tothe airport, a special airport ticket has to be bought.Generally speaking the crucial question is when creating a fare system, which ticket types areallowed to be used for which connections and how much freedom does the passenger havewhen selecting a ticket.The applicability of the different ticket types plays an important role. If the defined conditionsin the ticket type have been breached, the ticket cannot be used and another ticket has to beused. In the example, the short-distance ticket is invalid if the maximum run time of 10 minuteshas 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 oncertain 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 faresystem. In combination with the previously described applicability of tickets, a logic thusapplies for determining tickets to be used, for a given connection or its path leg(s): Amongst allapplicable 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 tobe used for all connections, whose start or target is the airport . For all other connections theairport ticket cannot be used after construction, which is why the ticket type with the secondhighest rank is regarded, in this case the short-distance ticket. This applies if the connectionfulfills the requirements of the short-distance ticket. If not, the normal zone-based fare with thelowest 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 selectedamongst all applicable tickets.

Ranking order of fare systemsIt may occur, that lines do not just belong to one fare system, but are part of several faresystems. A regional train can for example, be used both within the urban network area with anetwork ticket and beyond the boundaries of the transport association with a long-distanceticket. Urban network and long-distance transport are separate fare systems with completelydifferent 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 generallybe determined according to the procedure described above. However, in reality the passengercannot freely select between the two different fare systems, in each case. A typical farecondition would be for example, that the regional train on trips within the transport association

548 © PTV AG


area can only be used with ticket types of the urban network fare system and long-distancetransport tickets only have validity, if used beyond the transport association boundary (see"Procedure for ambiguous fare systems" on page 563).To express such ranking, you can define fare system ranks. These ranks are only relevant if inyour network model, lines belong to several fare systems, because otherwise the fare systemsare 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 setof allocated fare systems therefore exists for each path leg. The entire connection canprincipally be "covered" by any combination of items of these fare system sets. The faresystem ranks then define a logical order within the combinations: all combinations with thesmallest maximal fare system rank are considered first, and thus the one selected which canbe applied and provides the lowest fare. If none is applicable, all other combinations with thenext highest rank follow. If there are no valid fare system combinations, the global fall-back fareof the fare model is charged.Because you can allocate ranks both on the ticket type level and the fare system level to modelspecific fare conditions, all together great flexibility is achieved for fare modeling.

7.5.2 Ticket typesA ticket is valid for a path leg of a PuT connection, for several path legs of a connection or eventhe entire connection. Validity depends on the properties of the fare system (see ""Fare-reference" of a fare system" on page 560). This section first talks about applicability,calculation logic and other ticket type properties. To make it easier, this chapter does notalways explicitly point out that a ticket type, if necessary, only applies to individual path legs ofa connection, but talks about connections or paths.A ticket type describes how the fare should be calculated. The fare components of a ticket typeinclude the base fare, the initial fare, the transfer fare as well as the TSys-specificsupplements:

Fare component DescriptionBase fare The base fare is calculated from the fare structure of the ticket type. Four fare

structures can be selected:• Distance-based fare• Zone-based fare • From-to zone-based fare • Short-distance fare

Initial fare The initial fare is charged additionally for the first path leg of the path, namely dependent on the fare system of the first path leg.

Transfer fare The transfer fare is charged additionally for each transfer on the trip, where a new ticket has to be bought, namely dependent on the fare systems where the transfer is made.A transfer procedure may have both positive as well as negative effects on the fare, i.e. the transfer fare is either• a surcharge or• a reduction.

549 © PTV AG


Essential characteristic of a ticket type is the fare structure, which defines the calculationmethod for the base fare:• The distance-based fare is based on distance-based fare items: The base fare is calculated

based on the number of traversed fare points.• The zone-based fare is based on the zone-based fare items: The base fare is calculated

based on the number of fare zones traversed.• The From-to zone-based fare is based on From-To zone-based fare items: The base fare

is the entry of the pair, initial fare zone and target fare zone from the connection of a farematrix, 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 fortickets whose length, duration and number of stops does not exceed the definedthresholds.

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 whichconnections. In the case of the fare structure "Short-distance fare" the restricted applicability isclear, however, the other three fare structures may also have restrictions: Zone-based faresgenerally cannot be applied on connections, which lie outside of the considered fare zones.Both From-to zone-based fares, as well as distance-based fares may only refer to certain pairsof fare zones or certain distance classes.The rank defines the ticket type hierarchy within a fare system and is relevant when a faresystem comprises several ticket types. The definition of the rank is described in severalexamples (see "Ticket selection in a fare system" on page 562).Via the utility rate the conversion factor is specified for a single trip. It is included in thecalculation of the fare of a PuT path.

7.5.2.1 Base fare calculationThe calculation of the base fare is based on the fare structure of the ticket type, of which thereare 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, thecalculation of a distance-based fare is based on the number of fare points on the consideredpath. 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 fareto the traversing of a link for different PuT-TSys.

Transport system-specificsupplements

Supplements are defined separately per ticket type for each PuT transport system and include the following components:• Distance-based supplements

Like distance-based fares, these are based on fare points.• Fixed supplements. These can be charged per path leg or once per transport

system or only for the TSys with the highest rank.

Fare component Description

550 © PTV AG


The traversed fare points of the links and time profile items of the path are summed up, and thefare 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 thedetermined number of fare points, but is "empty".• Example: Fare structure "distance-based fare" Let's look at a ticket type with the following properties:

• Fare constant 10 CU for trips from 1 fare point through 5 fare points,• Fare constant 16 CU for trips from 6 fare points through 10 fare points,• linear increase of the fare from 16 CU to 24 CU between the range of 10 fare points and

20 fare points,• Fare constant 24 CU for trips through 30 fare points,• Ticket cannot be used fro trips with more than 30 fare points.

Expressed in a graph:

Illustration 185: Example for a distance-based fare with 5 fare stages

In VISUM you model this fare as the following distance-based fare stages:

Fare stages for the example on distance-based fare

Number of fare points Interpolate Fare [CU]

≤ 5 No 10

≤ 10 No 16

≤ 20 Yes 24

≤ 30 No 24

> 30 --- [Empty field]

551 © PTV AG


Fare structure "Zone-based fare"Zone-based fares are used in situations where the fare depends on the number of traversedfare zones.A ticket type with zone-based fare refers to a specific fare zone type. Not all fare zones play ageneral role for the tickets, but only those whose "type" corresponds to the fare zone type ofthe ticket. This is how you can especially model independent fare zones belonging to differentfare systems, which can still overlap in space.A zone-based ticket is by default only applicable for paths which completely run over stops,which belong to fare zones of the fare zone type of the ticket type. To replicate the calculationlogic up to and including VISUM 11, you can optionally ignore stops without fare zone. For thecreation 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 thenumber of fare zones and thus the fare. With more complex covering of fare zones there areseveral possibilities of covering a path through fare zones. VISUM then selects the minimumnumber of covering fare zones and thus the most inexpensive fare.A zone-based fare is still not applicable, if the fare stage does not offer a fare for thedetermined number of fare zones, but is "empty".Fare zones do not all have to be equivalent, but can be included with a cardinality into thecount. To do so, select a numeric, integer attribute and allocate the required values. A citycenter zone counts twice in many fare systems for example. It then has to receive cardinalitytwo.Initial fare zones and end fare zones of a path can explicitly be excluded from the applicationof cardinality.You can specify the method of counting fare zones which have been traversed on a pathseveral times. Either each traversed fare zone is counted exactly once, or each entering intoa fare zone causes it to be counted again.• Example: Fare structure "Zone-based fare"

552 © PTV AG


Illustration 186: Example for a zone-based fare with three covering fare zones and six stops.

The fare zones in this example have different cardinalities - fare zone 2 is to be counted twice:

The following base fare is charged for the respective fare zones:

The result being, the traversed fare zones and thus also the fare for all the paths in the examplenetwork:

Fare zone Cardinality

1 1

2 2

3 1

Number of fare zones Base fare [CU]

1 2.00

2 3.00

3 3.50

> 3 4.00

Path Traversed fare zonenumbers

Number of counted fare zones(considering the cardinalities)

Base fare[CU]

Stop 1 - Stop 2 1 1 2.00

Stop 1 - Stop 3 1 1 2.00

Stop 1 - Stop 6 1 and 3 2 3.00

553 © PTV AG


Fare structure"From-to zone-based fare"From-to zone-based fares illustrate a matrix fare between fare zones. The fare thus onlydepends on the start and end fare zones of the path. En route traversed fare zones do not playa role.You can generate a complete fare matrix between all fare zones. From-to zone-based faresare also suitable for the definition of exceptions: If trips from or to specific fare zones underliea different fare structure, you can define the fares of these relations with a From-to zone-basedfare, 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 zoneof 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 thefare zone numbers (x, 0), thus using the value 0 as a wildcard for the end fare zone. Analogentries for (0, y) are possible. Specific entries overwrite general entries, this means a faredefined for (x, y) applies to trips from fare zone x to fare zone y, independent of whether faresfor (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, severalfare zone pairs have to be considered; the fare is then defined as a minimum of all entries.• Example: Fare structure "From-to zone-based fare"For the example in illustration 186, the following From-to zone-based fare can be modeled asan alternative to the zone-based fare:

A comparison with the zone-based fare defined above gives the following differences:• The fare does no longer depend on the exact course of the path; a comparison between

direct and indirect path from stop 1 to stop 6 is no longer possible here, see cell (*).• However, different fares can be determined for paths with an identical number of fare

zones if required - these fares can even be asymmetrical. For example, trips from farezone 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 expressedin a zone-based fare.

The above matrix can be modeled in VISUM as follows:

Stop 1 - Stop 4 1 and 2 3 3.50

Stop 1 - Stop 5 via 3 and 4 1 and 2 3 3.50

Stop 1 - Stop 5 directly via 2 1 and 2 or 1 and 3 2 (for the path through 1 and 3) 3.00

Stop 1 - Stop 6 via 2, 3, 4, 5 1 and 2 and 3 4 4.00

to fare zonefrom fare zone

1 2 3

1 2.00 3.50 (*) 3.00

2 3.50 3.00 3.50

3 3.00 3.50 2.00

from FZ to FZ Fare [CU]

554 © PTV AG


The last entry is a wildcard for all fare zone pairs which were not mentioned explicitly before.You can also express, that the ticket type is not applicable for certain pairs of fare zones:

According to this definition, the ticket cannot be used for all trips to the new fare zone 4 - butfor 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 topaths which meet these threshold values.A short-distance ticket type can also contain more than one set of threshold values (short-distance fare items). You can express for example, that there are specific fares for certain runtimes, for example 1 CU up to 10 min, 2 CU up to 30 min, etc.A short-distance ticket is applicable, as soon as the threshold values of at least one of its fareitems are fulfilled. The fare is defined as the minimum fares of all fare items, whose thresholdvalues are met.• Example Fare structure " Short-distance fare"Fare item 1: Trips to the next stop only cost 0.50 CU:

Fare item 2: as above, but only for trips with a maximum of 5 min run time. The fare is then only0.30 CU.

1 1 2.00

2 2 3.00

3 3 2.00

1 3 3.00

3 1 3.00

0 0 3.50

from FZ to FZ Fare [CU]

4 All 2.70

All 4 [Empty field]

max. run time unlimited

max. distance unlimited

max. number of stops 1

Fare 0.50 CU

max. run time 5 min

max. distance unlimited

max. number of stops 1

Fare 0.30 CU

555 © PTV AG


The fare for fare item 2 can in principle also be selected higher than the fare for fare item 1.This however, would not be reasonable because for trips up to the next stop with maximum 5minutes run time, both threshold values are met, i.e. the fare is the minimum of both fares. Thisminimum would then be 0.50 CU, the second fare item therefore ineffective. This is an examplefor the following aspect:

Consistency of fare stagesThe fare stages of a ticket type (more precisely the fares at the fare items of the ticket type) canbe freely defined. In principle this also makes contradicting entries possible. For example, thefare for a greater distance can be smaller than the fare for a shorter distance, or a short-distance fare for a trip up to three stops can be more expensive than a short-distance fare forup to five stops. It is recommended however, that such contradicting definitions should beavoided.

7.5.2.2 Initial fare and transfer fareIn the standard case, all fare systems are independent, so that the total fare for a connectionis the sum of fares per fare system. Transfer fares allow modeling of interactions. These areadded together with the initial fare to the base fare.The initial fare is only imposed for the first path leg and depends on the fare system of the firstpath 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 aconnection is however greater or equal to zero.• Example: Start and transfer fares (see ""Fare-reference" of a fare system" on page 560)

7.5.2.3 Transport system-specific supplementsEach ticket type has its own supplement regulations. These include PuT transport systemdistance supplements and fixed supplements, whereas for the latter a transport system rankcan 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 thesame 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 thefare system of the ticket type are effective, which means for passengers are able to use theticket type in the first place.

Minimum fareThe minimum fare for each transport system is charged instead of the calculated total fare forthe 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 forthe total fare which has to be charged. Because the regulation applies for all transport systems,the maximum minimum fare of all occurring transport systems, is the lower limit for the totalfare of the ticket type.

556 © PTV AG


Further down you will find a simple example on minimum fares (see "Example: Calculation offixed supplements" on page 557).

Fixed supplementsFixed supplements are constant additional charges which are added to the base fare of theticket type. Each PuT transport system has its own fixed supplement. For which of the pathlegs covered by the ticket type, a fixed supplement can be imposed, is a central feature of theticket 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 theticket 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 theticket type, the maximum fixed supplement of the top-ranking transport system applies. Ranksdo not influence distance-based supplements.In the third case, a fixed supplement is imposed for each path leg anew, for the transportsystem used.The difference between the three options for imposing fixed supplements can be made clearerwith the following example:• Example: Calculation of fixed supplements

These are the following distance-dependent supplements for the ICE:

The considered calculation contains four path legs: IC, RE, IC and ICE. The following tablesshow the calculation of the fare for the three different options for imposing fixed supplements:

Transport system Fixed supplement[CU]

Minimum fare [CU] Rank Distance-based supplement

IC 4.00 0.00 2 No

ICE 0.00 7.00 1 Yes

RE 0.00 0.00 3 No

Number of fare points Fare [CU]

50 0.50

100 1.00

200 2.00

300 3.00

400 4.00

500 5.00

600 6.00

> 600 7.00

557 © PTV AG


1. Supplement once per transport system:

• (*) 0.00 CU, because the IC supplement was already imposed on the first path leg.• (**) 0.50 CU both for additive and proportional calculation of the distance supplement

(see "Distance-based supplements" on page 559).• (***) The minimum fare of 7.00 CU no longer has an effect, because the regular fare of

8.50 CU is higher.2. Supplement only for the top-ranking transport system:

• (*) Only the fixed supplement of the top-ranking transport system (ICE) is obtained,even if in this case it is 0.

• (**) The ICE minimum fare is imposed, because the ICE is used and the regular fare of4.50CU is lower than the ICE minimum fare.

3. Supplement per path leg:

• (*) Different than in the first case, reimposition of fixed IC supplement.

Path legs of theconnection

Fare points Base fare [CU] Fixedsupplement

[CU]

Distancesupplement

[CU]

Minimum fare[CU]

IC 50 4.00 0.00 0.00

RE 200 0.00 0.00 0.00

IC 100 (*) 0.00 0.00 0.00

ICE 50 0.00 (**) 0.50 (***) 7.00

Total 400 4.00 4.00 0.50

Total fare 8.50



[CU]

Distancesupplement

[CU]

Minimum fare[CU]

IC 50 (*) 0.00 0.00 0.00

RE 200 0.00 0.00 0.00

IC 100 (*) 0.00 0.00 0.00

ICE 50 0.00 0.50 7.00

Total 400 4.00 0.00 0.50

Total fare (**) 7.00



[CU]

Distancesupplement

[CU]

Minimum fare[CU]

IC 50 4.00 0.00 0.00

RE 200 0.00 0.00 0.00

IC 100 (*) 4.00 0.00 0.00

ICE 50 0.00 0.50 (**) 7.00

Total 400 4.00 8.00 0.50

Total fare 12.50

558 © PTV AG


• (**) The minimum fare of 7.00 CU no longer has an effect, because the regular fare of12.50 CU is higher.

Distance-based supplementsEach PuT transport system has its own fare stage for distance-based supplements. They arecalculated exactly like distance-based base fares, therefore based on the number of farepoints. The number of fare points for each transport system, is only summed up across thosepath legs which belong to lines of the transport system. Distance-based supplements are alsoadded to the base fare of the ticket type.There are two variants, on how distance-based supplements can be read from the fare table ofthe distance stages:

• proportional calculation• additive calculation

This setting is a ticket type property. For proportional calculation, the distance supplement validfor the sum of fare points over all path legs is taken from the fare table and then multiplied withthe 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 directlyimposed for each transport system.The following calculation example compares the two options:• Example: Calculation of distance-based supplementsOn a connection, 100 fare points are traversed using ICE and 50 using IC. The distance-basedsupplements are as follows:

Distance supplement for proportional calculation:

Distance supplement for additive calculation:

7.5.3 Fare systemsA fare system is a set of lines which have the same fare logic. In principle the passenger cantherefore use these lines with one ticket. A fare system could for example be an individualoperator or a transport association.One or more ticket types are allocated to each fare system for each PuT demand segment.• Example: Fare systems, ticket type and demand segments

Number of fare points (FP) ICE supplement [CU] IC supplement [CU]

<= 50 3.00 2.00

<= 100 4.00 3.00

<= 150 5.00 3.50

FPICEFPICE FPIC+----------------------------------- SupplementICE FPICE FPIC+( )⋅

FPICFPICE FPIC+----------------------------------- SupplementIC FPICE FPIC+( )⋅+

100FP150FP-----------------= 5 00CU, 50FP

150FP----------------- 3 50CU,⋅+⋅ 4 50CU,=

SupplementICE FPICE( ) SupplementIC FPIC( )+ 4 00 CU( ) 2 00 CU( ),+, 6 00CU,= =

559 © PTV AG


There are two demand segments which model whether a monthly pass is in possession or not.This differentiation is made in advance on the demand segment level, because purchasing amonthly pass is a long-term decision and not just when selecting the concrete connection.There are three fare systems in the example: City, Metro and Rail long-distance. The three faresystems are completely impartial for passengers without a monthly pass, where there is anormal 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 whichticket types in which fare system. The following table provides an overview:

The fare system rank plays a role when lines belong to several fare systems, as can be seenin several examples subsequently (see "Procedure for ambiguous fare systems" on page 563).

7.5.3.1 "Fare-reference" of a fare systemThe 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. Asecond 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 faresystem - even if path legs of other fare systems lie in between. All three cases are practice-related.The central fare system attribute Fare-reference is used to model this aspect and can assumeone of the following values:

• Each path leg separately: A ticket has to be bought for each path leg of the faresystem.

• Each group of contiguous path legs: A ticket has to be bought for each group ofcontiguous path legs of a fare system.

• All path legs together: For all path legs together, i.e. for the whole trip, one ticket issufficient for this fare system.

Path legs which belong to another fare system, can never be used with the same ticket.• Example: Fare system properties "Fare-reference"We are looking at a connection with four path legs, with transport systems Bus – Tram – Train– Bus. Using the above example of the three fare systems: Bus and Tram belong to the same

DSeg "Passengers without a monthly pass"

DSeg "Passengers with a monthly pass"

Fare system City(Bus, Tram)

Regular fare City (a Zone-based fare),

Short-distance City (max. 10 min)

Monthly pass region

Fare system Metro

Normal fare metro (a distance-based fare),

Short-distance Metro (max. 3 stops)

Monthly pass region

Fare system Rail long-distance

Single ticket rail Monthly pass rail

Table 205: Linking fare systems and demand segments

560 © PTV AG


fare systems City, the same ticket types are therefore valid. The transport system Trainbelongs to the fare system Rail.To keep the example simple, let's assume the following ticket types:

• Normal fare City: 100 CU for all distances.• Short-distance City: 60 CU for all trips up to max. 10 min. In the example, only the trip

on the first bus is shorter than 10 min.• Normal fare Rail: 200 CU for all distances.

Even if the fare structure has been simplified, this example clearly shows, how the total farechanges subject to the fare-reference. The following fares for the connection apply for eachfare-reference:

• In the first case the passenger pays for each path leg in the fare zone "City" individuallyand only for the first path leg is he allowed to use the short-distance ticket, because allother path legs have an operating time of more than 10 minutes.

• In the second case the successive path legs 1 and 2 can be used with the same ticket.• Only in the third case do you only pay once for the entire fare zone "City".

The third path leg is ignored, because the "Train" belongs to a separate fare system.The example of start and transfer fares are supplemented:• Example: Fare-reference and start and transfer fares

Both fare zones therefore require a initial fare as a base value at trip start. Transfers within thesame fare system cost in the case of "City" an additional charge of 50 CU, in the case of "Rail"nothing. For a transfer from "Rail" to "City" an additional 80 CU is charged, vice versa however,there is a reduction of 20 for a transfer from "City" to "Rail".The following table displays the start and transfer fare, which are added to the base fares listedabove:

Fare applies to...

Path leg - TSys

Fare system Each path leg separately

Each group of contiguous path legs

All path legs together

1 – Bus City 60 (Short-distance) 100

100also includes bus

at the end2 – Tram City 100

3 – Train Rail 200 200 200

4 – Bus City 100 100 no extra fare

Fare sum 460 400 300

Supplement / deduction FS City FS Rail

Initial fare 100 200

Transfer fare from FS City to … 50 -20

Transfer fare from FS Rail to … 80 0

Fare applies to...

561 © PTV AG


Even if the example is simple, you can see what great influence the "Fare-reference" has onthe fare calculation and thus on the fare itself. It is therefore very important to define itaccording to the real fare conditions of the modeled network.

7.5.3.2 Ticket selection in a fare system

In reality the ticket can not always be selected freely – even if in principle several ticket typescan be applied – because there is usually a predefined order. This order is modeled in VISUMby the rank of ticket types. It defines the hierarchy of the ticket types within the fare system.Taking the above example (see "Short overview" on page 546) let's look at the case of anindividual fare system, which has three different ticket types:1. Fare condition descriptions:

2. Modeling in VISUM:To model these fare conditions, the three ticket types have the following properties:

• The airport ticket has the highest rank (for example 1), because it has to be used in allcases 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 initialfare zone and target fare zone of the connection. In this fare matrix however, only those

Path leg - TSys

Fare system Each path leg separately

Each group of contiguous path legs

All path legs together

1 – Bus City 100100

100also includes bus

at the end2 – Tram City 50

3 – Train Rail -20 -20 -20

4 – Bus City 80 80 no extra fare

Sum of start and transfer

fares

210 160 80

Fare sum (see above)

460 400 300

Total fare 670 560 380

1 Normal fare The fare of the ticket type depends on the number of traversed fare zones as follows:

1 fare zone: 2.00 CU

2 fare zones: 3.00 CU

3 fare zones: 3.50 CU

4 or more fare zones: 4.00 CU

2 Airport ticket All trips into or out of the special zone Airport are subject to a exception. They constantly cost 3.75 CU, independent of the fare zone at the other end point of the path.

3 Short-distance fare

For all trips up to ten minutes run time, a short-distance ticket can be used for the fare of 1.00 CU. These do not include trips from or to the airport.

562 © PTV AG


relations whose start or destination fare zone is the airport, are occupied. Other entriesdo not exist, which shows the restricted applicability.

• The short-distance ticket has the next higher rank (for example 2), because for all tripsoutside of the airport, it is always bought when it is applicable. A maximum duration of10 minutes is stipulated. There are however no threshold values for trip distance ornumber of stops.

• The normal (zone-based) fare has the lowest rank (for example 3). In principle the ticketcan 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 tripor short-distance, but one of the other two.

3. Examples for paths in this fare system (and its fares):• A trip over 20 minutes from fare zone city center to fare zone sports field leads through

another fare zone university. These are three fare zones, the fare costs 3.50 CU.• A trip over 8 minutes leads from fare zone city center to fare zone university. A short-

distance ticket applies, the trip costs 1.00 CU.• A trip over 7 minutes and another over 12 minutes leads from fare zone university to

fare zone airport. In each case the airport ticket for 3.75 CU applies.• A trip within the fare zone also costs 3.75 CU.• A trip over 45 minutes from fare zone university via fare zone airport leads to fare zone

industrial park. The airport is not start or destination fare zone, the normal fare for threefare zones (3.50 CU) therefore applies.

7.5.4 Fare calculationThe total fare of a PuT connection is generally equal to the sum of fares for the individual faresystems, which occur on this path. Interactions can only be considered through transfer fares(see "Initial fare and transfer fare" on page 556).Decisive is "those which occur on this path". If the fare system per path leg is clear, i.e. eachused line (or the PuT supplement transport systems) belongs to exactly one fare system, farecalculation is split into separate blocks and the calculation within a block is carried out asdescribed before (see "Ticket selection in a fare system" on page 562).This is also the case for the above example on "fare-reference", because the fare for the trainline is completely independent of the fare calculation for the other three path legs (see"Example: Fare system properties "Fare-reference"" on page 560). In such a simple situation,there is only one possible fare system combination, in step 1 of the algorithm on farecalculation (see "Algorithm on fare calculation" on page 566).The general case of several possible fare systems per path leg, however, requires anextension of the previously described modeling:

7.5.4.1 Procedure for ambiguous fare systemsIf lines belong to several fare systems, many possibilities will potentially occur for the selectionof fare systems (and therefore tickets) on a connection. The following examples show typicalsituations, 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:

563 © PTV AG


• Example: Fare calculation for ambiguous fare systems, trip to C Town, part 1Let's consider the following path legs:

It is assumed, that on the middle path leg both City and Rail ticket types can be used, inparticular 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 faresystems 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 directlybefore or after the used line – exactly then when the "fare-reference" of your fare system (Cityor Rail) is "Each group of contiguous path legs" or even "All path legs together". This aspect ishowever, not subject of the exampleIf no ranks are assigned to the fare systems, all fare systems have the default rank 1, and thereis no hierarchical order. All possibilities have to therefore be examined and the mostinexpensive used, which is what this example wants.• Example: Fare calculation for ambiguous fare systems, trip only to B TownLet's now look at the case, that the trip already ends in B Town:

The validity range of the fare system City is not left and we assume, that the regional train inthis case, is only allowed to be used with tickets from this fare system. This even applies, if itwere 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 areregarded in descending rank order and the highest ranking used, which is applicable. Becausefor the rank 1 fare system a valid ticket already exists in this example, the rank 2 variant is noteven reviewed.• Example: Fare calculation for ambiguous fare systems, trip to C Town, part 2What does this definition of ranks now imply for the previous example, where explicitly bothfare systems could be applied for the regional train line?

From To Line (TSys) Fare system

A Town bus terminal A Town main station Bus 42 (Bus) City

A Town main station B Town Regional train City or Rail

B Town C Town Intercity Rail

From To Line (TSys) Fare system (with rank)

A Town bus terminal A Town main station Bus 42 (Bus) City (#1)

A Town main station B Town Regional train City (#1) or Rail (#2)



A Town main station B Town Regional train City (#1) or Train (#2)

B Town C Town Intercity Rail (#2)

564 © PTV AG


Compared to the case, that the trip ends in B Town, it is not possible to use the entireconnection within the prior-ranking fare system City, because the intercity to C Town is notincluded. A rank 2 fare system is therefore inevitable on this path. This is the starting point fora definition of ranks of fare system combinations, which enable maximum flexibility whenmodeling such fare conditions.

In the example, fare system combinations City-City-Rail and City-Rail-Rail are possible. Theirranks are the same, because max {1, 1, 2} = 2 and max {1, 2, 2} = 2. That is why none of thetwo are prior-ranking; the passenger in the regional train is therefore not fixed to the faresystem City.By allocating rank 1 for fare system City and rank 2 for fare system Rail, it was overall achievedthat the regional train within the City network can only be used with City tickets, but for tripsacross the network boundaries, it can also be used within the Rail fare system.• Example: Fare calculation for ambiguous fare systems, trip to C Town, part 3Let's now look at the variant, that the regional train itself goes to C Town:

In this case it looks as if – exactly like for trips to B Town – the exclusive use of the City faresystem is forced. However, this only applies if the City ticket can be bought up to C Town, iftherefore all stops including C Town lie within fare zones which belong to the zone-based fareof the City fare system. If this is not the case, the attempt to use the connection with faresystems 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 beused on its entire itinerary with tickets of this fare system. An even clearer example is thefollowing:• Example: Fare network with train fare system in the background

1. Description of the network and the fare conditions:

The rank of a combination of fare systems T = {t1, t2,…, tn} is defined as the maximum rankof one of its fare systems: Rank(T) := maxiRank(ti).

With this specification one obtains an order on the set of all fare system combinations.Combinations of the same rank count as being equal. This means in the course of fare calculation, VISUM regards all of them and selects the most inexpensive total fare. Only if there are no valid combinations for a rank, will the combinations of the next lowest rank be considered.The global fall-back fare is only applied if no valid combination exists. This can be assignedwith a value such as -1, to easily identify paths without valid ticket(s) after an assignment. Iffares incur an assignment in the impedance definition, please note that a higher fall-back fare(e.g. 99999) prevents paths without a valid ticket(s) from being found and loaded.



A Town main station C Town Regional train City (#1) or Rail (#2)

565 © PTV AG


A regional train line traverses the range of four fare systems (networks), which all together arezone-based fare systems. There are spatial overlaps between the first and the second as wellas the second and the third.

For trips on the regional train line within a fare system, ticket types of this fare system aremandatory. This also applies, if parts of the fare system area are traversed, which cover adifferent fare system. For trips across the boundaries of a fare system, however, ticket types ofthe 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 inthe covered section of two fare systems. The following regulation applies in this situation: In thecovered sections of fare system 2 with fare system 1 and with fare system 3, the latter hasprecedence.2. Resulting modeling of the ticket type in VISUM:Because the line can at least be partially used in all five fare systems, it has to be allocated toall fare systems. To express the precedence of fare systems 1 and 3 against fare system 2 inthe covered sections of the fare zones, both must have a higher rank (for example 1), than faresystem 2 (for example 2). The rank of fare system 4 is not important, it can be set to 3. The nonzone-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 followingmodel:Each zone-based fare system has a specific fare zone type, for example 1, 2, 3 and 4, andcorresponding ticket types with fare structure zone-based fare. The spatial overlap of zone faresystems arises in the overlap of their fare zones. All stops served by the line, thus lie exactly inone 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 alltraversed stops lie within fare zones which belong to the fare system of the ticket. Two tickettypes can only be used in the covered range of the fare systems and there the fare systemranks provide specified preference. The fare system "Rail long-distance" is used as a fall-back,because a valid ticket can be bought for this one in any case.

7.5.4.2 Algorithm on fare calculationThe succession of all decisions which lead to the selection of the ticket(s) used on a path, canbe formulated as an algorithm. This particularly clarifies the meaning of the ranks for faresystems and tickets.

566 © PTV AG


Each path consists of a sequence of path legs. Each path leg has one PuT line which isconnected to one or more fare systems (or a PuT-Aux transport system which is also allocatedto 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. indescending ranking order (whereas Rank of the combination = Maximum rank of the faresystems in the combination). Calculate the fare for each combination according to step 2.Select the lowest fare from the fare system combinations of the same rank. If all faresystems of a rank are invalid, consider the combinations of the next rank. If there is no validfare 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 andcalculate their fares according to step 3. If all calculations lead to a valid fare, the sum is avalid 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 thefare system path legs separate ticket types have to be used. Iterate over all these path legsubsets and calculate their fares according to step 4. If all calculations supply a valid fare,the sum is a valid fare for the fare system. If not, fare calculation for this fare system fails.

4. Consideration of a fare system of a path leg subset:For a fare system and a predefined path leg subset, iterate over all ticket types which areused by the fare system, in descending order. Calculate the fare for each ticket typeaccording to step 5. From the ticket types of the same rank, select the one with the lowestfare. 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-basedfare, Zone-based fare, From-to zone-based fare, Short-distance fare). If the fare table doesnot contain a valid entry, the ticket type cannot be applied. Add up the initial fare for the firstpath leg of the path. Add up the transfer fare according to the fare system which was usedon the preceding path leg.Determine and add up the distance-based supplement for the number of fare pointscounted. If the table does not contain a valid entry, the ticket type cannot be applied.Determine and add up the fixed supplement. Compare the total fare with the minimum faresof all occurring transport systems and raise it if necessary.

7.5.5 Application of faresWith the fare model, fares can be included in the timetable-based assignment in theimpedance of a connection and thus have influence on the connection choice. This does notapply for the headway-based assignment, because route choices are not made betweencomplete connections, but for each boarding and transfer decision. This is a basiccharacteristic of this family of assignment procedures and cannot be avoided due tomethodical reasons. Linear dependency of the fare from the (measured in fare points) covereddistance can still be modeled in the headway-based assignment, because the number of fare

567 © PTV AG


points is included directly in the impedance and furthermore boarding penalties and transferpenalties can be allocated.The following skim matrices can be derived from both PuT assignment types:• Fare• Number of traversed fare zonesPlease note that the skim "Number of fare zones" only counts those fare zones, which arerelevant 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 ofthis ticket do not play a role and are not counted for the skim. This is necessary, becauseseveral fare zone systems, separated by type, may exist next to each other and each tickettype 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 pathlegs" 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 asa revenue per fare point.Fares from the fare model can also be used as input data for Revenue calculation within thePuT operating indicators (see "Revenue calculation using the fare model" on page 597).

7.6 PuT Operating IndicatorsLine costing calculations are based on operational indicators. They can be divided into thefollowing categories:• General indicators• Indicators for the measurement of transport supply• Indicators for the measurement of transport performance• Indicators for the calculation of operating costs• Indicators for the calculation of fare revenues• Indicators for vehicle requirement and line blocking (see "Line blocking" on page 500).The indicators are described in the indicator categories. Which network objects the indicatorscan be calculated for, can be taken from the file IndicatorAvailability.xls in the directory...\VISUM115\Doc\Eng of your VISUM installation.Dependent on the indicator, different procedures have to be carried out, to calculate theindicator values. Some indicators are already available after a PuT assignment, others afterthe 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. Anoverview of this dependency you can find in the file IndicatorSource.xls in the directory...\VISUM115\Doc\Eng of your VISUM installation which provides the following details: Whichprocedure has to be used for which indicator and which settings have to be made for thecalculation. Basically, the following procedures are relevant for the calculation:• PuT Operating Indicators • Territory indicators • PuT assignment

568 © PTV AG

Chapter 7.6: PuT Operating Indicators

• Line blocking The indicators are basically calculated for analysis period, analysis horizon and analysis timeintervals (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 indicatortable (IndicatorAvailability.xls) as follows:• AHP = available for analysis period and analysis horizon• AHPI = available for analysis time intervals, analysis period and analysis horizon.• X = indicator is available, but does not show a time reference

7.6.1 Demonstration example The following example Example_LLE.ver (illustration 187) is used to illustrate the indicatorcalculations. The description of the indicator categories pick up this example again. You canfind the example file in the directory ...\VISUM115\Examples\Example_Net\.

Illustration 187: Example network with two lines and volume data

Transport SupplyThe transport system of the demonstration example consists of two lines with two line routesper line (outward and return line routes), but partially shortened trips.

Line Orig. Stop

Dest. Stop

Length [km]

First dep.

tCur [min]

Last dep.

Run time [min]

Number of trips

Valid Day

BUS > 10 40 27.5 06:07 00:40 18:07 00:45 19 daily

Table 206: Transport supply in Example_LLE.ver

569 © PTV AG


Projection factors and analysis time slicesThe model contains an analysis time period TI1 for the traffic during morning peak hours (8a.m. to 9 a.m.). The projection factors on the analysis horizon on the valid days are assignedrespectively (see User Manual, Chpt. 2.41, page 550).

The projection factor for demand segment PuT is allocated as follows.

Vehicles used

Fare ModelThe fare model includes two fare zones, which have been assigned the following stops.

BUS < 40 10 27.5 06:02 00:40 18:02 00:45 19 daily

BUS > 30 40 7.5 05:37 00:40 17:37 00:13 19 weekdays

BUS < 40 30 7.5 06:29 00:40 18:29 00:13 19 weekdays

TRAIN > 20 40 10.0 06:29 00:40 18:29 00:16 19 daily

TRAIN < 40 20 10.0 06:09 00:40 18:09 00:16 19 daily

Valid Day Proj. factor transport supply Proj. factor hourly costs

daily 365 365

weekdays 260 260

Table 207: Projection factors for the valid days in Example_LLE.ver

Demand segment Projection factor

PuT 365

Table 208: Projection factor for the demand segment

Vehicle type SeatCap Total Capacity

Standard bus 35 90

Low floor bus 35 50

Train 200 400

Table 209: Total capacity provided in the vehicles of example Example_LLE.ver

Number Name FZ100 FZ200

10 A Village X

20 C Village X

30 B Village X X

40 X City X

Table 210: Fare model in Example_LLE.ver

Line Orig. Stop

Dest. Stop

Length [km]

First dep.

tCur [min]

Last dep.

Run time [min]

Number of trips

Valid Day

Table 206: Transport supply in Example_LLE.ver

570 © PTV AG


Stop 30 (B village) is located exactly between fare zones FZ100 and FZ200, and is thereforeassigned to both fare zones.

Tickets and Fares

Additionally, a supplement of 3.00 CU (currency units: for example, Euro, Pound, Dollar) isrequired for each rail ticket.

Transport demandTable 212 displays the number of passengers between the zones.

Cost rates• Link costs

Track charge of 100 CU/km on railway track between stop 20 and stop 40, plusdepreciation charge of 100000 CU. All other links have a utilization fee of 10 CU/Km andrunning costs of 20 CU in the analysis horizon.

• Vehicle costs

Fare zones One-way ticket [CU] Four-trip ticket [CU] Monthly pass [CU]

One-way fare Fare One-way fare Fare One-way fare

up to 2 fare zones 1.00 3.20 0.80 60.00 1.50

up to 3 fare zones 2.00 6.40 1.60 60.00 1.50

up to 4 fare zones 3.00 10.40 2.60 60.00 1.50

as of 4 fare zones 5.00 12.00 3.00 80.00 2.00

Table 211: Fares of the fare model in Example_LLE.ver

FromZone ToZone Line1 Line2 Demand

A Village X City Bus1 Train 2000

X City A Village Train Bus1 2000

A Village C Village Bus1 200

C Village A Village Bus1 200

C Village X City Train 5000

X City C Village Train 5000

B Village X City Bus1 2000

X City B Village Bus1 2000

Total 18400

Table 212: Transport demand between the zones in Example_LLE.ver

Standard bus Low floor bus Train

Service Empty Service Empty Service Empty

Cost rate per hour [CU/h] 300.00 200.00 300.00 200.00 700.00 500.00

Cost rate per km [CU/km] 5.00 5.00 5.00 5.00 10.00 10.00

Table 213: Cost rates for vehicles in Example_LLE.ver

571 © PTV AG


• In addition, a charge of 50 CU/h is due for each vehicle combination Train.• The operator costs amount to annual administrative costs of 1000 CU for the bus operator

and 5000 CU for the train operator as well as depreciation costs of 100000 CU each.

7.6.2 Indicators for line route and timetable evaluationThe following indicators comprise line data, which are made up of the line route and thetimetable. Demand data is not required for calculation.

Cost rate per vehicle [CU/Veh/AP]

7000.00 7000.00 20000.00

Standard bus Low floor bus Train

Table 213: Cost rates for vehicles in Example_LLE.ver


LineNetLengthDir

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.

LineNetLengthUndir

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 lengthundirected

Compared to directed network length, for links the average link length (this means the mean value from the lengths of both directions) is counted for both open directions.

Num lines The meaning of this indicator depends on the network object for which it is being calculated.• Main lines take the number of lines into consideration, which belong to the main line.• PuT operators take the number of lines into consideration, which are operated by

the PuT operator.• Blocks take the number of lines into consideration, which are traversed on a block.• Links take the number of lines into consideration, which traverse a link.• Transport systems take the number of lines into consideration, which use this

transport system.• For zones / main zones, a line is regarded, if the zone is connected to a node with

a stop point, which is traversed by the line. No line trip has to serve the stop point• Stops take the number of lines into consideration, which traverse this stop. No line

trip has to serve the stop point• Stop points take the number of lines into consideration, which traverse this stop

point. No line trip has to serve the stop point

Num lines TSys Additionally returns the number of lines for each transport system. Otherwise, the indicator is analog to the number of lines.

Num line routes Number of line routes of a line or number of line routes run by a vehicle combination during a block.

Stop points total Number of stop points, which lie within a territory polygon.

Table 214: Indicators for line route and timetable evaluation

572 © PTV AG


Stop points served

Number of served stop points, which lie within a territory polygon. A stop point is served, when it is traversed by a line route. Thus, a line route item with this stop point is required and for the respective time profile item boarding or alighting has to be possible. It is not necessary that trips serve this stop point.

Stops served The meaning of this indicator depends on the network object for which it is being calculated.• Territory PuT detail regards the number of served stops being located within a

territory polygon. Stops are not served, if none of the time profiles includes a stop at one of the stop's stop points. Multiple stops within a stop are only counted once

• Lines take the number of stops into consideration, which are traversed by a line. This is independent of whether a stop at the respective stop point is intended in the time profile or not.

• Line routes regard the number of served stops, which are traversed by the line route. This means, that stops are not served, if no time profile contains a stop at one of the stop's stop points.

• Time profiles take the number of stops into consideration, for which a stop is intended for its stop points, in the TP.

• Service trips take the number of stops into consideration, where a service trip stops.• Transport systems take the number of stops into consideration, which a transport

system traverses. This is independent of whether a stop (boarding or alighting) is intended in the respective time profiles.

Stop events Number of stop events at stops within the territory polygon. All stop events at the stops are counted. A trip is thus counted several times, if a trip stops at several stop points within the stop. If a stop point lies in another territory than the respective stop, the stop still counts for the stop in the territory. The number of stop events in the territory counts for each service trip and is aggregated for the other levels, if necessary. Different from the indicator "Stop points served" trips are required. Otherwise stop events do not count.

StartStopEvents Number of service trips, which start at a stop in the territory.

EndStopEvents Number of service trips, which end at a stop in the territory.

Earliest departure

Earliest departure from stop point located inside territory. This is the earliest departure within the analysis time slice, not necessarily the first departure of the day (for example, departure at 12:20 a.m.).

Latest arrival Latest arrival at stop point located inside territory. This is the latest arrival within analysis time slice, not necessarily the last departure of the day (for example, arrival at 11:59 p.m.).

StopTime The stop time, which accumulates from stop events at stop points within the territory polygon. The stop time is made up of the input attribute Stop time at the time profile items.



573 © PTV AG


Num departures The meaning of this indicator depends on the network object for which it is being calculated. The indicator is especially interesting for time interval-related analyses, to determine the departures within a certain time interval for example. • For main lines / lines it returns the number of service trips run by this line.• For line routes it returns the number of service trips run by this line route• For time profiles it returns the number of service trips using this time profile• For PuT operators it returns the number of service trips operated by this PuT

operator• For transport systems the number of service trips operated with this transport

system• For stops, the number of service trips which stop for boarding is returned. Stop

events at several stop points within the stop are counted several times. If a stop is traversed several times within a trip, the departures are also counted several times

• For stop points, the number of service trips which stop for boarding is returned.

Num departures TSys

Different from Num.Departures, the number of departures is returned by transport system. Calculation is otherwise analog.

Num arrivals Number of service trips, which stop for alighting at the stop or the stop point. Multiple stop events are counted several times for a stop.

NumArrivalsTSys

Different from Num.Arrivals, the number of arrivals is returned by transport system. Calculation is otherwise analog.



574 © PTV AG


Num Service Trips

The meaning of the indicator depends on the network object for which it is being calculated:• For territory analyses, the number of service trips traverse a territory is returned. A

service trip is added to the territory, if at least one stop of the service trip lies within the territory The stop point location is not crucial, but the stop location.

• For main lines / lines / line routes, the number of service trips by main line / line / line route is returned

• For the line route course, the number of service trips traversing the line route item is returned (start and end stop point of the trip are decisive, it is irrelevant whether boarding or alighting is permitted)

• For time profiles, the number of service trips using this time profile is returned• For time profile items the number of service trips traversing the time profile item is

returned (crucial is the start and end stop point of the trip). It is irrelevant whether boarding or alighting is permitted

• For service trips it is specified, how often the service trip runs in the respective time period (AH, AP, TI)

• For service trip items it is returned, how often this service trip traverses the respective service trip item (crucial are start and end stop points of the trip). It is irrelevant whether boarding or alighting is permitted

• The number of service trips run by the PuT operator is returned by operator• For blocks the number of service trips being included in the block is returned• For links, the number of service trips traversing the link is returned. A link is

regarded as if being traversed, if the service trip traverses more than 50% of the link´s length

• For a transport system, the number of service trips using this transport system is returned

• A service trip counts for a zone, if the zone is connected to a node with a stop point, which is served by the service trip (boarding or alighting permissible)

• For a stop, the number of service trips serving the stop for boarding or alighting is returned. Multiple stop events at stop points of the stop are counted several times

• For a stop point, the number of service trips serving the stop point for boarding or alighting is returned

Num ServiceTrips proportional

For PuTDetail evaluations this indicator only differs from the Num ServiceTrips, if there are trips with several trip sections and these differ in terms of the vehicle combination. Different from the Number of Service Trips the number of service trips is then distributed to trip sections. If the trip sections only differ with regard to the valid days, the 'Num ServiceTrips proportional' value complies with 'Num ServiceTrips'. Therefore, the evaluation of this indicator is useful for territory analyses only for levels in combination with xVehComb.

Num ServiceTrips TSys

Different from the Num.ServiceTrips, the number of service trips is returned by transport system. Calculation is otherwise analog.

MeanServiceLength

Calculation is dependent on the network object.

• For a transport system applies

• Otherwise it applies



Service kilometers Number Service trips---------------------------------------------------------

Service kilometersNumber Departures----------------------------------------------------

575 © PTV AG


Calculation example: Number of departures per transport system• Number of departures for analysis period = number of service trips, which depart on Jan 02,

2006For 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 ofvalid dayFor the bus, the number of departures is calculated (AH) = 38 • 365 + 38 • 260 = 23750For the train, the number of departures is calculated (AH) = 38 • 365 = 13870

• Number of departures for analysis time period TI1 = Number of service trips, whosedeparture 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 systemFor the analysis period and the analysis horizon, the number of service trips complies with thenumber of departures in this example. The difference between the two indicators can be seenwhen looking at the analysis time interval TI1. Now also service trips are counted, whosedeparture does not lie in the time interval between 8:00 a.m. and 9:00 a.m., though they arerunning in this time slice.• Number of service trips for analysis time interval TI1 = Number of service trips, whose

departure time lies between 8 a.m. and 9 a.m.For the bus, the resulting number of service trips (TI) = 10 (Trip no. 98, 99, 100, 118, 119,120, 138, 139, 156, 157)For the train, the resulting number of service trips (TI) = 4 (Trip no. 60, 61, 80, 81)

7.6.3 Measurement of the transport supplyTransport supply indicators express operational efforts in length units or in time units. Demanddata is not required for their calculation.

MeanServiceTime

Calculation is dependent on the network object.

• For a transport system applies

• Otherwise it applies

isCoupled (Respective) time profile is coupled with another time profile (1) or not coupled (0).

IsEffectivelyCoupled

Coupling is effective, if a trip which is coupled to another trip via a respective time profile, actually runs (this means, that for each coupled TP at least one trip has to exist which is active and furthermore has a valid ValidDay. A valid ValidDay lies within the analysis period and both coupled trips run on the same day).



Service timeNumber Service trips--------------------------------------------------------

Service timeNumber Departures----------------------------------------------------

576 © PTV AG



Service Kilometers Kilometers covered on service trips. Trip length via all service trips and number of departures.

Section Service Kilometers

Compared to ServiceKm, the length of each individual vehicle journey section is added (as long as it lies within the analysis period).

ServiceTime Time required by service trips. Duration via all service trips and number of departures.

Section Service Time

Compared to service time, the duration of each individual vehicle journey section is added (as long as it lies within the analysis period).

Empty Kilometers Kilometers covered on empty trips. Compared to service trips, no passengers are carried on empty trips. Empty kilometers = Pull-out kilometers + Interlining kilometers + Pull-in kilometers

Section Empty Kilometers

Compared to EmptyKm, the length of each individual vehicle journey section is added (as long as it lies within the analysis period).

EmptyTime Time covered on interlining trips Compared to service trips, no passengers are carried on empty trips.EmptyTime = Pull-out time + Interlining time + Pull-in time

Section Empty Time

Compared to empty time, the duration of each vehicle journey section is added (as long as it lies within the analysis period).

Operating kilometers

Operating kilometers = Service kilometers + Empty kilometers

Section operating kilometers

Compared to OperatingKm, the length of each individual vehicle journey section is added (as long as it lies within the analysis period).

Operating Time Operating time = Service time + EmptyTime

Section Operating Time

Compared to operating time, the duration of each vehicle journey section is added (as long as it lies within the analysis period).

SeatCap Sums up the number of seats of the vehicle combinations over all vehicle journey sections of the object, for which the indicator is determined (e.g. lines). This attribute is only available for the elements of the line hierarchy and for PuT operators and transport systems.

Seat Kilometers Seat Km = Section Service Km • Number of seats of vehicle combinationsSummed up over all vehicle journey sections and number of departures.

Seat Hours Seat Hours = Section Service Time • Number of seats of vehicle combinationsSummed up over all vehicle journey sections.

Total Capacity Sums up the total seating and standing capacity of the vehicle combinations over all vehicle journey sections of the object, for which the indicator is determined (for example, lines). This attribute is only available for the elements of the line hierarchy and for PuT operators and transport systems.

Total Capacity Kilometers

Total Capacity Km = Section Service Km • Total seating and standing capacity of the vehicle combinationsSummed up over all service trip sections.

Total Capacity Hours

Total Capacity Hours = Section Service Time • Total seating and standing capacity of the vehicle combinationsSummed up over all vehicle journey sections.

Table 215: Indicators of the transport supply

577 © PTV AG


Calculation example: Service kilometers per transport system• Service km for the analysis period = Number of trips (AP) • Trip length.

For the bus it applies that ServiceKm (AP) = 38 • 27.5 km + 38 • 7.5km = 1,045 km +285 km = 1,330 kmFor 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 dayFor the bus it applies that ServiceKm (AH) = 1045 km • 365 + 285 km • 260 = 455525 kmFor the train it applies that ServiceKm (AH) = 380 km • 365 = 138700 km

• Service km for the analysis time interval TI1 results from summing up the km data from alltrip sections, whose respective line route items depart in this time sliceFor the bus it applies that ServiceKm (TI1) = 113.75 km. The calculation is made clearer byillustration 188.

Length Length covered by the time profile items in the territory. (Attribute is available via Territory - PuT Detail only for level Territory x Time profile (x Vehicle Combination).)

Run time Time used for covering the time profile items in the territory. (Attribute is available via Territory - PuT Detail only for the level Territory x Time profile (x Vehicle Combination).)

Mean Speed Mean speed = Service kilometers / Service time

Capacity PuT Seats

Number of seats of vehicle combinations, which traverse this link, summed up over all vehicle journey sections. (Attribute is only available for links.)

Capacity PuT total Total seating and standing capacity of the vehicle combinations, which traverse this link, summed up over all vehicle journey sections and the number of departures (Attribute is only available for links).

Number of Vehicles (in proportion to length)

The number of vehicles which are - according to the current block version - required for the reference object, (line, line route, etc.). The indicator value corresponds to the number of blocks, which cover the vehicle journey sections of the reference object. If a block covers vehicle journey sections of several objects, for the vehicle only the proportion of the vehicle journey sections of the reference object is added to the line length of all vehicle journey sections.

Number of vehicles (in proportion to time)

As above, but the addition to the reference object is instead carried out with the share of vehicle journey sections of the reference object in the service time of all vehicle journey sections.


Table 215: Indicators of the transport supply

578 © PTV AG


Illustration 188: Calculation of service kilometers between 8 a.m. and 9 a.m.

For the train it applies that ServiceKm (TI1) = 3 • 10 km = 30 km (Trip numbers 61, 80, 81)

Calculation example: Seat km per transport system• Seat km for the analysis period = ServiceKm (AP) • Number of seats summed up over all

trip sections.For the bus it applies that SeatKm (AP) = 1330 km • 35 = 46550 kmFor 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 summedup 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 kmFor 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 kmcalculation (illustration 188).For the bus it applies that SeatKm (TI) = 35 • (27.5 + 3.75 + 15 + 12.5 + 5 + 27.5) km + 35• (7.5 + 7.5 + 7.5) = 3,981.25 kmFor the train it applies that SeatKm (TI) = 30 km • 200 = 6000 km

579 © PTV AG


Calculation example: Service time per transport system• Service time for the analysis period = Num PuT Departures (AP) • Times from Time profiles

For the bus it applies that ServiceTime (AP) = 38 • 45 min + 38 • 13 min = 2204 min = 36 h44 minFor 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 daysummed 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 minFor the train it applies that Service time (AH) = 38 • 16 min • 365 = 221920 min = 3698h40 min

• Service time for the analysis time interval TI: Calculation is done analog to the servicekilometer calculation (illustration 188).For the bus it applies that service time (TI) = 45 min + 13 min + (5 km/10 km) • 13 min +12 min + (5 km/10 km) • 20 min + 13 min + 13 min + (5 km/10 km) • 20 min + 0 min + (5 km/10 km) • 12 min + 45 min + 13 min = 186.5 min = 3 h 10 minFor 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/hFor the train it applies that vMean = 380 km / 10 h 8 min = 37.5 km/h

7.6.4 Measurement of the network performanceThe indicators of the network performance result from the PuT line use by passengers. For thecalculation of the indicators, the volumes have to be available from the PuT assignment. Someof the indicators are automatically calculated during assignment (see overview tableIndicatorSource.xls in the directory ...\VISUM115\Doc\Eng).]


Passenger kilometers(DSeg)

The link that passengers are driving with the PuT vehiclePassenger kilometers = Passenger trips unlinked • trip distance from Boarding to Alighting stop

Passenger hours(DSeg)

Time which the passengers spend in the PuT vehiclePassenger hours = Volume • Duration

Passenger trips TSys (DSeg)

Repeated boarding the same transport system is not counted more than once (for example transferring from one bus into another).

Passenger trips Unlinked / Passenger trips Unlinked PuT

Unlinked passenger trips match the number of boarding passengers per object. Counts each passenger using at least one line route item in the territory. No passengers are counted for path legs that end exactly at the start or start exactly at the end of a time interval.

PTrips Unlinked PuT DSeg

Number of passengers boarding per object additionally differentiated according to demand segments. This attribute is only available for zones.

Table 216: Indicators of the network performance

580 © PTV AG


PTrips Unlinked >2xTransfer (DSeg)

Passenger trips with 3 or more transfers on their way from origin zone to destination zone. This attribute is only available for the elements of the line hierarchy.

PTrips Unlinked with 0xTransfer (DSeg)

Passenger trips without transfer on their way from origin zone to destination zone. This attribute is only available for the elements of the line hierarchy.

PTrips Unlinked with 1xTransfer (DSeg)

Passenger trips with exactly one transfer on their way from origin zone to 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 • 100This attribute is only available for the elements of the line hierarchy.

Boarding passengers (DSeg)

Number of boarding passengers. This also includes passengers, which are transferring from another line (This attribute is only available for the elements of the line hierarchy and for stops and stop points.).

Alighting passengers (DSeg)

Number of alighting passengers. This also includes passengers, which are transferring to another line (This attribute is only available for the elements of the line hierarchy and for stops and stop points.).

PassOrigin (DSeg)

Number of boarding passengers, which have this stop as their origin. Passengers which transfer here are therefore not counted. (This attribute is only available at stops and stop points.)

PassDestination (DSeg)

Number of alighting passengers, which have this stop as their destination. Passengers which transfer here are therefore not counted. (This attribute is only available at stops and stop points.)



581 © PTV AG


Calculation example: Passenger trips per line• Number of Passenger trips per analysis period

For the bus it applies that 8400 = 200(A->C) + 200(C->A) + 2000(A->X) + 2000(X->A) +2000(B->X) + 2000(X->B)For the train it applies that 12000 = 5000(C->X) + 5000(X->C) + 1000(A->X) + 1000(X->A)

• Passenger trips 0 transfers analysis periodFor 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 periodFor 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 stopFor the bus it applies that 2400 • 10 km(A<->C) + 2000 • 27.5 km(A<->X) + 4000 •7.5 km(B<->X) = 109000For the train it applies that 12000 • 10 km(C<->X) = 120000

PassThrough Number of through-going passengers. These are all passengers traveling with a line, which traverses this item of a line route / time profile / service trip, however, they neither board nor alight here (This attribute is only available for the elements of the line hierarchy).

PassThrough with stop (DSeg)

Number of passengers with stop event. These are all passengers traveling with a line which stops at this stop point, however, they neither board or alight here (This attribute is only available for stops and stop points).

PassThrough without stop (DSeg)

Number of through passengers without stop event. These are all passengers traveling with a line, which passes the stop point, but does not stop there. (This attribute is only available for stops and stop points.)

PassTransfer Number of passenger transfers in the territory (This attribute is only available for territories).

PassTransTotal (DSeg)

Total number of passengers transferring at this stop or stop point (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.)



582 © PTV AG


• The value Passenger kilometers per analysis horizon is calculated as follows: PassKm(AH)= PassKm(AP) • Projection factor of the demand segment summed up over all demandsegments.For the bus it applies that 109000 km • 365 = 39785000 kmFor the train it applies that 120000 km • 365 = 43800000 km

• Passenger kilometers per analysis time interval TI:For the bus it applies that 9660 km. The calculation can be taken from illustration 189:

Illustration 189: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m.

For the train it applies that 3 • 10 km • 316 = 9480 km

Calculation example: Passenger hours per transport system• The value Passenger hours per analysis period is calculated as follows: PassHour(AP) =

Passenger trips • Run time from Boarding to Alighting stop.For the bus it applies that 2400 • 12 min + 2000 • 45 min + 4000 • 13 min = 2846 h 40 minFor the train it applies that 12000h • 16 min = 3200 h

Note: Unlike the calculation of transport supply indicators, the projection factor of the demandsegment is regarded for the network performance indicators' projection to the analysishorizon (AH) (see User Manual, Chpt. 2.10.3, page 179).

583 © PTV AG


• The value Passenger hours per analysis horizon is calculated as follows: PassHour(AH) =PassHour(AP) • Projection factor of the demand segment summed up over all demandsegments.For the bus it applies that 2846 h 40 min • 365 = 1039033 h 20 minFor the train it applies that 3200 h • 365 = 1168000 h

• The value Passenger hours per analysis time period TI is calculated as follows.For the bus it applies that 255 h 55 min. The calculation can be taken from illustration 190.

Illustration 190: Calculation of passenger kilometers between 8 a.m. and 9 a.m.

For the train it applies that 3 • 16 min • 316 = 252 h 48 min

7.6.5 Calculation of operating costs and fare gains (revenues)illustration 191 gives an overview of the cost and revenue model in VISUM and the interrelationwith the assignment results. The attribute names are bold in the depiction. Different settingshave to be made (see User Manual, Chpt. 7.3.2, page 1076).

584 © PTV AG


Illustration 191: Calculation schema for costs and revenues

7.6.6 Calculation of the operating costsThe total costs can be divided into vehicle-dependent costs and infrastructure costs. These arethe provided cost blocks:

Note: Please note that the reference period for costs and the reference period for revenueshave to match, in order to get reasonable cost coverage results. The revenues are calculatedfor the assignment time interval. The attribute passenger trips total reflect the number ofpassenger trips in the assignment time interval, which means that there is a variation in thedependency of the length of the assignment time interval. The revenues therefore also varyin dependency of the choice of assignment time interval. The costs however, are based onthe analysis period. Because the assignment time interval often only comprises the peak hour(for example the evening rush hour from 4 p.m. to 6 p.m.), it is necessary to project this resultto the analysis period, when calculating cost coverage in your model or if you want tocombine indicators, which are calculated in the assignment, with indicators which arecalculated in the procedure PuT operating indicators (file IndicatorSource.xls in the directory...\VISUM115\Doc\Eng). To create the same reference period, you have to define a projectionfactor from the assignment time interval to the analysis period on the demand segment (seeUser Manual, Chpt. 7.2, page 1072). The projection factor 1 is only correct here, if you carryout an assignment for the whole day.

585 © PTV AG


The total costs which accumulate for operating public transport, are returned in the followingattribute.

7.6.6.1 Vehicle type-dependent costsThe costs for a vehicle is composed of hourly costs, kilometer costs and fixed costs. In VISUM,these costs are assigned to vehicle units (see User Manual, Chpt. 7.2.2, page 1072). Inpractice these kilometer and vehicle costs are dependent on the vehicle type used (forexample standard or articulated bus, or tram in single or multiple traction) and the hourly costsof the operator (for example public or private operator, type of labor contract).

Vehicle type-dependent costs

Hourly costs / Cost time

Time-dependent costs for personnelTime costs = service time • hourly costs rate of service trips + empty time • hourly cost rate of empty trips

Kilometer costs / Cost distance

Kilometer-dependent costs for fuel, repairs, etc.Distance costs = ServiceKm • kilometer cost rate of service trips + empty kilometer • kilometer cost rate of empty trips

Vehicle costs / Cost vehicle

Assigned fixed cost for a vehicle (debt service as well as other fixed costs such as insurance costs).Vehicle costs = cost rate per vehicle unit • number of vehiclesThe number of vehicles is an output attribute of line blocking.

Table 217: Vehicle type-dependent costs

Infrastructure costs

Stop point costs / Cost stop point

Costs for the usage of stop points These can be composed of depreciation costs (for example investment costs), running costs (for example maintenance costs) and utilization costs (for example fees for using the stops).

Costs 1/2/3 stop points

Three cost rates which are included in the calculation of stop point costs (see "Stop point costs" on page 590).

Link costs / Cost links

Costs for the usage of links (infrastructure cost) The link costs are divided equally between the service trips which use the link.

Costs 1/2/3 links Three cost rates which are included in the calculation of link costs (see "Link costs" on page 588).

Operator costs / Costs operator

Share of costs for general operational costs These can be composed of depreciation costs (for example investment costs) or running costs (for example maintenance costs).

Costs 1/2/3 operators

Three cost rates which are included in the calculation of operator costs (see "Operator costs" on page 591).

Table 218: Infrastructure costs

Total costs

Costs Costs = time costs + distance costs + vehicle costs + stop point costs + link costs + operator costs

Table 219: Total costs

586 © PTV AG


Hourly costs (attribute Cost time)Time costs = service time • hourly costs rate of service trips + empty time • hourly cost rate of emptytrips

• Service time describes the time for passenger transport. It can be taken from thetimetable.

• Empty time comprises the times for delay buffers, driver breaks or interlining andlayover. Line blocking is required for determining the empty times, otherwise this shareis not included in the hourly costs.

Kilometer costs (attribute Cost distance)Distance costs = ServiceKm • kilometer cost rate of service trips + empty kilometers • kilometer costrate of empty trips

• Service kilometers for transporting passengers are calculated directly from the servicetrips in the timetable.

• Empty kilometers arise from interlining trips between the last stop of a service trip andthe 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 UserManual, Chpt. 2.27.2, page 371), and the vehicle demand determined by PuT line blocking.Vehicle costs = cost rate per vehicle unit • number of vehicles

• The attribute Cost rate per vehicle unit contains the fixed costs for each vehicle unit (theacquisition costs for example). Fixed costs increase with every additional vehiclerequired.

• The value Number of vehicles results from the necessary vehicle blocks. Line blockingis therefore assumed for the calculation of vehicle costs.

Calculation example: Vehicle type-dependent costs for linesThe following vehicle type-specific cost rates are the basis for the example (see"Demonstration example" on page 569).

Vehicle units Standard bus Low floor bus Train



Cost rate per km [CU/km] 5.00 5.00 5.00 5.00 10,00 10,00

Cost rate per vehicle unit [CU/Veh]

7000.00 7000.00 20000.00

Reference period of the cost rate per vehicle unit

Analysis period Analysis period Analysis period

Table 220: Cost rates for the vehicle units

Vehicle combinations Standard bus Low floor bus Train


Table 221: Cost rates for the vehicle combinations

587 © PTV AG


The following distances and times accumulate for the train:

Calculating the vehicle type-dependent costs (distance costs, time costs and vehicle costs) forlines returns the following result for the Train line.• Distance costs / analysis periodCostDist(AP) = CostKmService • ServiceKm(AP) + CostKmEmpty • EmptyKm(AP)

• Time costs / analysis periodCostTime(AP) = CostTimeService • ServiceTime(AP) + CostTimeEmpty • EmptyTime(AP)

• Vehicle costs / analysis periodCostVehicle(AP) = Cost rate vehicle unit • Number of vehicles

7.6.6.2 Link costsLink costs are infrastructure costs, which accumulate when using a link. The link costs aredivided equally between the service trips which use the link. Up to three cost values (attributeCostRate1 to 3) can be specified per link and transport system to model link costs (see UserManual, Chpt. 2.13.7, page 219). For each of these three cost values, one of the following costtypes 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 tracksDependent on the selected cost type, the allocation of the costs to the individual service tripsis then carried out according to the formulas described below.


Cost rate per km [CU/km] 0.00 0.00 0.00 0.00 0.00 0.00

Vehicle combination ServiceKm EmptyKm ServiceTime EmptyTime

Train 380 km 0 km 10.13 h 0 h

Table 222: Distances and times for the vehicle combination Train in the analysis period

Vehicle combinations Standard bus Low floor bus Train

Table 221: Cost rates for the vehicle combinations

10CUkm--------= 380km⋅ 10CU

km--------+ 0km⋅ 3800CU=

750CUh

--------= 10 13h,⋅ 500CUh

--------+ 0h⋅ 7600CU=

20000 CUVeh----------= 1Veh⋅ 20000CU=

588 © PTV AG


Calculation example: Link costs for service trips in the analysis period• Example for depreciation costs

Cost type depreciation costs

CostValue: for example investment costs for a link (link attributes CostRate1-3 PuTSys)

Cost type running costs

CostValue: for example annual maintenance costs for a link (link attributes CostRate1-3 PuTSys)

Cost type utilization costs

CostValue: for example fees for using a link (link attributes CostRate1-3 PuTSys)CostsLinkService trip, 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 service trips or allocated only to service trips which end or start at this stop point (see User Manual, Chpt. 7.3.2.5, page 1081).

CostsLinkAP, L, T Link costs of the link in the analysis period (AP)

CostsLinkService trip, L, T Costs for a service trip which uses the link

ΣVL, T Number of service trips of transport system T which use link L.

FacTS The transport supply projection factor from AP to AH (see User Manual, Chpt. 2.41.3, page 553)

DT Depreciation time in years

p Interest rate [%]

Table 223: Formulas for calculating link costs

Cost rate 2 PuTSys(Train) 100000 CU

Interest rate p 7 %

Depreciation time DT 10 years

Projection factor transport supply (FacTS) 365

Number of service trips of the transport system train

19

Table 224: Example calculation for link depreciation costs

KostenStrAP S V, ,KostenWertS V, qAD q 1–⋅ ⋅

qAD 1–----------------------------------------------------------------------

⎝ ⎠⎜ ⎟⎛ ⎞ 1

FakVA------------------ ⋅= mit q 1 p

100---------+=

( )10011

1

1,,, pqwith

FacTSDTq

qDTqTLCostValueTLAPCostLink +=•

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

−

−••=

∑= TLTLAPTLVehJourn VehJournCostLinkCostLink ,,,,,

∑ •=

FacTSTLVehJournTLCostValue

TLVehJournCostLink,

,,,

589 © PTV AG


• Example for running costs

• Example for utilization costs (in the example, stored in attribute Link Cost 1)

7.6.6.3 Stop point costsStop point costs are infrastructure costs which accumulate when using a stop point. The stoppoint costs are defined for each stop point. The costs are evently distributed between theservice trips which allow boarding and alighting on this stop point. To model the costs, up tothree cost values (attributes Cost rate1 to Cost rate3) may be entered for each stop point (seeUser Manual, Chpt. 2.25.2, page 357). For each of these three cost values, one of the followingcost 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 tracksDependent on the selected cost type, the allocation of the costs to the individual service tripsis then carried out according to the formulas described below.

Link Cost 2 of link 4CostsLinkAP, L, T

Link Cost 2 of service trip 58 39,008 / 19 = 2,053

Cost rate 3 PuTSys(Bus) 100 CU

Links traversed by service trip 96 1 -> 2 -> 3 -> 5 -> 6 -> 7

Link lengths 5 km per link

Length reference of cost rate 3 Link length

Time reference of cost rate 3 Analysis horizon


Link Cost 2 for share of links 1, 2, 3 and 5 4 • (20 CU / (19 • 365)) = 0.01154 CU

Link Cost 2 for share of links 6 and 7 2 • (20 CU / (38 • 365)) = 0.00288 CU

Link Cost 2 for service trip 96 0.01154 + 0.00288 = 0.01442 CU

Table 225: Example calculation for running costs of links

Cost rate 1 PuTSys(Train) 100 CU

Length of link 4 10 km

Length reference of cost rate 1 km

Link Cost 1 for service trip (in this example, it is constant for all trips of the train)

100 CU/km • 10km = 1000 CU

Table 226: Example calculation for link utilization costs

Table 224: Example calculation for link depreciation costs

100000 1.0710 0.07 11.0710 1–------------------------- 1

365---------⋅ ⋅ ⋅ ⋅ 39.008=

590 © PTV AG


7.6.6.4 Operator costsUp to three cost values (attributes Cost rate1 to 3) can be entered for each operator. For eachof these three cost values, one of the following cost types can be selected.• Depreciation costs, for example investment costs (debt service for depot and offices)• Running costs, for example maintenance costs (maintenance for the depot and

administrative/sales costs).To distribute operator costs to the service trips, which are operated by this operator, adistribution key can be specified which consists of the following weighted indicators• Service kilometers (GewServKm)• Seat kilometers (WeightSeatKm)• Service time (WeightServiceTime)• Number of service trips (GewServFahrt)


CostValue: for example investment costs for a stop point (Stop point attributes CostRate1 to 3)


CostValue: for example annual maintenance costs for a stop point (Stop point attributes CostRate1 to 3)

Cost type utilization costs

CostValue: for example fees for using a stop point (Stop point attributes CostRate1 to 3)CostSPService trip, 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 service trips or allocated only to service trips which end or start at this stop point.

CostsSPAP, HP Stop point costs of the stop point SP in the analysis period (AP).

CostsSPV, HP Costs for a service trip which uses the stop point SP.

ΛService tripSP Number of service trips which use stop point SP.

FacTS The transport supply projection factor from AP to AH (see User Manual, Chpt. 2.41, page 550)


p Interest rate [%]

Table 227: Formulas for the calculation of stop point costs

KostenHPAP HP,KostenWertHP qAD q 1–( )⋅ ⋅

qAD 1–-------------------------------------------------------------------------- 1

FakVA------------------⋅=

( )10011

1

1,,, pqwith

FacTSDTq

qDTqTSPCostValueTSPAPCostStopP +=•

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

−

−••=

∑= TSPVehJournTSPAPCostStopPTSPVehJournCostStopP ,,,,,

∑ •=

FacTSTSPVehJournTSPCostValue

TSPVehJournCostSP,

,,,

591 © PTV AG


• Passenger trips unlinked (WeightPTripsUnlinked)• Passenger kilometers (WeightPassKm).With the values of any combination of these six attributes, you can thus distribute the operatorcosts onto service trips. The weighting factors must amount to 100 % (see User Manual, Chpt.7.3.2.5, page 1081).

Distribution of operator costs O on a service trip

The share of one service trip in operator (O) costs:


CostValueB: for example investment costs for a depot


CostValueB: = for example annual maintenance costs for the depot

ShareV The share of one service trip in operator (O) costs

FO Number of all service trips of operator O

CostValueO Cost value which is specified as operator attribute

CostOpAP, B Operator costs of operator O in analysis period (AP)

CostOpServiceTrip Operator costs for one service trip by operator O.

Table 228: Formulas for calculating operator costs

SeatKmWL

iiSeatKm

VehJournSeatKmSerKmWL

iiSerKm

VehJournSerKmVehJournShare −⋅

=

+−⋅

=

=

∑∑11

VehJournWV

ServiceTWL

iiServiceT

VehJournServiceT−⋅+−⋅

=

+

∑

1

1

psWeightPTriPTrips

PTripsKmWeightPass

PassKm

PassKmneysNumVehJour

ii

VehJourneyneysNumVehJour

ii

VehJourney ⋅+⋅+

∑∑== 11

( ) 10011

1

1, pqwith

FacTSDTq

qDTqOCostValueOAPCostOp +=•⎟

⎟

⎠

⎞

⎜⎜

⎝

⎛

−

−••=

OVehJournShareOAPCostOpOVehJournCostOp ,,, •=

FacTSOVehJournShareOCostValue

OVehJournCostOp ,,

•=

592 © PTV AG


Calculation example: Depreciation costs

Calculation example: Running costs

FacTS The transport supply projection factor from AP to AH


p Interest rate [%]

Cost rate 1: Investment costs for depot 7500000 CU

Depreciation time DT 10 years

Interest rate 7%


Operator Cost 1 for "Urban operator" = 2925.57 CU

Weight service kilometers 25 %

Service kilometers of trip 96 27.5 km

Service kilometers total for operator "Urban operator"

1330km

Weight seat kilometers 25 %

Seat kilometers of trip 96 962.5 km

Seat kilometers total for operator "Urban operator"

46550 km

Weight passenger kilometers 50 %

Passenger kilometers of trip 96 2495.0 km

Passenger kilometers total for operator "Urban operator"

109000 km

Share of service trip 96 in operating costs

Operator Cost 1 for service trip 96 2925.57 CU • 0.022 = 63.73 CU

Table 229: Calculation example for depreciation costs of the operator

Cost rate 2: Maintenance cost for depot 80000 CU

Time reference of the cost rate Analysis horizon


Operator Cost 2 for "Urban operator"

Weight service kilometers 25 %

Service kilometers of trip 96 27.5 km

Table 230: Calculation example for the running costs of the operator

Table 228: Formulas for calculating operator costs

7500000 1.0710 0.07⋅ ⋅

1.0710 1–------------------------------------------------------- 1

365---------⋅

27.51330------------ 0.25 962.5

46550--------------- 0.25 2495

109000------------------ 0.5 = 0.022⋅+⋅+⋅

80000365

---------------- 219.18=

593 © PTV AG


7.6.7 Calculation of the fare revenues (revenue calculation)With VISUM revenues can be calculated and then distributed to the network objects. There arethree 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 bythe passenger. The revenue distribution can also be modified by specific parametersettings (fixed amount per path leg, weighting per kilometer, weighting by number of pathlegs).

• Specification of a revenue for each fare pointThe revenue results from the following calculation: revenue/fare point and the number offare points. The revenue distribution can also be modified by specific parameter settings(fixed amount per path leg, weighting per kilometer, weighting by number of path legs).

• Calculation of the revenues using the fare model For each passenger trip, the fare is calculated from the current ticket type. This revenue isthen distributed over the lines used by the passenger. The revenue distribution can also bemodified by specific parameter settings (fixed amount per path leg, weighting per kilometer,weighting by number of path legs and transport system-specific distribution ofsupplements).

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 in the following. For eachpossibility, an example calculation is carried out using the application example data.Independent of the selected type of revenue calculation, the following output attributes(revenue indicators) are available.

Service kilometers total for operator "Urban operator"

1330 km

Weight seat kilometers 25 %

Seat kilometers of trip 96 962.5 km

Seat kilometers total for operator "Urban operator"

46550 km

Weight passenger kilometers 50 %

Passenger kilometers of trip 96 2495.0 km

Passenger kilometers total for operator "Urban operator"

109000 km

Share of service trip 96 in operating costs

Operator Cost 2 for service trip 96

Table 230: Calculation example for the running costs of the operator

27.51330------------- 0 25,⋅ 962.5

46550---------------- 0 25,⋅ 2495.0

109000-------------------- 0.50⋅+ + 0.022=

80000 0.022⋅365

------------------------------------- 4.5 CU=

594 © PTV AG


7.6.7.1 Revenue calculation from fixed revenue per passenger tripTo estimate the revenues from ticket fares, a revenue amount per passenger trip can bespecified. In the following example, a fixed revenue of 4.00 CU per passenger trip is specifiedand the revenue per line calculated. The distribution regards only the number of path legs (see"Revenue distribution" on page 598). The following route table (PuT path legs) provides anoverview of all other indicators required, including the passenger trips.


Total revenue Total revenue from fare revenues which apply to the network object.

Total revenue (length proportional)

Total revenue from fare revenues which apply to the territory and the selected level. Distribution is proportional to the link lengths of the traversed links.

Total revenue (fare point-proportional)

Total revenue from fare gains which apply to the territory and the selected level. Distribution is proportional to the number of traversed fare points on links and time profiles.

Revenue PTripUnlinked

Revenue per passenger trip = Revenue total / PTripsUnlinked

Cost coverage % Expresses the cost coverage in percentCost coverage % = Revenue total (length proportional) / Costs • 100

CostCov total Expresses the cost coverage in absolute numbersCost coverage total = Revenue total (length proportional) - Costs

Cost coverageper PTripUnlinked

Cost coverage per passenger trip = Cost coverage total / passenger trips

Table 231: Revenue indicators

From zone To zone Line FromSPoint

ToSPoint

Passenger trips

Fixed revenue per passenger trip [CU]

Revenue share (Weighted with number of path legs)

A Village (100)

X City (200) BUS1 10 20 1501 4.00

Train 20 40 4.00

A Village (100)

X City (200) BUS1 10 40 499 4.00 499 • 4.00

A Village (100)

C Village (201)

BUS1 10 20 200 4.00 200 • 4.00

X City (200) A Village (100)

BUS1 40 10 1000 4.00 1000 • 4.00

X City (200) A Village (100)

Train 40 20 1000 4.00

Table 232: Revenue share per path leg

1501 4⋅2

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

1501 4⋅2

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

1000 4⋅2

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

595 © PTV AG


Revenues per line then result from summation of the revenue shares for each line.

7.6.7.2 Revenue calculation from fixed revenue per traversed fare point

If fare points have been defined on links or in time profiles of the model, revenue calculationcan regard a fixed revenue per traversed fare point (see User Manual, Chpt. 7.5, page 1086).In the following example, a revenue of 0.20 CU per fare point is specified. The route table (PuTpath legs) provides an overview of the calculation.

BUS1 20 10 4.00

X City (200) C Village (201)

Train 40 20 5000 4.00 5000 • 4.00

X City (200) B Village (202)

BUS1 40 30 2000 4.00 2000 • 4.00

C Village (201)

A Village (100)

BUS1 20 10 200 4.00 200 • 4.00

C Village (201)

X City (200) Train 20 40 5000 4.00 5000 • 4.00

B Village (202)

X City (200) BUS1 30 40 2000 4.00 2000 • 4.00

Line Revenue per line

Bus1 3002 + 1996 + 800 + 4000 + 2000 + 8000 + 800 + 8000 = 28598

Train 3002 + 2000 + 20000 + 20000 = 43996

Table 233: Revenue per line

FromZone

ToZone

Line FromSPoint

ToSPoint

NumFP

PTrips Fixed revenue per FP [CU]

Revenue share (Weighted with number of path legs)

100 200 BUS1 10 20 10 1501 0.20

Train 20 40 20 0.20

100 200 BUS1 10 40 29 499 0.20

100 201 BUS1 10 20 10 200 0.20

200 100 BUS1 40 10 30 1000 0.20

200 100 Train 40 20 20 1000 0.20



1000 4⋅2

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

1501 10 20 ) 0.2⋅+( )⋅2

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

1501 10 20 ) 0.2⋅+( )⋅2

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

499 29 0.2⋅ ⋅

200 10 0.2⋅ ⋅

1000 30 0.2⋅ ⋅

1000 20 10+( ) 0.2⋅ ⋅2

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

596 © PTV AG


Revenues per line then result from summation of the revenue shares for each PuT path leg.

Fare points can be created for links and also for time profiles. In the calculation of the revenueshare for each path leg, the sum of fare points at both of those network objects goes in.

Illustration 192: Calculation of the fare points for path legs

7.6.7.3 Revenue calculation using the fare modelThe most exact variant of the revenue calculation is the one which builds up on the VISUM faremodel. To do so, fare systems and ticket types have to be defined and connected with thenetwork lines (see "PuT fare model" on page 546). A fare model provides a specific fare foreach PuT path.

BUS1 20 10 10 0.20

200 201 Train 40 20 20 5000 0.20

200 202 BUS1 40 30 10 2000 0.20

201 100 BUS1 20 10 10 200 0.20

201 200 Train 20 40 20 5000 0.20

202 200 BUS1 30 40 10 2000 0.20

Line Revenue per line

Bus1 4503 + 2894 + 400 + 6000 + 3000 + 4000 + 400 + 4000 = 25197

Train 4503 + 3000 + 20000 + 20000 = 47503

Table 235: Revenue per line


1000 20 10+( ) 0.2⋅ ⋅2

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

5000 20 0.2⋅ ⋅

2000 10 0.2⋅ ⋅

200 10 0.2⋅ ⋅

5000 20 0.2⋅ ⋅

2000 10 0.2⋅ ⋅

H1 H2 H3 H4 H5

2 5 6 3

10 10 10

TW1 TW2 TW3

Path legs

TP at l inks (NumTPs-TSys)

TP at time profiles (NumTPs)

Stop points

TP at path legs (NumTPs) 12 21 13

597 © PTV AG


The revenue is first calculated on PuT path level. The passenger trips (volume) of the path arethus multiplied with the fare. The revenue is then distributed to the PuT path legs (see"Revenue distribution" on page 598). With a zone-based fare, the following revenues result forthe paths in the example Example_LLE.ver .

7.6.7.4 Revenue distributionInternally VISUM first calculates the revenues for PuT paths. The revenues are then distributedto the PuT path leg and then converted to the network object line hierarchy (lines, line routes,etc.). You can influence the distribution of the revenues by the following parameters.• With Weighting Number Path Legs you can achieve an even distribution of the revenue

over all path legs. Each path leg receives the same revenue share, if the weight is 100%.• With Weighting Number Fare Points, the distribution takes the ratio between the number

of fare points of the path leg and the number of fare points of the entire path intoconsideration. This can be used so that the longer path legs (in terms of fare points) thusreceive a larger share of the revenue.

• You can select any weighting between both distribution possibilities, number of path legsand number of fare points.

• When specifying Fixed amount per path leg, each path leg first receives a fixed sum ofthe total revenue. The remaining revenue is then distributed to the path legs according tothe distribution rules mentioned above. If the sum of all of the fixed amounts exceeds therevenue to be distributed, the fixed amounts are correspondingly reduced. If a fare modelis used, the supplements are not taken into consideration.

From

zon

e

To z

one

Pat

h le

gs

Pas

seng

er

trips

Num

ber o

f fa

re z

ones

One

-way

tic

ket b

ase

fare

[CU

]

Sup

plem

ent

for T

rain

[CU

]

Fare

= B

ase

fare

+

Sup

plem

ent

[CU

]

Rev

enue

=

Vol

ume

• Far

e [C

U]

A Village X City Bus1 Train

1000 5 3.00 3.00 6.00 6000.00

A Village X City Bus1 1000 6 3.00 0.00 3.00 3000.00

A Village C Village Bus1 200 3 2.00 0.00 1.00 200.00

X City A Village Bus1 1000 6 3.00 0.00 3.00 3000.00

X City A Village Bus1 Train

1000 5 3.00 3.00 6.00 6000.00

X City C Village Train 5000 4 1.00 3.00 4.00 20000.00

X City B Village Bus1 2000 3 1.00 0.00 1.00 2000.00

C Village A Village Bus1 200 3 1.00 0.00 1.00 200.00

C Village X City Train 5000 4 1.00 3.00 4.00 20000.00

B Village X City Bus1 2000 3 1.00 0.00 1.00 2000.00

Total 62400.00

Table 236: Calculation of the revenues per path (PuT routes)

598 © PTV AG


For revenue distribution the following formulas are appliedShare-FarePt = NumFarePt-PL / NumFarePt-TotalShare-PathLeg = 1 / NumPLRevShare-PathLeg =(Share-FarePt • W- NumFarePt + Share-PathLeg • W-NumPL)Rev-PathLeg = Rev-Fix + (Rev-PassTrip – Rev-Fix • NumPL) • RevShare-PathLeg

The revenue distribution is also demonstrated with the example Example_LLE.ver. A zone-based fare model was modeled there and the calculation of the input data required for revenuedistribution already demonstrated (see "Revenue calculation using the fare model" onpage 597).Revenue distribution is only carried out for those paths which comprise more than one path leg.In the example, this is the path from A Village to X City, where 1,000 passengers use the busand the train, and back. As the number of path leg fare points is 10 for both the bus (A Village– C Village) and the train (C Village – X Town), a distribution factor of 0.5 results in each case.

Note: Revenue distribution does not regard how the revenue was calculated (fare model,fixed revenue per passenger trip or fixed revenue per fare point).

NumPL Number of path legs in a passenger trip

NumFarePt-PL Number of fare points in a path leg

NumFarePt-Total Total number of fare points in the passenger trip

RevShare-PathLeg Share of the path revenue, which applies to the path leg

W-NumFarePt Weighting of fare points (length)W-NumFarePt + W-NumPL=1.0W-NumPL Weighting of path legs

Rev-PassTrip Revenue per passenger trip

Rev-Fix Revenue which is distributed to each path leg as a fixed amount

Rev-PathLeg Revenue which is distributed to the path leg

From origin zone 100 (A Village)

To destination zone 200 (X City)

Links in the course of Path 1 1 (Bus) -> 2 (Bus) -> 4 (Train)

Number of fare points on traversed links

Link 1: 5 (Bus)Link 2: 5 (Bus)Link 4: 10 (Train)

Share-FarePt(Bus1)

Number of path legs of Path 1 2

Share-PathLeg(Bus1)

Revenue on Path 1 6000 CU

Weighting of fare points (length) 75 %

Weighting of path legs 25 %

Table 237: Revenue calculation for the path leg Bus1

5TP 5TP+20TP

------------------------------ 0.5=

12---

599 © PTV AG


If you want to return the revenues on the line level, the following calculation thus applies.

Another calculation example illustrates the calibration options (especially the definition of afixed amount for each path leg). Let the following network be the example network.

Illustration 193: Example network for fixed amount per path leg

Revenue Path Leg(Bus1)

Line FromZone ToZone PTrips Fare Revenue = PTrips • Fare

BUS1 A Village X City 1000 3.00 3000.00

A Village X City 1000 6.00

A Village C Village 200 1.00 200.00

B Village X City 2000 1.00 2000.00

C Village A Village 200 1.00 200.0

X City A Village 1000 3.00 3000.00

X City A Village 1000 6.00

X City B Village 2000 1.00 2000.00

Total = 16400.00

TRAIN X City C Village 5000 4.00 20000.00

X City A Village 1000 6.00

C Village X City 5000 4.00 2000.00

A Village X City 1000 6.00

Total = 46000.00

Table 238: Aggregation of the path leg revenues to lines

Passenger trips 3

Total number of fare points 12

Share-FarePt(Bus1)


Table 237: Revenue calculation for the path leg Bus1

5TP 5TP+20TP

------------------------------ 0.75⋅ 12--- 0.25⋅+⎝ ⎠

⎛ ⎞ 6000 CU( )⋅ 3000 CU( )=

6000 12---⋅ 3000=

6000 12---⋅ 3000=

6000 12---⋅ 3000=

6000 12---⋅ 3000=

S1S1 S4S4S3S3S2S26 FP2 FP 4 FP

Train Bus 2Bus 1

212------ 0.167=

600 © PTV AG


When using a fare model (see "Revenue calculation using the fare model" on page 597), thedistribution of supplements can also be influenced. With the option Distribute supplementsto transport systems you have the following possibilities:• If the option is selected, the supplement charged for the transport system is only distributed

to the path legs which are traversed by this transport system. This is how the supplementis only distributed to the path legs, where the long-distance train is used, for example for aconnection where a local train without supplement and a long-distance train withsupplement are used.

• If the option has not been selected, the supplement is distributed to all path legs accordingto the distribution key, independent of whether the transport system, for which thesupplement was defined, is used for this path leg. This is how a regional train also benefitsfrom the supplement for a long-distance train, for revenue distribution, for example.

Share-FarePt(Train)

Share-FarePt(Bus2)

Number of path legs 3

Share-PL

Rev-PassTrip 3.00

Path leg Share per path leg Revenue per path leg

Bus 1 1.0 • 0.167 + 0.0 • 0.333 = 0.167 0.167 • 3.00 = 0.50

Train 1.0 • 0.500 + 0.0 • 0.333 = 0.500 0.500 • 3.00 = 1.50

Bus 2 1.0 • 0.333 + 0.0 • 0.333 = 0.333 0.333 • 3.00 = 1.00

Table 240: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0


Bus 1 0.5 • 0.167 + 0.5 • 0.333 = 0.250 0.250 • 3.00 = 0.75

Train 0.5 • 0.500 + 0.5 • 0.333 = 0.417 0.417 • 3.00 = 1.25

Bus 2 0.5 • 0.333 + 0.5 • 0.333 = 0.333 0.333 • 3.00 = 1.00

Table 241: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.00


Bus 1 0.5 • 0.167 + 0.5 • 0.333 = 0.250 0.20 + 0.250 • (3.00 - 3 • 0.20) = 0.80

Train 0.5 • 0.500 + 0.5 • 0.333 = 0.417 0.20 + 0.417 • (3.00 - 3 • 0.20) = 1.20

Bus 2 0.5 • 0.333 + 0.5 • 0.333 = 0.333 0.20 + 0.333 • (3.00 - 3 • 0.20) = 1.00

Table 242: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.20


612------ 0.5=

412------ 0.333=

13--- 0.333=

601 © PTV AG


An example illustrates the differences between both methods. There is only one fixedsupplement in the example. To make it easier, there is no distance-based supplement. Thebase fare of the connection is 30.00 CU.

• (*) The fixed supplement of the top-ranking TSys (ICE) is only charged once, in this case7.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 fixedsupplement of 3.00 CU, the EC would obtain the complete supplement of 7.00 CU, whentaking the rank into consideration and distributing by transport system.

7.6.7.5 Calculation of cost coverageFor cost coverage calculation, total revenues have to be compared with total costs. Thefollowing output attributes are available.

For the application example, cost coverage data on line level is calculated as follows for Bus1for example.

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 2.33

IC (#2) 100.00 10,00 7.00 (**) 3.50 2.33

RE (#3) 100.00 10,00 0.00 0.00 2.33

Total 30.00 (*) 7.00 7.00 7.00


CostCov total Expresses the cost coverage in absolute numbers.CostCov total = Revenue total (length proportional) - Costs

CostCov Percent [%] Expresses the cost coverage in percent.

Cost coverage per passenger trip

Expresses the cost coverage per passenger trip.

This attribute is only available for the elements of the line hierarchy and for PuT operators and transport systems.

Table 243: Indicators for the cost coverage calculation

Total revenue 16400.00 CU

Costs 36321.86 CU

CostCov total 16400.00 CU - 36321.86 CU = -19921.86 CU

Table 244: Cost coverage calculation from revenues and costs

CostCov [%] Revenue tot (lenght prop)Cost

-------------------------------------------------------------------- 100⋅=

CostCov PTripUnlinked CostCovTotPTripsUnlinked----------------------------------------=

602 © PTV AG


7.6.8 Basic calculation principles for indicatorsHere, the following indicator calculation principles are introduced.• Projection onto the analysis horizon (AH)• Aggregation along the line hierarchy (Aggregation of indicators on trip section level to

indicators of a higher level)• Temporal cut (Calculation of indicators for analysis time intervals)• Spatial cut (by territory)• Impact caused by couplings• Projection of additional attributes

7.6.8.1 Projection onto the analysis horizonUsing projection factors, the analysis period values of indicators can be extrapolated to anyuser-defined analysis horizon. If your analysis period is one day and a service trip runs everyday throughout the year, you can for example use a projection factor of 365 to calculate therevenue for the entire year. If the service trip only runs on weekdays, you can select aprojection factor of 260. Depending on the indicator to be calculated, the projection factor hasto either be set for the valid day or for the demand segment (Table 245).i

The application example makes the difference between the projection factors on valid daysand those by the demand segment clear. For trip 135, passenger kilometers and servicekilometers are compared to each other.

CostCov Percent [%]

Passenger trips unlinked 8400

Cost coverage per passenger trip = -2.37 CU

Table 244: Cost coverage calculation from revenues and costs

36321.8616400.00------------------------- 100⋅ 45.15 %=

-19921.868400

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

Indicator category Projection factor Transport supply / Valid day

Projection factor Hourly costs / Valid day

Projection factor by DSeg

General indicators X

Transport supply X

Network performance X

Costs (apart from Cost Time) X

Cost Time X

Revenues X

Table 245: Which projection factor applies for the calculation of indicators?

Valid Day weekdays (Monday to Friday)

Table 246: Difference in the projection to AH for ServiceKm and PassengerKm

603 © PTV AG


7.6.8.2 Example for temporal dependencies of indicatorsFor the projection to the analysis horizon, the indicators of the transport demand (networkperformance, 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 thefact into account that the transport demand, for example at the weekend, can decline moreseverely 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 dayseparately. In this way, for an analysis period of one week in August, not only can the indicatorsof regularly occurring Valid Days be correctly projected to an analysis horizon of one year (forexample, 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 assignmenttime 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 periodregards 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 theassignment time interval.

• If the demand time series of the demand segment refers to only a part of the assignmenttime interval, then the projection factor corresponds to the ratio between the demand in theanalysis period and that of the demand time series time period.

The following example shows how this kind of calculation can be used to save computationtime in case of homogeneous demand.

ExampleThe analysis period and the assignment time interval should each cover one week (Monday toSunday). 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 timeseries may be applied on weekdays, whereas on the weekend there is no demand in thissegment. The demand of this demand segment is coded in the OD matrix of one day incombination with the time series for 24h, beginning Monday at 0:00. Due to the time series,only the trips which start on Monday are charged during assignment. In order nevertheless to

Projection factor Transport supply / Valid day 260

Service kilometers (AP) 7.5 km

Service kilometers (AH) 260 • 7.5 km = 1950 km

Projection factor Demand segment PuT 365

Passenger kilometers (AP) 397.5 km

Passenger kilometers (AH) 365 • 397.5 km = 145087.5 km

Table 246: Difference in the projection to AH for ServiceKm and PassengerKm

604 © PTV AG


indicate correct weekly values as PuT volumes per analysis period, the following projectionfactors are applied to the "commuters" demand segment.

The following example of a vehicle journey with two sections (illustration 194) shows thecalculation of selected operating indicators for the following analysis time slices.• the analysis period of one week• the analysis horizon of one year• an analysis time interval on Tuesday 7 – 8 a.m.As shown in illustration 194 and Table 247, vehicle journey section 1 is served daily, whereasvehicle journey section 2 is available only on Sundays and public holidays.

Illustration 194: Time-distance diagram for a vehicle journey with two vehicle journey sections

Projection from ... to ... Factor

Assignment time interval AP 5

Assignment time interval AH (= year) 5 • 52 = 260

VehJourney VehJournSect 1 VehJournSect 2

Valid Day Daily Sunday+Holiday

Projection factor Analysis Horizon 52 63

Departure 6:30

Arrival 7:30

Trip length 30 km 30 km 20 km

Trip length 6:30 - 7:00 10 km 10 km 0 km



SeatCap 200 100

Table 247: Further specifications for the vehicle journey with two VJ sections

t

s

0 km7:00 8:00

10 km

20 km

30 km

6:00

1

2

605 © PTV AG


Table 248 shows the calculation of the seat kilometers. This is done by multiplying the seatingcapacity by the service trip length and then simply adding up the vehicle journey section data.

Compared to seat kilometers, the calculation of service kilometers (often termed loadkilometers or train kilometers) by simply adding up the vehicle journey sections is notpermitted. In this case, it must be realized that superimposed vehicle journey sections mayonly be counted once. This is particularly important for the calculation of any track costsderived from the service kilometers. Track costs are calculated on the basis of servicekilometers 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 amaximum formation is taking place. In the example shown in Table 249, this is the case onSunday. The calculation of the service time is carried out in the same way.

Analysis period Mon-Sun

VehJournSect 1 200 seats • 20 km • 7 days = 28000 km

VehJournSect 2 100 seats • 20 km • 1 day = 2000 km

Total 30000 km

Analysis horizon

VehJournSect 1 28000 km • 52 = 1456000 km

VehJournSect 2 2000 km • 63 = 126000 km

Total 1582000 km

Analysis time interval Tue 7:00 – 8:00

VehJournSect 1 200 seats • 10 km = 2000 km

VehJournSect 2 100 seats • 0 km = 0 km

Total 2000 km

Table 248: Calculation of seat kilometers

Analysis period Mon-Sun

Analysis horizon Analysis time period Tue 7:00-8:00

Monday 20 km • 1 20 km • 52 10 km • 0

Tuesday 20 km • 1 20 km • 52 10 km • 1

Wednesday 20 km • 1 20 km • 52 10 km • 0

Thursday 20 km • 1 20 km • 52 10 km • 0

Friday 20 km • 1 20 km • 52 10 km • 0

Saturday 20 km • 1 20 km • 52 10 km • 0

Sunday 10 km • 1+ 10 km • 1+ 10 km • 1

10 km • 52+ 10 km • MAX(52;63)

+ 10 km • 63

20 km • 0

Total 150 km 8,020 km 10 km

Table 249: Calculation of service kilometers

606 © PTV AG


7.6.8.3 Aggregation along the line hierarchyInternally VISUM adds – based on the value calculated from the service trip section – allindicators along the line hierarchy (Internally here means, that not all indicators can bedisplayed on service trip section level. The reason being saving the values in the memoryrequirements). This also applies if indicators are evaluated by territory or time slice.

Illustration 195: Aggregation along the line hierarchy

For operators, aggregation is also carried out via the vehicle journey sections (because as anoption, each vehicle journey section can be assigned an operator). For the aggregation ontransport system level, the line values are added per transport system (because a transportsystem has to be assigned to each line).For the service kilometers of the transport system Train in the application example, thecalculation is as follows.

Illustration 196: Aggregation of the service kilometers from the trips onto the line

7.6.8.4 Temporal cut (Time cut)The temporal cut is applied, if you want to calculate indicators for a certain analysis timeinterval (see User Manual, Chpt. 4.2.2, page 824) or during the calculation of the indicators forthe analysis period. In the last case, the complete days of the analysis period are treated



LineMain lineAggregation

607 © PTV AG


internally the same as a time interval, which last from 12 pm to 12 am. The temporal cut iscarried out on the time profile.For the time cut, the departing line route items are decisive. Indicators are always firstcalculated on the trip section level and then aggregated along the line hierarchy (see"Aggregation along the line hierarchy" on page 607). If a time interval lasts for example from8 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 lineroute item is still included in the calculation.The division of link-related indicators is thus based on the acuteness of individual links. In thecase of trips exceeding a time interval limit for example, a time interval is assigned to thevalues 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 runtimes of the time profile first and then compared with the limits of the time intervals(see"Interpolation of passage times (run times in minutes)" on page 608) . A calculation examplecan also be found in a different place (see "Measurement of the transport supply" onpage 576).

Illustration 197: Interpolation of passage times (run times in minutes)

7.6.8.5 Spatial cut (Territory cut)In principle, the calculation of the territory-specific portion is based on cutting the link.• Length-related and time-related indicators, which are calculated per link (for example

service kilometers), are summed up for the territory where the link is located in.• If a link traverses several territories, the indicators of territories is proportionally added

to the respective length shares, for length-related indicators.• If a link traverses several territories, the indicators of territories is proportionally added

to the respective time shares, for time-related indicators.• For indicators which are not calculated per link, such as the number of stop events in a

territory, this territory is summed up where the polygon lies.

B

Links with run times

Line route

Time profile

3 6 1 4

4 2 10

Line route with interpolated run times

2 2 2 2 8

B

B

A

A

A

A

C

C

C

C

E

E

E

E

D

D

D

X

X

X

Stop point exactly between B and C

4 * 3 / (3 + 6*0.5)

608 © PTV AG


7.6.8.6 Partially traversed linksPartially traversed links are a special case. These are links with a stop point on the link, wherea trip ends or starts at this link stop point. For the calculation of some indicators, the link has tobe traversed by at least 50 %, to be included in the calculation. Which rule applies for whichindicator and network object, can be taken from the file IndicatorAvailability.xls. An example forthis are the service kilometers on the link. In the upper section of the illustration 198, the link isonly traversed by 20 %. The service kilometers on the link are then 0 km. In the lower sectionof the illustration, the link is traversed by 80 %. The service kilometers on the link are then8 km.

Illustration 198: Partially traversed links

7.6.8.7 Impact caused by couplingsFor some indicators, coupled service trips are counted proportionally. This means, that twoservice trips which are coupled, in the coupled section share the value of the indicator. TheExcel file IndicatorAvailability.xls provides an overview of the indicators to which this applies. Ifindicators regard the coupled service trips only for certain network objects, this is additionallynoted in a comment.The following example illustrates the influence of couplings. Couplings are taken intoconsideration for service kilometers, for section service kilometers however, couplings are nottaken into consideration.

H1 H3H2

Trip

20% 80%

Link 1: 10km

ServiceKm Link 1: 0km

H1 H3H2

Trip

20%80%

ServiceKm Link 1: 8km

609 © PTV AG


Illustration 199: Influence of couplings on the indicator calculation

7.6.8.8 Projection of additional attributes In addition to the pre-defined PuT operating indicators also user-defined indicators can beextrapolated 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 iscalculated according to the following algorithm.• Result attributes are created

For the network objects Service trip, Time profile, Line route, Line, Main line, TSys andTerritoryPuTDetail it is checked if there is a numeric, editable attribute featuring the sameID as the original attribute. If not, a user-defined attribute featuring that ID is generatedautomatically. Code and name, too, are adopted from the original attribute. For the networkobjects Vehicle journey section, Service trip, Time profile, Line route, Line, Main line, TSysand TerritoryPuTDetail it is checked if there is a numeric, editable attribute featuring thesame ID as the original attribute but suffixed by "AH". If not, a user-defined attributefeaturing that ID is generated automatically. Code and name is each suffixed by "AH“, too.If the result attributes already exist, they will be set to zero.

• Calculation at vehicle journey section levelIt is assumed that the original attribute contains a value related to AP. At the vehicle journeysection the AH result attribute value is determined as follows.ValueAH = ValueAP • ProjFactorTransportSupplyHere, the projection factor specified for the Valid Day of the journey section is used for thetransport supply.

• Calculation in the line hierarchyThe values of the original attribute are added up along the line hierarchy and allocated tothe respective result attribute there. The values of the AH result attribute of the vehiclejourney section are equally added up and allocated to the AH result attribute at each level .

Note: If the result attributes already exist, but are either not numeric or not editable, an errormessage 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 beexecuted.

Trip 1

19km 2km

Trip 2

Coupling

(in associated time profile of the trips)

ServiceKm Trip 1: (19km / 2) + 2km = 11.5kmSection-ServiceKm Trip 1: 19km + 2km = 21km

ServiceKm Trip 2: (19km / 2) = 9.5km + 2km = 11.5kmSection-ServiceKm Trip 2: 19km

610 © PTV AG


• Territory cut• If the original attribute is a length-related attribute, the value of the vehicle journey

section is first distributed onto the traversed links in proportion to the line length. Thenthe link values are intersected with territories as usual. Thus, the value of a link is addedto the share (link length in territory / link length) in the AP result attribute per object(s) ofthe line hierarchy x territory.

• If the original attribute is a time-related attribute, the value of the vehicle journey sectionis first distributed onto the traversed links in proportion to the run times of the timeprofile. 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 eachtraversed territory.

• The values calculated per vehicle journey section are each multiplied by the projectionfactor AH for the transport supply (see above) and then added up equally in the AH resultattribute per object(s) of the line hierarchy x territory.

In the example Example_LLE.ver the network object vehicle journey section has the user-defined attribute Revenue_per_PassKm. This reflects the ratio between revenue andpassenger kilometers. Projection to line data is carried out according to the following schema.

Illustration 200: Extended projection of attributes

Note: If the Init PuT Operating Indicators procedure is executed, the user-defined attributesof the TerritoryPuTDetail network object, for example, Territory x TSys x Vehiclecombination, 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, theyhave to be deleted manually.



LineMain line

Trips 58 to 95 (38 trips): 0,38 GE/km each

Train 1 >; TP1: 19 * 0,38 GE/km = 7,22 GE/km Train 1 <; TP1: 19 * 0,38 GE/km = 7,22 GE/km

Train 1 >: 1 * 7,22 GE/km = 7,22 GE/kmTrain 1 <: 1 * 7,22 GE/km = 7,22 GE/km

Train: = 2 * 8,05 GE/km = 16,1 GE/km

Main lines do not exist

Trips 58 to 95, each exactly 1 VJI: 0,38 GE/km each

611 © PTV AG


612 © PTV AG

8 Environmental impact model and HBEFA

The VISUM add-on module Environment is used to calculate the environmental impact - noiseand pollutant emissions - caused by motorized traffic. Three procedures for calculatingenvironmental impact are available:• Noise-Emis-Rls90 (see "Noise volume" on page 613)

Calculation of noise emission levels in accordance with RLS-90 (see User Manual, Chpt.8.4, page 1104).

• Noise-Emis-Nordic (see "Noise volume" on page 613). Calculation of noise emission levels in accordance with Nordic Council of Ministers (1996)(see User Manual, Chpt. 8.4, page 1104).

• Pollution-Emis (see "Air pollution emissions" on page 616). Calculation of air pollution emissions in accordance with emission factors of the SwissFederal Office for the Environment (BAFU) (see User Manual, Chpt. 8.7, page 1107).

The HBEFA add-on allows you to calculate emission values by link, by territory and network-wide in VISUM VISUM. The calculation is based on the Handbook Emission Factors for RoadTransport version 3.1 (see "Emission calculation according to HBEFA 3.1" on page 618).

Subjects• Noise volume• Air pollution emissions• Emission calculation according to HBEFA 3.1

8.1 Noise volumeTo calculate noise volumes based on traffic volumes, VISUM offers the Noise-Emis-Rls90 andNoise-Emis-Nordic procedures. The Noise-Emis-Rls90 procedure is based on the RLS-90 ofthe noise reduction for roads by the German Federal Minister for Traffic, the Noise-Emis-Nordic procedure on the Nordic Council of Ministers (1996) model.The model is fairly simple but sufficient to identify relative variations, that is, how, where, andto what extent traffic-routing and road construction measures affect traffic volumes and, as aconsequence, the noise situation of particular roads.

8.1.1 Noise-Emis-Rls90 procedureThe procedure determines the average emission level of long and straight roads in accordancewith RLS-90.For the calculation of Lm,E in decibels, VISUM considers the followingoperations:• Calculation of the average level Lm(25) using equation (7), RLS-90.

•• M = relevant hourly traffic volume (car/h)• p = relevant HGV proportion in percent of total traffic (above 2.8 t total permissible weight)

( ) ( )[ ]p082,01Mlg105,3725Lm ⋅+⋅+=

613 © PTV AG

Chapter 8: Environmental impact model and HBEFA

• Determination of correction factor DStrO for different road surfaces in accordance with table4, RLS-90. VISUM keeps the correction factors listed in this table as an ASCII fileRLS.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 to80 km/h.

• Determination of correction factor DStg for inclinations and gradients using equation (9),RLS-90.

• The final result for every active link is the emission level Lm,E which is calculated throughan addition using equation (6), RLS-90.

8.1.2 The Noise-Emis-Nordic procedureThis procedure is an enhancement of the Noise-Emis-Rls90 procedure for the Nordic Standardin accordance with the Nordic Council of Ministers (1996). Its calculation is similar to the oneused in the Noise-Emis-Rls90 procedure.

8.1.3 Link attributes for noise calculationsThe two noise calculation procedures require (Table 250) different input attributes. Tounderstand these input attributes please refer to the explanations and illustrations in the RLS-90. The output value Noise is returned as a result.

Note: The correction factor DE which takes absorption characteristics of reflecting areasinto account is not calculated.

StgDStrODvDmLE,mL +++=


HGV share(Input)

HGV-share p (above 2.8 t total permissible weight) of total trafficDefault: 0Value 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: 0Value range: -50 to 50

Surface typeSurface type(EWS)(Input)

For different road surface types, correction penalties are generated and added in accordance with RLS 90, table 4. The respective data are stored in the parameters file RLS.DAT (see "Parameters file RLS.DAT" on page 615).Standard value: 1Value range: 1 to 9

Noise(Output)

Mean emission level Lm,E of long and straight roads in [dB].

Table 250: Link attributes for noise calculations

614 © PTV AG

Chapter 8.1: Noise volume

Parameters file RLS.DAT* Surface typespermissible maximum speed*30 km/h40 km/h50 km/h>= 60km/h* non-porous*cast-asphalt, asphalt concrete*Type 1 0000** porous cast-asphalt* Concrete*Type 2 1.01.52.02.0** Paving with* level surface*Type 3 2.02.53.03.0**other paving**Type 4 3.04.56.06.0**ZTV Concrete 93*with steel brush stroke*Type 5 0001.0**ZTV Concrete 93*without steel brush stroke*Type 6 000-2.0**Asphalt concrete 0/11*Mastix asphalt*Type 7 000-2.0**open porous asphalt*Grain 0/11*Type 8 000-4.0**open porous asphalt*Grain 0/8*Type 9 000-5.0

The values apply to the correction penalties per surface type.illustration 201 shows an example where noise calculation is illustrated as link bars accordingto Noise-Emis-Rls90. In the User Manual you will find further information on implementation(see User Manual, Chpt. 8.5, page 1105).

615 © PTV AG


Illustration 201: Illustration of noise volume as link bars

8.2 Air pollution emissionsIn VISUM, road traffic air emissions can be determined on the basis of the calculationprocedure Pollution-Emis (based on emission factors of the Swiss Federal Office for theEnvironment).The calculation of the pollution emission values is carried out internally by the program on thebasis of direction; volume values for both directions are later added. The result is displayed asa cross-section volume.The emissions are calculated for every car and every truck (HGV), with every value multipliedby the number of vehicles (link volume for HGVs or cars). These partial sums are then totaled.

8.2.1 Pollution-Emis procedureThis procedure is based on emission factors issued by the Swiss Federal Office for theEnvironment (BAFU) for pollutants NOx, CO, HC and SO2, for both cars and HGVs. For eachpollutant, a regression curve with polynomes to the 5th degree is used.Emiss:= a + b * v + c * v2 + d * v3 + e * v4 + f * v5The parameters a,b,c,d,e and f of the polynome were determined separately for differentpollutants for cars and HGVs for the reference years 1990, 1992, and 2000 and are containedin the parameter text files EMI1990.DAT, EMI1992.DAT and EMI2000.DAT. For the referenceyear 1990, for example, the following values are used.* Input file for flexible emission formulas for Switzerland 1990* They are polynome to the 5th degree.** a + bx + cx2 + dx3 + ex4 + fx5(the numbers are exponential)

Note: To illustrate the noise volume in traffic networks, we recommend a classificationaccording to the DIN standard 18005 Part 2 09.91.

616 © PTV AG

Chapter 8.2: Air pollution emissions

*(x is the speed of cars or HGVs)**a+bx+cx2+dx3+ex4+fx5*NOx CAR 0.758602.8004e-2-9.9187e-41.4276e-5-5.6655e-80.0*NOx HGV 24.216-0.701941.5878e-2-1.5996e-47.1751e-70.0*CO CAR 16.425-0.383572.8706e-3-4.5425e-60.00.0*CO HGV 45.380-3.07299.7880e-2-1.6116e-31.3138e-5-4.1410e-8*HC CAR 2.2155-6.6593e-28.7930e-4-5.1330e-61.1381e-80.0*HC HGV 46.490-3.78590.133822.3153e-31.9258e-5-6.1410e-8*SO2 CAR 101.80-3.03094.4557e-2-2.8928e-47.7300e-70.0*SO2 HGV 1980.4-87.5642.9120-5.0701e-24.3285e-4-1.3577e-6

Recent measurements have shown that actual emission values are generally overestimated by1990 calculation factors, because the change in vehicle fleets (more vehicles have now beenequipped with catalytic converters) has contributed to decreasing volumes per vehicle. Thelatest Swiss emission factors take this change into account with modifications for the years1992 and 2000.The polynome approximation of emissions relative to speed shows the following developmentsfor CO for the different reference years in illustration 202:

Illustration 202: Emissions relative to speed

8.2.2 Pollutant-Emis link attributesFor the emission calculation procedure Pollutant-Emis, the HGV share is required as input linkattribute. The link attributes (air pollution) in Table 251 are output as output values.

Car 1990

Car 1992

Car 2000

HGV (same values for all years)

0,0

2,0

4,0

6,0

8,0

10,0

12,0

14,0

16,0

18,0

20,0

0,0

2,0

4,0

6,0

8,0

10,0

12,0

14,0

16,0

18,0

20,0

0 10 20 30 40 50 60 70 80 90 100 1100 10 20 30 40 50 60 70 80 90 100 110Speed km/h

CO emission volume in g/km

617 © PTV AG


illustration 203 shows an example where the nitrogen monoxide volumes are displayed as linkbars according to Pollution-Emis. In the User Manual you will find further information onimplementation (see User Manual, Chpt. 8.8, page 1108).

Illustration 203: Display of nitrogen monoxide volumes as link bars

8.3 Emission calculation according to HBEFA 3.1This chapter describes the fundamental principle and the basics of the emission calculationaccording to HBEFA (see User Manual, Chpt. 8.10, page 1110).

8.3.1 Fundamental principleThe HBEFA-based emission calculation procedure allows you to calculate emission values


HGV share(Input)

Relevant HGV share in percent of total traffic (above 2.8 t total permissible weight)

EDat_NOx(Output)

Nitric oxides in g/km

EDat_SO2(Output)

Sulphur dioxide in g/km

EDat_CO(Output)

Carbon monoxide in kg/km

EDat_HC(Output)

Hydrocarbons in g/km

Table 251: Pollutant-Emis link attributes

Note: For the display of pollution emissions, we recommend the use of classified values.

618 © PTV AG

Chapter 8.3: Emission calculation according to HBEFA 3.1

by link, by territory or network-wide in VISUM . The calculation is based on the HandbookEmission 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. thespecific emission in g/km for all current vehicle categories (PC, LDV, HDV and motorcycles),each divided into different categories, for a wide variety of traffic situations."

8.3.2 Basics of the HBEFA calculation in VISUMIn VISUM the emission calculation according to HBEFA determines the desired emissions andoptionally cold start excess emissions. The traffic situation, volumes and fleet compositions aretaken 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 fleetcompositions suggested by HBEFA per country, calendar year and category (e.g. Car or HGV)can be used as a basis here.Then, the emissions are calculated with the HBEFA-based emission calculation procedure,which can be calculated for either one or several demand segments at the same time. The procedure can be calculated in two different ways:• statically (for analysis period and analysis horizon)• dynamically (additionally per analysis time interval)

Per demand segment, the volumes for warm emissions and cold start excess emissions stemfrom a selectable attribute. This attribute is interpreted as volume with time reference analysisperiod (AP). When calculating with AP-based volumes, the value is divided by the APprojection factor and multiplied by the AH projection factor.When calculating the fuel quality, as an indicator for the plausibility of the calculations, thenetwork-wide fuel consumption (quantity/[g]) collected by demand segment is converted intothe specific consumption ([l/100km]) separately by diesel and gasoline. First, the quantity isdivided by the density of the fuel (gasoline ca. 0,75kg/l, diesel ca. 0,83kg/l) and then related tothe mileage of the demand segment. The specific consumption by demand segment isdisplayed in the Statistics > Emissions (HBEFA) list and saved to the trace file.

8.3.2.1 Basis for calculating warm emissionsThe 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 typeand the link attribute Is Urban:

Note: The complete HBEFA Handbook is available on the website www.hbefa.net.

Note: You can calculate the dynamic variant, if volumes are available for individual analysistime intervals.

619 © PTV AG


• Gradient class: The gradient class results from the attribute Gradient based on the following classification:

• Level of Service (LOS): Depending on the parameter setting, the LOS is determined either directly from the contentof the selected attribute or based on a classification by the specified attribute regarding thethree specified class limits.

• Static traffic situation (i. e. without the LOS share): The urban/rural classification results directly from the link attribute Is Urban, the HBEFA linkclass directly from the link type. The speed class is determined on the basis of the set linkattribute (default: v0), while only certain values are possible according to the traffic situationscheme in HBEFA (depending on urban/rural and link class):

HBEFA link class Is Urban Fleet composition class to be applied

HBEFA_Motorway-National or HBEFA_Motorway-City or HBEFA_Semi-Motorway

--- Highway

Other No RuralOther Yes Urban

Note: If you use uniform fleet compositions for each demand segment, the fleetcomposition for Urban is always applied.

Value range Gradient class< -5 % -6 %-5 % to below -3% -4 %-3 % to below -1% -2 %-1 % to below 1% 0 %1 % to below 3% 2%3 % to below 5% 4%5% and more 6%

Note: If you calculate by time interval and the set subattribute type is AHPI with values fortime intervals, the LOS will be calculated per analysis time interval as well.

620 © PTV AG


If there is a traffic situation whose speed does not vary by more than 5km/h, which matchesthe characteristic urban/rural and the link class, it will be allocated. In the case of two suchtraffic situations (e.g. 55km/h), the one with the higher speed will be allocated. If no trafficsituation fulfills this condition, the nearest traffic situation with the same link class will beused.If no traffic situation matches the specified combination of urban/rural and HBEFA linkclass, 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, thelevel of service and the gradient class will be multiplied for each pollutant to be calculated bythe value of the volume attribute (AP) specified for the demand segment and by the length ofthe link. The result is the warm emission for this pollutant, this link and this demand segmentbased on the analysis period. Multiplied by the respective projection factor, the amount issaved in the respective link attribute (AP and AH) and added to the network-wide emission (APand AH).If the calculation is additionally carried out per analysis time interval, the emission factor isdetermined once per interval due to the interval-dependent LOS and multiplied by the volumevalue for this interval and the length of the link. The result is then saved in the subattributeassociated with the analysis time interval and added to the network-wide time-dependentemission.

Calculated pollutantsThe following pollutants can be calculated in VISUM. The pollutants are divided into threegroups:Group 1: Established measurement programs

Element DescriptionCO carbon monoxideFuel fuel consumptionGasoline fuel consumptionDiesel fuel consumptionPM particle mattersHC hydrocarbons

621 © PTV AG


Group 2: Complementary measurement programs and literature

Group 3: Indicative literature references

8.3.2.2 Basis for calculating cold start excess emissionsTo determine the cold start excess emissions, firstly, the cold start emissions weighted over theshares 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 switchedvia attribute Calculate start excess based on routes at the origin zone:• Polygonal calculation• Calculation on routes

Polygonal, geometrical calculationThe idea of the geometrical calculation is that the start of a route is diffuse. In the model, itbegins 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 startexcess emission originates, too. And this is used to avoid the calculation on routes as follows.

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

Element DescriptionPb leadBenzene benzeneCH4 methane

SO2 sulfur dioxide

NO2 nitrogen dioxide

NMHC non-methane hydrocarbon

Element DescriptionNH3 ammoniac

N2O nitrous oxide

Note: The emission factors of the pollutants SO2, Pb and CO2 reported are country specificbecause they depend on the composition of the fuel. So far, only values for Germany can becalculated in VISUM.

Note: In HBEFA, cold start excess emissions are not indicated for all subsegments. Forsegments without an available excess, a cold start excess emission of 0 g/start will beapplied.

Element Description

622 © PTV AG


For each origin zone, firstly, the absolute cold start excess emission is calculated as total overthe demand segments over the products from the value of the attraction attribute of thedemand segment multiplied by the share of cold start and the emission factor of the respectivepollutant for the fleet composition to be applied. This absolute emission per pollutant isdistributed length proportionally to all links that are not closed for the PrT which lie within aradius of 1km around the convex hull of the connector node of the zone. Cold start excessemissions which arise from different zones are accumulated.

Calculation on routesIn order to determine the cold start excess emissions on routes, all routes of the demandsegments to be calculated are evaluated from the origin to the destination. For each traversedlink, a cold start excess share AP,S is calculated as the integral of the decay function over thelink length. This share is multiplied with the volume of the route and the share of cold start ofthe origin zone of the route. Any attribute, whose content does not have to correspond to thetotal of the volumes of all routes, can be used as volume value when calculating the warmemissions. In order to calculate meaningful cold start excess emissions anyhow, the value isdivided by the volume of the demand segment afterwards and multiplied by the value of thevolume attribute. That implies that the relation between the route volume and the link volumemultiplied 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 issummed up over all routes. The evaluation of the routes can end as soon as the first fourkilometers 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 withthe cold start excess emission factor of the fleet composition allocated for urban and projectedover AP and AH. As in the case of the polygonal method, the calculated absolute emission of the zone is thendistributed proportionally to this indicator per link onto the links. Please note that this does notyield the exact dynamic route volumes but an acceptable approximation. In order to use thedynamic route volumes in the procedure, the traffic flow model of the used dynamicassignment would have to be reproduced. The volume per analysis time interval calculatedfrom these dynamic route volumes during the assignment is used instead.Like the other emissions, the cold start excess emissions are aggregated network-wide andissued in the statistics list Emissions (HBEFA).

Note: If no routes are available for a demand segment and the calculation on routes isdemanded at a zone, no cold start excess emissions will be calculated for this zone. Besidesthe explicit rejection of the routes, this is for example the case if you want to determineemissions of service buses using a separate, artificial demand segment whose volumesresult from, for example, the number of service trips. Here, the omission of the cold startexcess emissions is in line with the fact that almost all of the trips are warm. The procedurecan, however, still be run.

623 © PTV AG


624 © PTV AG

9 Economic assessment according to EWS

The EWS-97 (Empfehlungen für Wirtschaftlichkeitsuntersuchungen an Straßen, 1997 –English: Recommendations on economic efficiency analyses of roads) have been compiled bythe working committee on economic efficiency analyses of Forschungsgesellschaft fürStraßen- und Verkehrswesen (German Road and Traffic Research Association), being theupdate of RAS-W-86 (Richtlinien für die Anlage von Straßen, Teil:Wirtschaftlichkeitsuntersuchungen, 1986 – English: Road design guidelines – Part: Economicefficiency analyses).These recommendations are the basis for the economic assessment of investments in roadconstruction according to uniform standards. The results of economic efficiency analysessupport decision-making on whether a measure or which of several possible measures is to betaken. Furthermore, decisions have to be made as objectively and as comprehensibly aspossible.

Subjects• EWS – basics• EWS link attributes• EWS – Costs• EWS – Cost-benefit analysis

9.1 EWS – basicsEconomic efficiency analyses according to EWS-97 are based on the comparison of costs andbenefits which incur if a road construction measure is taken (planned case) or which can besaved if the measure is not be taken (comparison case).

UtilityThe EWS-97 assesses the impacts of the realization of road construction measuresconsidering the modification of the following benefit components (difference of the non-investment costs).• Operating cost• Travel times• Accidental events• Noise volume• Pollutant volume• CO2 volume• Barrier effect vs. pedestrian crossing• Availability of space for pedestrians and cyclistsIf the impacts of a measure are compared, the benefits may be positive (economic gains) ornegative (economic losses). The benefits are assessed separately by direction.

625 © PTV AG

Chapter 9: Economic assessment according to EWS

CostsThe costs are broken down in two components.• Investment costs (costs for the construction or modernization of roads and of

compensational work).• Running costs (road maintenance costs)

• Constructional maintenance (instant and small-scale measures)• Operational maintenance (cleaning, control and maintenance work as well as winter

gritting and snow-clearing services to ensure operational reliability)

Evaluation period and annuities

Illustration 204: Evaluation period and annuities

The evaluation period is 20 years. Time of evaluation is the 1st January of the year afterinauguration (in EWS module: reference year; (see "EWS – Costs" on page 630)).As a start the investment costs (EWS module: costs in the year of the due date; (see "EWS –Costs" on page 630)) incurring at different times or periods are accumulated or discounted tothe reference time or year (in EWS module: reference year; (see "EWS – Costs" onpage 630)). Based on the various amortization time intervals constant annual amounts to beinvested (annuities) are calculated. This is done using annuity factors by means of which thereference year costs are distributed over the evaluation period taking into account theinterests.The benefits are determined for a representative year of the evaluation period (availability ofdemand data) and therefore determined approximately constantly over the evaluation period(benefit annuities). The overall benefit or the overall costs of the measures over the evaluationperiod 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. Costsand benefits are specified at price index 01/01/1995, hereby costs without VAT.

Cost-benefit ratioDecision criterion for the economic efficiency of road construction measures is the quotient ofbenefit and costs. In case of road construction investments the cost-benefit ratio (CBR)

20 years

E v a l u a t i o n p e r i o d

Time of evaluation

Investment costs in the year of the due date

Cost annuities

Accumulation Discounting

Benefit for a

representative year

Benefit annuities Benefit annuities

626 © PTV AG

Chapter 9.1: EWS – basics

specifies how many DM of benefit can be expected per DM of costs spent. If all kinds ofbenefits 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 mainlydetermined as annual CBR (see "Evaluation period and annuities" on page 626). To make thedetermination of the cost-benefit ratio more transparent, the individual partial benefits of thetotal cost-benefit ratio are apportioned.

Network delimitationAll coherent network segments for which the traffic volumes of comparison case and plannedcase 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 areaof the measure to be assessed.

Application areas and use constraintsEWS-97 are suitable for the assessment of the economic efficiency of road constructionmeasures within the framework of a comparison of variants (comparison of alternative designsof one project, for example different alignments) or priority rankings (comparison of variousprojects, for example different extensions of a road network).However, it has to be noted that they are not necessarily suitable if major impacts on publictransport 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 derStandardisierten Bewertung, Engl.: Standardized evaluation method) have to be determinedindividually in cooperation with the parties involved.

Deviations from the EWS-97 guidelines for the implementation in the VISUM EWS add-on moduleThe VISUM EWS add-on module has integrated the EWS edition 1997 into the VISUMenvironment as accurately as possible. Minor corrections of the EWS guidelines have beendiscussed 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 constructionmeasure. If this is not enough, investments featuring the same amortization periods can beaggregated. EWS table 14 provides details on the breakdown of building activities.

• Running cost (EWS-97, pp. 29, 5.2)• It is not possible to enter surcharges on the road type-dependent base values of

running costs (see EWS-97, table 15, p. 31) for extra expenditures (street lighting,traffic signals, tunnels, winter services, cycle lanes). These costs can be input as

627 © PTV AG


additional maintenance costs for the whole study network (see "EWS – Costs" onpage 630).

• The footnote concerning other extra-urban roads (EWS-97, table 15, p. 31), saying thatvalues are only applicable to the higher-order road network (others 30% less) has notbeen 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 directlyentered 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 middlelane of road type 2.10 in table 41, p. 49, is not taken into account.

9.2 EWS link attributesEWS-specific link attributesTable 252 shows the EWS link attributes.

Notes: Working with VISUM users should pay attention to all differences between EWSprogram module and EWS guidelines. In case of open questions please do not hesitateto contact the PTV hotline.The application of the EWS add-on module requires the detailed knowledge of EWS-97.Gained results should be verified through plausibility checks.


DistanceBuilDistance to building properties (EWS)(Input)

Distance of kerb to building properties [m]Default: 0Range: 0.00 to 1,000000.00

Build. type Type of building properties (EWS)(Input)

Type of building properties 0 = none 1 = open 2 = closedDefault: 0

BuildHght Height of buildings (EWS)(Input)

Minimum average height of house fronts [m] (cf. EWS-97, equation 70)Default: 0Range: 0.00 to 1000.00

ResidentsResidents (EWS)(Input)

Number of residents concernedDefault: 0Range: 0 to 100000

Table 252: EWS-specific link attributes

628 © PTV AG

Chapter 9.2: EWS link attributes

Further link attributesThe following link attributes are also used with the VISUM Environment add-on module.• Gradient [%]

Longitudinal gradient of the lane (positive: uphill; negative: downhill).• Surface type

Road surface type (according to EWS-97, table 21, p. 39; see also RLS.DAT, section 8).• Share of HGV [%]

Share of HGV in total average daily traffic (see also default values of HGV sharesaccording to RLS-90 in EWS-97, table 20).

• Noise immission heightDifference in height hm between noise emission and immission point in [m] (cf. EWS-97,equation 66).

EWScategoryEWS category(Input)

EWS road categories (according to EWS-97, table 20, p.39);0 = motorways1 = federal roads 2 = connecting roads (state, district, community)3 = local roadsDefault: 3

EWStype EWS type(Input)

EWS link type (according to EWS-97, table 6, p.16)Default: 111

Sidewalk widthSidewalk width (EWS)(Input)

Sidewalk width for actual state [m]Default: 0Range: 0.00 to 99.99

CurvityCurvature (EWS)(Input)

Curvity as the total of all angles per kilometer [gon/km]Default: 0Range: 0 to 10000

Cycle lane widthCycle lane width (EWS)(Input)

Cycle track width for actual state [m]Default: 0Range: 0.00 to 99.99

Sidewalk width futureFuture sidewalk width (EWS)(Input)

Sidewalk width for future state [m]Default: 0Range: 0.00 to 99.99

Cycle lane width futureFuture cycle lane width (EWS)(Input)

Cycle lane width for future state [m]Default: 0Range: 0.00 to 99.99

Note: In VISUM immission height is not calculated according to EWS-97, equation (67),but directly input by the user.


Table 252: EWS-specific link attributes

629 © PTV AG


Furthermore, the following basic link attributes are required for calculations according to EWS.• Link length• permissible speed of vehicle groups (transport systems)The volumes required for EWS can either be input as counted data or calculated byassignment. On the one hand, it allows to use “actual” results gained from traffic counts and onthe other hand, the simulation of various variants based on the assignment methods integratedin VISUM. The speeds relevant for the evaluation are calculated according to EWS-97, tables11-13.

9.3 EWS – CostsBesides the EWS link attributes and the EWS parameters the costs equally have to be input forthe calculations according to ESW-97.• Investment costs• Additional annual maintenance costsThe 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, thetime of inauguration as well as the usual interest rate for investment projects of 3 % will beconverted to annual investment costs (annuities).VISUM determines the annual running costs taking the base values for comparison case andplanned case of the study network listed in EWS-97, table 15. , for comparison case andplanned case of the study network. Additional annual maintenance costs – surcharges for extraexpenditures (for example street lighting, winter service) and other costs according to EWS-97,table 15 (for example bridge and tunnel engineering) – will also be added, if applicable.

9.4 EWS – Cost-benefit analysis(see User Manual, Chpt. 9.8, page 1131) automatically performs further calculationscomparing the results of comparison case and planned case either by comparison case andplanned case calculations carried through consecutively or by importing planned case andcomparison case files already containing VISUM EWS calculations.Then all EWS calculations are output as annual values in a result table illustration 205.

Notes: Specification of the volume origin (assignment or AddValues) for EWS calculation inEWS 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 dailytraffic ADT (cf. EWS-97, chapter 4.3.1). If demand matrices are not available as ADT, theyhave to be adjusted accordingly. The conversion factor is specified in the EWS Parameterswindow.

630 © PTV AG

Chapter 9.4: EWS – Cost-benefit analysis

Illustration 205: Depiction of the results in EWS window

The following calculation results – all costs in million DM/year – are output.• Running costs determined from the base values of EWS-97, table 15 including additional

annual maintenance costs (see "EWS – Costs" on page 630) of comparison case andplanned case and their cost difference.

• Investment costs (annuities; (see "EWS – Costs" on page 630)) of comparison case andplanned case and their cost difference.

• Total costs, the sum of investment costs and running costs of comparison case andplanned case and their cost difference.

• Non-investment costs of comparison case and planned case, each in total and related tothe individual benefit components (operating cost, accidental events etc.) and theirdifference (utility).

• Share%: relative benefit of the individual benefit components related to the overall benefit,for example according to table illustration 205:

• CBR, overall cost-benefit ratio and relative cost-benefit ratio of the individual benefitcomponents, for example according to table in illustration 205.

The cost-benefit ratio allows a ranking of the different planning variants: constructionworthiness if CBRTotal ≥ 1.

56.636.1494.02

2% ===TotalCBRCOCBR

COShare

36.14/.553.0/.945.7

===aDMMioaDMMio

TotalCostDiffTotalUtility

TotalCBR

94.0/.553.0/.521.022 ===

aDMMioaDMMio

TotalCostDiffCOUtility

COCBR

631 © PTV AG


632 © PTV AG

10 GIS functions

VISUM allows you to include data from geographic information systems (GIS) into your model.Both ESRI shape files (file extension *.shp) and the Personal Geo Database (PGD) aresupported. VISUM also offers typical GIS functions such as the different objects or differentcoordinate systems for georeferencing your network. Furthermore, functions for networkdigitalization (GPS tracking) and visualization (legends, backgrounds, texts, polygons) areoffered, which make network data preparation for presentations easier.Other GIS typical functions have already been discussed at some other point:• Integrating symbolic illustrations (see "Points of Interest (POI)" on page 59)• Showing and hiding layers (see User Manual, Chpt. , page 15)• Freely definable coloring for network objects (see User Manual, Chpt. 12.2, page 1253)

Subjects• Connection to the Personal Geo Database and GIS objects• Shape files as a GIS interface• Intersect• Coordinate systems• Processing the network display with graphic objects• GPS tracking

10.1 Connection to the Personal Geo Database and GIS objectsVISUM can temporarily connect itself with an ESRI Personal Geo Database (PGD) or a shapefile. This function can be useful for example, when a traffic modeler working with VISUM,connects to a Personal Geo Database on the computer of a land use planner. The trafficmodeler can then take the required data from the Personal Geo Database of the land useplanner by means of intersection (see "Intersect" on page 638) and then cut the connection.This process bypasses the need to import the file back to VISUM.

During the connection to the PGD, so-called GIS objects are created in VISUM. GIS objectsare POI-like network objects (see "Points of Interest (POI)" on page 59), which are onlyavailable during a PGD connection. Analogous to POIs, GIS objects are organized into GIScategories. 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 followingobjects in the VISUM network.• Schools, swimming pools, stops• Stretches of water, agricultural areas, planning districts

Note: To be able to use this function, you need a license for the program ArcGIS version 8.3or higher.

633 © PTV AG

Chapter 10: GIS functions

To create GIS objects in VISUM, you have to either select the PGD Feature Classes or FeatureDatasets for display or editing. The following objects are thus created in VISUM:• For each selected Feature Class of the Personal Geo Database, a GIS category is created.• For each Feature a GIS objectNone of the coordinates transferred to VISUM are being converted. The GIS objects arealways removed again as soon as the connection to the PGD has ended. If you want topermanently 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 exampleThe following applies during the Personal Geo Database connection:• Only key information on the objects is stored permanently.• Information on attributes of the category is available through an attribute interface.• Read and write access to the attributes is transferred directly to the database.

10.2 Shape files as a GIS interfaceShape files are a data format for geodata, which are used in most GISs. The data format isespecially suitable for the data exchange between VISUM and GIS. With VISUM you can readand save shape files.

A shape file is not an individual file, but is made up of three files:• File *.shp for saving geometry data• File *.shx contains the geometry index to link to the attribute data• File *.dbf contains attribute data in dBase data format. You can assign the attributes

contained here a VISUM attribute, when reading the shape file (see User Manual, Chpt.13.10.2, page 1445).

Shape files can contain points, lines or polygons (surfaces). Only one type of element can becontained in a shape file.

10.2.1 Importing shape filesWhen importing shape files, the information contained in shape files is read in a VISUMnetwork. Which network it is imported to depends on the type of shape file (point, line orpolygon) and by which processing mode (additive or non-additive). An overview on whichshape file types are imported to which network objects is provided by Table 253.

Note: To save shape files you need the add-on module Shapefile converter.

Note: A technical description of the data format can be found on the Internet at www.esri.com/library/whitepapers/pdfs/shapefile.pdf.

Link, Screenline, Connector

Zone, Main zone, Territory, Main node

Node, Detector, Count location, Stop, Stop point

POI

Point X X X

Table 253: Reading shape files in VISUM network objects

634 © PTV AG

Chapter 10.2: Shape files as a GIS interface

If you want to read existing node data as a stop points into the shape file, you have to first readit as a node and then with the function aggregate node, create (see User Manual, Chpt.2.11.14, page 193) stop points.While reading polylines as links, you can create alternative directed links or links with bothdirections. 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 directionsWhile 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 theselected network object). illustration 206 shows an example, where shape file data are readas a link. The shape file contains the attributes STREET_NAM, LENGTH and LANE, whichallocate the VISUM link attributes Name, Length and Number of lanes.

Illustration 206: Source and target attribute allocations

Polyline X X

Polygon X X

Note: Creating POIs is only possible with additive reading of shape files, because a POIcategory has to be specified, where the POIs can be included. At least one POI category hasto therefore be contained in the network, to read shape files as POIs.Connectors, stop points, and count locations can only be read in additively.

Table 253: Reading shape files in VISUM network objects

635 © PTV AG


Example applications• Reading shape files with a road network as links in VISUM. In VISUM a routing-enabled link

network is then available.

• Reading cross-communities as territories• Reading schools as POIs• Reading land use as POIsIn addition to the import of shape files as VISUM network objects, you can also insert shapefiles 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 canthus insert multiple shape file layers into the network (for example a layer for industrial areas).The drawing order of the layers and its color can be changed. illustration 207 shows anexample, where two shape files were integrated as a background with land use for residentialand commercial areas.

Illustration 207: Land use from two shape files as background

Note: The links have to first be enabled for transport systems.

636 © PTV AG

Chapter 10.2: Shape files as a GIS interface

10.2.2 Exporting shape files

Exporting shape files can be useful for example, if you want to use calculation results such aslink volumes from a VISUM assignment in a GIS. Shape files can also be used to exchangedata 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 fromVISUM respectively. For each selected network object, a file with the extension *.shp, *.shx,and *.dbf is saved. Additionally, VISUM creates a *.ctf file for each exported shape file. VISUMrenames attribute identifiers, which are longer than 10 characters, because shape files do notsupport 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 noprojection). 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 remainconstant.The Table 254 shows in which shape types the VISUM network objects are illustrated.

When exporting shape files, the following special cases have to be noted.

Note: Exporting shape files is only possible with the add-on module Shapefile converter.

Point Polyline Polygon

Nodes X

Main nodes X

Main node centroids X

Stop points X

Stops X

Links X

Zones X

Zone centroids X

Main zones X

Main zone centroids X

Territories X

Territory centroids X

Line routes X

Screenlines X

Connectors X

Count locations X

Detectors X

POIs X X X

Table 254: Illustration of VISUM files of shape types

637 © PTV AG


• LinksIf links are saved undirected, only one object is created for both directions. The attributesof 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 eachdirection.

• ConnectorsYou can select whether the first point of the object should be the zone (standard setting) orthe 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.

• POIsPOIs can be point, polygon or polyline and are thus exported to three different files.

10.3 IntersectOne of the most important GIS functions is the intersect. This means the overlapping of twosubject levels of the same area section with the aim of gaining new information. To create ademand model in VISUM, GIS structure data (such as the number of employees or the numberof pupils) can for example be read in a surface POI and these intersected with zones. Theresult being the type of structure data for each zone (number of employees or pupils per zone)in a VISUM attribute.Intersections between network objects are possible in VISUM, so that no export in a GIS isnecessary for intersection operations. This can be used to link two network objects whichoverlap each other (intersection) and saves the thus resulting information in a VISUM attribute.The intersection area of two objects results from the spatial overlapping of both objects.illustration 208 shows examples of overlapping network objects.

638 © PTV AG

Chapter 10.3: Intersect

Illustration 208: Examples of overlapping network objects

Use casesA typical use case for an intersection is the data import from a GIS.• There are land use data in GIS• Land use data are imported to VISUM using a shape file, which is read in a POI.

(Alternatively VISUM can be connected to a Personal Geo Database. Land use data inVISUM are then available as GIS objects.)

• The zone and an editable attribute are later selected as target object, to adapt the createdinformation.

• Through the intersection of zones and POIs the result is the land use data per zone and canfor example be used in a VISUM demand model (for example the number of homes perzone).

Intersection is not just confined to data exchange with GIS. Multiple application possibilitiesalso arise within VISUM. Some examples, which information can be obtained with anintersection operation are introduced in the following.

639 © PTV AG


• Number of PuT passengers per zone (Table 255)• Number of inhabitants in the catchment area of line routes (Table 256)• Number of inhabitants in the catchment area of stops (Table 257)• Vehicle kilometers within territories (Table 258)• Zone number where the stop lies (Table 259)• Average number of PuT passengers at the stops of a zone (Table 260)

Intersecting zones and stop points: The passengers in a zone are calculated from the ZoneAddValue1 = Sum of passengers at all stops in the zone polygon.

Table 255: Calculating the number of PuT passengers per zone

Intersecting line routes and zones: The inhabitants of a line route are calculated from LineRoute.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the line route.

Table 256: Calculating the number of inhabitants in the catchment area of lines

640 © PTV AG


Table 258: Calculating the vehicle kilometers within territories

Intersecting stops and zones: The inhabitants of a catchment area of stops are calculated from Stop.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the stop.

Table 257: Calculating the number of inhabitants in the catchment area of stops

Intersecting territories and links: The vehicle kilometers in a territory are calculated from Territory.AddValue1 = Sum of VehicleKm PrT via all links in a territory.

641 © PTV AG


Table 259: Calculating the zone number where a stop point lies ()

The target attribute values can either be calculated as a sum, mean value, minimum ormaximum of the source attribute values. If for example you do not want to calculate the totalnumber of PuT passengers per zone (Table 255), but the average number of PuT passengersat the stops of a zone, proceed as described in Table 260.

BufferTo carry out intersections, at least one involved network object type has to be two-dimensional.To obtain this, a buffer can be created around a network object.

Intersecting stop points and zones: In which zone a stop point lies, is calculated from StopPointAddValue1 = smallest zone number of the zone where the stop point lies (Please note that the minimum is selected here, because theoretically, a stop point could lie in two zones, if its polygons overlap. One of the other three functions, however, could also be selected).

Intersecting zones and stops: The average number of passengers at stops in a zone is calculated from the ZoneAddValue1 = Average number of departures at all stops within the zone polygon.

Table 260: Calculating the average number of PuT passengers at the stops of a zone

Note: If you want to calculate the number of source objects per target object, select theattribute 1.0 of the source object .

642 © PTV AG


A buffer assigns an area to a point object, line object or a polygon. The resulting area isintersected along with the actual network object. An object point thus becomes a two-dimensional object when calculating the intersection.The buffer is not defined based on the polygon centroid, but on each point of the polygon. Thismeans, 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 thencalculated by which the target buffer overlaps the source buffer(s). Together with the attributevalue 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 adistance ≤ radius to a point of obj to the particular object. Radius = 0 results in the obj itself. Inthe case of buffer polygon objects, polygons plus their buffers are intersected.

IntersectionsThere are three types of intersections:• Surface with surface

The intersection of two polygons is defined as usual.• Surface with point

If a surface is intersected with a point, the attribute value of the point is counted 100%, ifthe point lies within the polygon. Otherwise it is counted with 0%.

• Surface with lineThe intersection of a surface with a line object is the share of the line object within thesurface.

The polygon content Content(P) of a polygon is defined as usual. The following also applies:• For line objects obj Content(obj) = Length(obj) is defined.• For point objects obj Content(obj) is defined as infinitesimal ε > 0. An infinitesimal number

is a number whose absolute value is greater than zero but less than any positive realnumber be it ever so small. Content defines the overlapping share of objects. A sourcepolygon P2 overlaps for example, the target polygon P1 with the following share.

.If a buffer > 0 is assigned to a point or line object, it turns into a polygon.Share is then defined as follows:

21 FF ∩

)2()21()2,1(

PContentPPContentPPShare ∩

=

⎩⎨⎧

∈∉

=pgppgp

pggenPolypPoShare10

),int(

),int()int,( pggenPolypPoSharepPopggenPolyShare =

pg"in l "),( lengthofSharepggenPolylLinkShare =

643 © PTV AG


Intersection then results in:

with P1 = buffer(origobj, targradius), P2 = buffer(origobj, origradius).

The following examples show the effect of the intersect operation in VISUM.

Illustration 209: Intersecting three polygon objects with a link buffer

In illustration 209, surfaces are intersected with surfaces. The intersection of two polygons isdefined as usual.• Prorated intersection of polygon and link buffer (1)• Polygon is located inside of link buffer - intersection of 100% (2)• Polygon is located outside of link buffer - intersection of 0% (3)

Note: The share of a point object equals 1 if it lies within the polygon, 0 if it is positionedoutside of it. A line object has a share x of a buffer if x = length of the section contained in thebuffer / total length.

∑∑

∈

∈

⋅=

llLinks

llLinks

lLength

lLengthpglSharepggenPolylPolylinegenShare

)(

)(),(),(

),( legenPolylinpggenPolyShare

),( pggenPolylegenPolylinShare=

)2()21()2,1(

pgContentpgpgContentpggenPolypggenPolyShare ∩

=

( ))2,1()()arg( PPShareorigobjOAttrAggrobjtTAttrorigobj

⋅=

(1)

(2)

(3)

644 © PTV AG


Illustration 210: Intersecting point objects with a polygon

In illustration 210, for those point objects outside of the polygon, intersection results in 0%, forthe three point objects inside of the polygon, intersection results in 100%. If 1.0 is selected assource attribute, all stops (source object) per zone (target object) are counted here for example(since value of source object = 1.0).

Illustration 211: Intersecting point objects with a buffer polygon

In illustration 211, for those point objects outside of the buffer polygon (= polygon + buffer),intersection results in 0%. The intersection share within the buffer polygon is 100% for all pointobjects. Six points are thus intersected with 100%.

Illustration 212: Intersecting point object buffers with polygons

1

2

34

645 © PTV AG


If point objects are intersected with polygons, the intersection share of a buffer results perpolygon from the position of the buffer in the respective polygon. In the illustration 212, twopoint object buffers with 100% share are intersected and one point object buffer prorated (itsremaining 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, pointobjects within the overlapping area will be counted twice, because the polygon buffers overlapeach other and the point object lies within two polygons with buffers. The resulting number ofpoint objects regarded for intersection is then greater than the actual number of point objects.

10.4 Coordinate systemsWhen creating networks, components from different GIS sources are often combined, whichpartially refer to different coordinate systems. To make the data consistent a coordinatetransformation is necessary. VISUM supports you with this task with the following functions.• The user can optionally specify that all coordinates in the current network belong to a

predefined coordinate system (see User Manual, Chpt. 10.1.1, page 1137).• The coordinate system can be changed in VISUM. You can automatically transform (see

User Manual, Chpt. 10.1.1, page 1137) the coordinates of the current network.• If data are imported, which apply to another coordinate system than that for the current

network, VISUM automatically transforms the imported coordinates into the system of thecurrent network.

There is an option to switch from the default VISUM to a predefined coordinate system. VISUMoffers a selection of coordinate systems, which are provided as files with the extension *.prj inthe directory ...VISUM115\EXE\PROJECTIONS. This file format is Well-Known-Text-Format inESRI version.

In VISUM, a difference is made between geographic coordinate systems and projectedcoordinate systems.In geographic coordinate systems, the coordinates are displayed as spherical coordinates withgeographic length and width. They are measured as an angle from the earth's center to a pointon the earth's surface (for example 47° 6‘ northern latitude, 12° 27‘ eastern longitude). Incomparison, the coordinates of the earth ellipsoid is projected to a level, for plane coordinatesystems. A location on earth is therefore distinctly determined as an X and Y coordinate on thelevel. The following example in VISUM shows two projection files for a planar and a geometriccoordinate system.

Note: You can optionally specify, whether you want to work with a current projection in yourproject. It is usually sufficient to keep the standard setting ("VISUM"). In this case coordinatesin VISUM do not apply to any current projection, but are illustrated "uninterpreted" in arectangular system. If, however, original files are specified in a certain projection and areimported to a network, where no projection has been selected, the display is distorted. In thiscase select the suitable projection.

646 © PTV AG

Chapter 10.4: Coordinate systems

Example for planar coordinate system (WGS 1984 UTM Zone 48N.prj)

Example for geometric coordinate system (Deutsches Hauptdreiecksnetz.prj):

VISUM manages coordinate systems in the following file types: Depending on the file type,coordinate information is saved or imported differently.

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 261: Planar coordinate system

GEOGCS["GCS_Deutsches_Hauptdreiecksnetz",DATUM["D_Deutsches_Hauptdreiecksnetz",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

Table 262: Geometric coordinate system

Note: Please note, that in the actual file *.prj the projection properties which are written downrow by row, have to be successive (in a row). Detailed information on how to createprojections can be found on the ESRI homepage (for example at www.support.esri.com/index.cfm?fa=knowledgebase.techArticles.articleShow&d=14056).

File type Write Read

*.ver Version file

All attributes of the current coordinate system are saved.

All attributes of the current coordinate system are read in. If the name of the system is not found in the list of predefined systems, it is added to the selection. A *.prj file is not created.

*.net, *.mdb Network fileDatabase

All attributes of the current coordinate system are saved.

If not read-in additionally, the file is read like a version file, in case the network parameter block is missing, the standard setting (VISUM) is applied. If read-in additionally, the network parameters block is read-in in case it exists and is enabled (see User Manual, Chpt. 1.3.3.3, page 41).

*.shp Shape file

In addition to the shape file, a *.prj file with the currently set projection is created if it differs from the standard setting (VISUM).

If a corresponding *.prj file exists for a shape file, it is used as projection and transformed into the currently set projection if applicable. If it does not exist and the existing network has a coordinate system, the user selects a coordinate system (see User Manual, Chpt. 10.4.1, page 1149).

647 © PTV AG


10.5 Processing the network display with graphic objectsVISUM 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 graphicobjects. In contrast to network objects, network-independent graphic objects are not part of thenetwork 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 alegend, using a legend assistant. The following functions are available:• Inserting texts (see "Texts" on page 648)• Automatic creation of a legend (see "Legend" on page 648)• Inserting polygons (see "Polygons" on page 652)• Inserting background graphics (see "Backgrounds" on page 649)

10.5.1 TextsTexts serve to additionally label network displays. There are two text types:• Background texts

Texts which are inserted into the network display• Legend texts

Texts which are inserted into a legend

10.5.2 LegendWith the legend additional information on illustrating and describing the network, can be outputin the VISUM network display. Legends are created with the Legend Wizard which enablesusers to select the network objects to be listed and to set parameters for the display. Thewizard automatically generates a legend that matches those settings. Furthermore, space canbe made in the legend for user-defined complements. Externally prepared graphics can forexample be inserted there (illustration 213).

*.inp VISSIM network

The coordinates are written to an *.inp file without further transformation.

not applicable

*.hgrBackground file

not applicable Background files are not adjusted.

File type Write Read

Note: Graphic texts are network-independent graphic objects and therefore be differentiatedfrom labels of network objects and labels for plot output.

648 © PTV AG

Chapter 10.5: Processing the network display with graphic objects

Illustration 213: Legend with user-defined texts

10.5.3 BackgroundsYou can include many different graphic formats as a background for your network display. Bothvector graphics, for example *.shp or *.dxf and raster graphics, for example *.jpg, *.bmp or *.sidare supported. Including backgrounds is ideal to better create a network display and addgraphical information to scale. This is how a zoning plan or a city map can be applied to thebackground of the network display for example.

Backgrounds in graphics formats (Table 263) supported by VISUM can be freely scaled by theuser and placed where required in the network display. This means, that position and size aredetermined via virtual, modifiable coordinates. It is possible to put several backgrounds on topof each other. Their order of display can be changed by the user. illustration 214 shows anetwork section without background. Only the link network is displayed. Backgrounds with landuse were inserted in the same network background in illustration 215.

Note: Backgrounds can only be inserted with add-on module Background.

649 © PTV AG


Illustration 214: VISUM network display without background

Illustration 215: VISUM network display with background

650 © PTV AG

Chapter 10.5: Processing the network display with graphic objects

10.5.3.1 Supported background formatsTable 263 outlines the most important graphic formats, which can be imported into VISUM viagraphic object type backgrounds.

File type Description

*.bmp (dib) Bitmap: pixel-based Windows standard format

*.wmf (emf) Windows Metafile: both vector- and pixel-based Windows graphic format (standard and enhanced format)

*.gif Graphics Interchange Format: pixel-based standard format by Compuserve for internet applications

*.jpg Joint Photographic Experts Group: standard pixel-based format for internet applications developed by an ISO experts group

*.jp2 The JPEG2000 format also published by Joint Photographic Experts Group. Compared to JPG, this format offers a better compression rate and can also receive meta data.

*.png Portable Network Graphics: License-free raster graphics format for Internet applications. It was developed by the World Wide Web Consortium (W3C) to replace GIF and JPG.

*.psd Photoshop: Popular pixel-based format by Adobe for professional image processing on PC

*.tif Tagged Image File: pixel based default format for DTP and scanner applications; also with CCITT compression

*.tga Targa: Pixel-based format by Truevision for professional image processing on Workstations

*.dwg A CAD format developed by Autodesk for CAD software AutoCad. The DWG format today, is a de facto standard for CAD data exchange and the most commonly used drawing data format.

*.dxf Drawing Interchange Format: A vector graphic format developed by Autodesk, for CAD data exchange, which was developed for the CAD program AutoCAD. A *.dxf file writes a CAD model (for example a technical drawing) as text according to the ASCII standard.

*.ecw Enhanced Compression Wavelet: ECW is a raster graphic format, which allows very high compression rates. It is therefore ideal for saving aerial photographs and satellite images.

*.shp Shape files are data format for geodata, which are used in most GIS. The data format is ideal for including GIS data in VISUM (see "Shape files as a GIS interface" on page 634).

*.sid Multiresolution seamless image databaseMrSID is a compressed format for raster graphics. It is ideal for cartographic data and satellite images.

*.svg Scalable Vector GraphicsStandard for describing two-dimensional vector graphics in the XML syntax. The main language volume can be displayed by the most used web browsers without additional plug-ins (for example Firefox). A plug-in such as the SVG Viewer by Adobe allows the display on the Internet Explorer.

Table 263: Background formats supported by VISUM

651 © PTV AG


10.5.3.2 Automatical positioning of the background in the network with World files

If a raster graphic background is to be included in VISUM, georeferencing the background inthe network can be executed automatically, if in addition to the actual graphic file (for exampleBackground.jpg) a so-called World file (for example Background.jpw) is available, whichcontains the data for georeferencing the image file. If a World file is available, this makes theexchange and including backgrounds much easier, because the background is automaticallyinserted in the right position in VISUM. The effort for vernier adjustment of the backgrounddoes therefore not apply.A World file contains the transformation information used by the image, for the reference toworld coordinates. The format was specified and introduced by ESRI. The naming conventionfor World files provides, that the last letter of the file ending of the graphic file is replaced witha w, the rest of the file name corresponds to the respective graphic file (if the graphic is namedMap.tif for example, the respective World file is then named Map.tiw). A World file describesthe coordinates, the scale and the rotation of the background.

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

10.5.4 PolygonsThe polygons of the Background add-on module are graphic objects which facilitate the freedesign of drawings. Polygons can be edited in many ways:• Drawing lines or areas• Choice of color• Position of lines and line types• Patterns for areas

Note: World files do not contain a reference to a coordinate system.

32,00,00,0-32,0691200,04576000,0

Table 264: Example for a World file

Note: Georeferencing and thus creating the World file can be executed with GIS software (forexample ArcGIS by ESRI). Because the World file is a text file, it is theoretically possible tocreate it yourself in the text editor, if the necessary information is known.

652 © PTV AG

Chapter 10.6: GPS tracking

10.6 GPS trackingIf a GPS receiver is connected to your PC, you can display the current position in the networkgraphic. With tracking switched on, the network graphic display is then updated in user-definedtime intervals (see User Manual, Chpt. 10.10, page 1181).The function requires a connection via a serial interface. Receivers with a Bluetooth or USBinterface can also be used, if they emulate a serial interface. You can apply these functions todigitalize 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 awarning (for example due to bad transmission or incorrect conversion of the coordinates) willbe drawn in Marking1 color (see User Manual, Chpt. 12.2, page 1253). The position acquiredby the GPS receiver (length, width) will always be transferred (see "Coordinate systems" onpage 646) into the current projection of the network. If no projection has been set, the positionis taken over directly. All that has to be noted is that the network coordinates correspond to theactual geographical position.

Note: Polygons can only be inserted with add-on module Background.

653 © PTV AG


654 © PTV AG

11 Interactive analyses

VISUM offers different functionalities which you can use to interactively evaluate your trafficmodel. These can be used to analyze PrT as well as PuT. The following interactive analysesare available.

Subjects• Flow bundles• Isochrones• Shortest path search

11.1 Flow bundlesFlow bundles filter loaded paths determined in an assignment by a range of criteria. Loadedpaths are the result of assignment calculation and are characterized by the followingproperties.• 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 bundlecalculation. Marked network objects thus constitute the path filter criteria of a flow bundle.Below, you will find out which filter criteria can be used in detail. Table 265 displays theprinciple of the flow bundle. The left figure shows all paths found in the assignment and theright one shows paths which lead via the marked link.

Flow bundles Filtering paths from the assignment according to different criteria (for example, all paths which lead via a certain link)

Isochrones Analysis of the accessibility of network objects. Network objects which are available from one or several network objects in the same time are colored with the same color (for example, all locations which can be reached in 5 minutes by foot from a node).

Shortest path search Searching the shortest path between zones, nodes or main nodes according to different criteria (for example distance)

655 © PTV AG

Chapter 11: Interactive analyses

The flow bundle can be displayed graphically in the network editor (see User Manual, Chpt.11.1.4, page 1192) or output as a list (see User Manual, Chpt. 12.1, page 1227).Using PuTassignment as an example illustration 216 displays the flow bundle paths in the PuT path legslist. In the graphic display, the path courses highlighted in color and the respective flow bundlevolumes for each traversed link describe the spatial and quantitative distribution of traffic of thespecified flow bundle.

Illustration 216: Display of the flow bundle paths in the PuT path leg list

The flow bundle type is specified through the network object type selected:

All PrT paths (displayed as volume bars) Filtering all PrT paths, which lead via the marked link, through the definition of a flow bundle.

Table 265: The flow bundle as path filter

Note: To be able to display a flow bundle, an assignment has to be calculated and the pathssaved. You can save paths in the PrT (see Basics, Chpt. 5.1.2, page 849) and in the PuT (seeBasics, Chpt. 6.1.1.2, page 944).

656 © PTV AG

Chapter 11.1: Flow bundles

• Flow bundles based on nodes, main nodes, stops, stop points or stop areas (markingnodes, main nodes, stop points, stop areas or stops)

• Link flow bundle (marking links)• Zone and main zone flow bundle (marking zones or main zones)• Traffic type flow bundle (by setting certain links or time profiles as passive)The flow bundle can be created by marking one or more objects of a network object type. It canalso be determined by any combination of marked network objects of different network objecttypes (see "Combination of flow bundle criteria" on page 662).

11.1.1 Flow bundle definition by selecting network objectsFlow bundles are defined through the selection of network objects or by selecting the types oftraffic (combinations of this criteria are also possible). This section describes thecharacteristics of flow bundles, which are calculated by marking network objects.

Node flow bundle (PrT and PuT)The node flow bundle outputs all paths which lead to the marked node(s). In PrT you have toselect demand segments, whose paths should be considered (the assignment result and thusthe paths are available separately for each demand segment).A selection of the demand segments is also necessary in PuT. In addition, you can extend thefiltering of paths by further criteria. A PuT supply selection can be made on different levels,from transport system to line route, service trip and operator. A path is only contained in theflow bundle, if it traverses the selected network object (for example a stop point) with exactlythe specified PuT supply. Depending on the network object type, the definition of "traversed"differs. At a zone of the traffic type origin traffic, a condition is, for example, set at the first PuTpath leg of the path via the PuT supply filter.

The filter requirements which result from the selection of the network object and the definitionof the additional requirements for PuT network objects both have to be fulfilled at the same time(AND THEN link). In the following example (see "PuT node flow bundle with additional filtercriteria for lines" on page 658) all paths are contained in the flow bundle, which traverse thenode 100001 and use line 002 on at least one path leg. Line 002 does not have to be used onthe entire path. It is sufficient if line 002 is traversed on one of the path legs, seeillustration 218.

Notes: If a flow bundle is active, the trips belonging to the flow bundle can be saved as a flowbundle matrix.The flow bundle considers the active settings of the OD pair filter. This makes flow bundleanalyses for particular types of zones (for example, only internal zones) possible.

Note: For the definition of these additional filter criteria, only those network objects can beselected, which are actually traversed by the selected network object. If, for example, thenode k marked for the flow bundle is not traversed by line 002, the line is therefore notavailable.

657 © PTV AG


Illustration 217: PuT node flow bundle with additional filter criteria for lines

Illustration 218: Some of the paths which traverse node 100001 and use line 002

Main node flow bundle (PuT only)The main node flow bundle works analog to the node flow bundle. It outputs paths which leadvia the marked main node(s). You have to select the demand segment, whose paths should betaken into account for flow bundle calculation.

658 © PTV AG


Link flow bundle (PrT and PuT)The link flow bundle outputs all paths which lead to the marked link(s). You have to select thosedemand segments both in PrT and PuT, whose paths should be taken into account for flowbundle calculation. In PuT you also have the possibility of defining further filter criteria for PuTnetwork objects. These correspond to the criteria of the node flow bundle (see "Node flowbundle (PrT and PuT)" on page 657).

Flow bundles based on stop points, stop areas and stops (PuT only)The flow bundles for the three network objects of the stop hierarchy (stop point, stop area andstop) output all paths which lead via each marked network object. For each of the three flowbundles, as an additional filter criteria, you have to specify the passenger types to be taken intoconsideration.• Boarding passengers (B): to display a flow bundle, the boarding line must correspond to the

selected entries (if for example only one stop was marked for the flow bundle, this meansthat only those paths which start at the marked stop are output in the flow bundle).

• Alighting passengers (A): the last line must correspond to the selected entries (if forexample only one stop was marked for the flow bundle, this means that only those pathswhich end at the marked stop are output in the flow bundle)

• Transfers (T): both lines must correspond to the selected entries (if for example only onestop was marked for the flow bundle, this means that only those paths which intend to havea transfer at the marked stop from one line to another, are output in the flow bundle). Thefilter criteria for this type of transfer can be refined. You can, for example, specify that onlytransfers from the transport system Bus to transport system Tram or from line 002 to line001 should be taken into consideration.

• Through passengers with stop (W): Through passengers are passengers which travel witha line which travels via the stop, but do not get off there.

• PassThroughNoStop (N): Through passengers without a halt at the stop are passengerswhich travel with a line, which traverses via the stop, but which does not stop there.

Zone and main zone flow bundle (PrT and PuT)Flow bundles for the network objects zone and main zone output all paths which lead via themarked network object(s). You have to select those demand segments both in PrT and PuT,whose paths should be taken into account for flow bundle calculation. For the flow bundledefinition you have to specify the desired traffic types (origin traffic, destination traffic or bothtraffic types). Please note that zones cannot be traversed. They can only be picked as the first(origin zone) or last search object (destination zone) of a path or as a zone with origin anddestination demand.• Origin traffic: all paths which start in the selected zone or main zone• Destination traffic: all paths which end in the selected zone or main zone• Both origin traffic and destination traffic: all paths which start or end in the selected zoneFor PuT as for links and nodes you also have the possibility of defining further filter criteria forPuT network objects. More information can be found with the description of the node flowbundle (see "Node flow bundle (PrT and PuT)" on page 657).

659 © PTV AG


11.1.2 Flow bundle definition through selection of traffic typesYou can filter the paths of the flow bundle display by the traffic type (Internal traffic, Origintraffic, Destination traffic, Through trips, External trips, or Bypassing internal trips) if you setlinks or time profiles active or passive.In the following example, Lynnwood town center through traffic is illustrated by the flow bundleof traffic types. Only those paths are displayed in the flow bundle which start and also end atan external zone. In the illustration 219, the flow bundle for the through traffic and also one forthe flow bundle paths of external zones 136 to 27 is displayed.

Illustration 219: Display of through traffic with a flow bundle of active links

For both network objects (time profiles and links) the traffic types internal traffic, origin traffic,destination traffic, through traffic, external traffic and bypassing internal traffic aredistinguished. For links these have the following meanings:• Internal traffic: Paths which only use active network objects (links and time profiles) (to only

display the paths which lie within the urban area in the flow bundle display, for example)

Note: At least one link or one time profile needs to be passive in order to calculate a flowbundle of transport systems. To set it passive use the filter (see User Manual, Chpt. 2.5,page 124) or the spatial selection (see User Manual, Chpt. 2.6, page 144).

660 © PTV AG


• Origin traffic: Paths which start at an active network object (to display all commuter flowsfrom the urban area to the surrounding area as a flow bundle, for example)

• Destination traffic: Paths which end at an active network object (to display all commuterflows from the surrounding area to the urban area as a flow bundle, for example)

• Through traffic: Paths which start and end with a passive object, in between however, usesat least one active object (to display the HGV traffic which passes through a conurbation asa flow bundle for example)

• External traffic: Paths which do not use an active network object (to display the traffic whichdrives around the conurbation as a flow bundle, for example)

• Bypassing internal traffic: Paths which start and end with an active network object, inbetween however, use at least one passive network object (to display the traffic forexample, which starts and ends in the urban area, but on its route traverses through thesurrounding area, because there is a by-pass which has advantages concerning thespeed)

For active time profile path filters it is considered, which of the path leg uses an active orpassive time profile (for each path leg there is a clear time profile which is used by the path leg,hence, the filter settings have an effect for time profiles on the path leg). Table 266 shows whatrelevance the traffic types have for the path filters for active time profiles.

The abbreviations in Table 266 have the following meaning:a ... active time profilep ... passive time profilex ... irrelevant if active or passive time profileTable 267 graphically shows the meaning of traffic types in path filters for active time profiles.

Number of path legs 1 2 3 4

Internal traffic a a-a a-a-a a-a-a-a

Origin traffic - a-p a-x-p a-x-x-p

Destination traffic - p-a p-x-a p-x-x-a

Through trips - - p-a-p p-a-x-p orp-x-a-p

External trips p p-p p-p-p p-p-p-p

Bypassing internal trips - - a-p-a a-p-x-a ora-x-p-a

Table 266: Traffic types against the status (active / passive) of the path legs

Internal traffic

Through trips

Origin traffic

Table 267: Meaning of traffic types in path filters for active time profiles

661 © PTV AG


To demonstrate the application use, some example evaluations will be illustrated with pathfilters via active time profiles.1. Determine the number of passengers using long-distance trains on all path legs

• All time profiles are active for long-distance lines, all others are passive• Selection of the traffic type internal traffic

2. Determine the number of passengers using a long-distance line on at least one path leg• All time profiles are active for long-distance trains, all others are passive• Selection of the traffic types internal traffic, origin traffic, destination traffic, through

traffic and bypassing internal traffic3. Determine the number of passengers using at least one long-distance line on at least one

path leg and at least one public transport line on one path leg• All time profiles are active for long-distance trains, all others are passive• Selection of the traffic types origin traffic, destination traffic, through traffic and

bypassing internal traffic

11.1.3 Combination of flow bundle criteriaFor the paths determined by a flow bundle, you can also combine several criteria and connectthem with AND THEN or OR. You can also combine PrT criteria and PuT criteria. The flowbundles in show for example a combination of AND THEN terms and OR linksillustration 220.All paths which start in zone 102 and end in zones 1, 2 or 5 are output in the flow bundle. Forzone 102 the traffic type origin traffic was permitted, for zones 1, 2 and 5 only traffic typedestination traffic. The required settings can be seen in the window, in illustration 220.

Destination traffic

Bypassing internal trips

External trips

LegendActive time profile

Passive time profile

Table 267: Meaning of traffic types in path filters for active time profiles

662 © PTV AG


Illustration 220: Paths which start in zone 102 and end in zones 1, 2 or 5

Definition of an AND THEN termThe flow bundle describes all paths from origin to destination which traverse all markednetwork objects in exactly the order in which they succeed in the AND THEN term.illustration 221 shows an AND THEN term which contains ten links. All paths which traversethese links in the specified sequence are displayed.

663 © PTV AG


Illustration 221: All paths which traverse a link section in north direction

Definition of an OR linkBy inserting an OR link (see User Manual, Chpt. 11.1.3, page 1191), the AND THEN term iscompleted. The flow bundle describes all paths, which fulfill at least one path filter criteria,meaning one of the AND THEN terms linked with OR.Any number of AND THEN terms can be combined by OR operations. Every path is only outputonce with the flow bundle, even if it is found for several AND THEN terms.illustration 222 shows how a PrT flow bundle and a PuT flow bundle can be illustratedsimultaneously with an OR link. The PrT flow bundle shows all PrT paths which traverse thenodes 106062539 and 106062191. The PuT flow bundle shows all PuT paths which traversethe stops 106061623 and 106063464.

Notes: Any number of nodes, main nodes, stops, stop areas, stop points and links can belinked in any order.Zones and main zones can only be the beginning or end of a path and can therefore not betraversed.

664 © PTV AG


Illustration 222: Combination of flow bundles for PrT and PuT by using an OR link

11.1.4 Flow bundles with alternative routesIf you want to display all paths in the flow bundles which do not traverse the selected networkobjects, you have the possibility of displaying these alternative routes. Only those OD relationsare taken into consideration, which use the selected network objects. If 60% of the paths of anOD pair run via the link for the selected link s, the alternative routes then make up theremaining 40% of the paths of this relation. Those are the OD pair paths which are nottraversing via the selected link s. In the example in illustration 223, two links of a by-pass (inboth line directions) are marked for the flow bundle. The links of a direction are each combinedin an AND THEN term. Both AND THEN terms for both directions are linked via an OR link.This means that all paths are displayed which lead across this link section, independent of thedirection.

665 © PTV AG


Illustration 223: Link flow bundle with AND THEN term and OR link

In illustration 224 a flow bundle with the alternative routes is displayed. Those paths are output,which do not lead across the marked link section, for all OD pairs, for which paths have beenfound in the origin flow bundle. The comparison of the two illustrations shows, that most trafficuses the by-pass on these OD pairs. Only a few road users choose the routes which leadthrough the city. In a planning project the effectiveness of a created measurement could thusbe allocated.

666 © PTV AG

Chapter 11.2: Isochrones

Illustration 224: Link flow bundle with alternative routes

11.2 IsochronesBased on one or several selected network objects, isochrones visualize the accessibility ofother network objects. The accessibility can be classified in accessibility intervals. Theintervals can be displayed in the network editor with different colors. This is how you canhighlight all towns, for example, with the same color, which can be accessed from a specificnode in the same time. In practice, isochrones are used for example to analyze the catchmentarea of stops. In illustration 225 all stop areas in the urban area are marked and then anisochrone calculation is carried out. You can see, that especially potential PuT passengersfrom the eastern part of the city (colored dark red) need more than 8min to the next stop.

667 © PTV AG


Illustration 225: Isochrones to display the accessibility of stop areas

illustration 226 illustrates with a simple example the effectiveness of isochrones. In thisexample, isochrones were drawn based on node 20. The travel time in the loaded network(tCur) was used as a choice criterion. The links were labeled with these times. The linksegments were colored with different colors dependent on the accessibility (here depending ontCur) (see User Manual, Chpt. 12.2.3.9, page 1274). If for example you travel from node 20 vianode 11 to node 41, the in-vehicle time is 29min 35s. According to this, the last link section iscolored dark red before node 41, because here your journey is longer than 26min.

668 © PTV AG


Illustration 226: Functional principle of isochrones with a simple example

If several network objects are selected for the isochrone display, the shortest path from theselected network objects to the link section is calculated, for each link section. The shortest ofthese shortest paths then determines which accessibility interval is assigned to the link section.If, for example, nodes 21 and 31 are selected for the isochrone display and a link section canbe reached from node 21 in 22min and from node 31 in 28min, the link section is assigned tothe accessibility interval <= 22min and colored accordingly.

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

Note: The accessibility of network objects can be displayed simultaneously in the network forboth PuT and PrT.

Note: When selecting of the route choice criterion, note that t0, tCur and Impedancecorrespond as long as no assignment has been calculated.

669 © PTV AG


Accessibility of link sectionsThe link sections are drawn in the color of which accessibility interval they belong to.illustration 227 shows the accessibility of link sections from marked node 7357. Dark redcolored link sections can only be reached in more than 10min.

Illustration 227: Accessibility of link sections from node 7357

Classified display of network objectsThe classified display of the network objects nodes and zones is done with the output attributeIsochrones Time PrT. This means, that nodes and zones are colored depending on theirIsochrones Time PrT. In illustration 228 a classification of the zones was made with theIsochrones Time PrT.

670 © PTV AG


Illustration 228: Zones classified according to their Isochrones time PrT

11.2.2 PuT isochronesPuT isochrones visualize the accessibility of nodes, stops, stop areas, stop points, and zones.The accessibility is determined on the basis of a timetable-based connection search. It ispossible to include only active vehicle journey sections in the search and to confine themaximum number of transfers. Furthermore, you have to specify the time interval, in whichconnections should be searched, and an extension for the timetable-based connection search.The extension is the period after the specified time interval, where connections have to havereached their destination. Nodes, zones or stop areas – or a combination – can be marked forisochrones.In PuT there are two possible ways of displaying isochrones.• Drawing the isochrones as 2D display

Both attributes Isochrones Time PuT and Isochrones Number of transfers PuT can bedrawn for the classification of the accessibility intervals.

• Classified display of network objects node, zone, stop, stop area and stop point Classification can be made with the attributes Isochrones Time PuT or IsochronesNumber of transfers PuT.

Isochrone display in 2DFor the 2D display, the network background is colored depending on the accessibility intervals.The following attributes can be used, for the definition of the accessibility intervals.• Isochrones time PuT

PuT journey time from start (marked node, zone or stop area) to each network object forwhich the Isochrones Time PuT was calculated (node, zone, stop, stop area or stoppoint). This display form is used in illustration 229 to visualize the accessibility of stop

671 © PTV AG


areas. The main station is marked, which means, that the isochrones reproduce the PuTjourney time from the main station.

Illustration 229: 2D display of the accessibility of stop areas from the main station

• Isochrones Number of transfers PuTAlternatively, the 2D display can also be classified according to the Isochrones Numberof transfers PuT.

Classified display of network objectsFor PuT isochrones it is possible to display the nodes, zones, stops, stop areas and stop pointsas classified. The following two attributes can be used.• Isochrones time PuT

PuT journey time from start (marked node, zone or stop area) to each network object,calculated for the Isochrones time PuT (node, zone, stop, stop area or stop point).illustration 230 shows an example, where the stops are displayed as classified. The stopKarlsruhe main station is marked as start. The stops are illustrated as circles and theircoloring depends on the time in which each stop can be reached from the main station.

672 © PTV AG


Illustration 230: Classified display of stops on the basis of the isochrone time PuT

• Isochrones Number of transfers PuTNumber of transfers from the start (marked node, zone or stop area) to each network objectfor which the PuT isochrone was calculated (node, zone, stop, stop area or stop point).illustration 231 shows the same example as illustration 230. As a classification criteria theIsochrones Number of transfers PuT was selected here. It is therefore apparent whichstops can be reached from the main station with none, one or more than one transfer.

673 © PTV AG


Illustration 231: Classified display of stops on the basis of the isochrone number of transfers

11.2.3 Combination of PrT and PuT isochronesVISUM allows you to simultaneously display isochrones for PrT and PuT in one network. Thisis how the accessibility in PrT and PuT can be compared for example. In the example inillustration 232 the stops are displayed as classified according to the Isochrones Time PuT.The stop area 106062191 was marked for isochrone calculation. The link sections areclassified on the basis of the isochrone time PrT, for the PrT. Node 106062191 was marked asa start object for the PrT isochrone, which is located where the corresponding stop area is. Ifyou compare the accessibility to the main station (stop area 106062529) from the marked nodeor the stop area, it can be specified which temporal advantage it has driving the car or takingthe bus. Based on this comparison the appropriate measures can then be taken, for example,what needs to be done to make PuT more attractive. illustration 232 graphically displays, thatthe main station can be reached with PuT (106062529) in <= 6min from start (106062191). Acomparison with PrT (colored link sections) shows, that the same start-destination relation canbe covered in less than 3min.

674 © PTV AG


Illustration 232: Comparison of the accessibility in PrT and PuT in graphical display

The exact numbers are delivered by the list view (see illustration 233). The exact IsochronesTime PrT is 2min 50s, the Isochrones Time PuT is 5min 25s.

Illustration 233: Comparison of the accessibility in PrT and PuT in the list view

675 © PTV AG


11.3 Shortest path searchWith the shortest path search command you can determine the best paths from a chosen originto a chosen destination and display the result in the network (see illustration 234). Differentsearch criteria can be used to find the shortest path. The paths found can then be displayed ina shortest path search list.

Illustration 234: Shortest path search between two nodes in PrT

An interactive shortest path search can be used especially to find errors in network modeling.With the graphic output of the shortest path, you can quickly determine implausible shortestpaths in the network editor. It could thus occur, that links for a transport system weremistakenly blocked by the modeler and therefore an unexpected path between two nodes isassumed as the shortest path. With the shortest path search you can find such paths and undothe road closure if necessary.

Shortest path search PrTIn PrT, shortest paths can be searched for between nodes, main nodes or zones. The shortestpath is searched for the selected traffic system respectively. The following choice criteria arepossible as search criteria.

676 © 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 PuTShortest path search for PuT can either be done on the basis of the timetable (PuT tab) ortransport system-based (PuT TSys).If it is carried out as timetable-based, the connection with a minimum search impedanceapplies as the shortest path. Search impedance is thus any linear combination of journey timeand the number of transfers.Search impedance = x • journey time + y • number of transfersYou can also specify, whether a shorter journey time or less transfers is more favorable for theshortest path search. You can search for a timetable-based shortest path between two zonesor two stop areas.The transport system-based shortest path search does not differentiate between individualPuT lines. Modeling the transport supply only considers the links of a basic network with theirspecific run times. The basic network can comprehend the following three possibilities:• All road and rail links of the link network• Only those links which are traversed by PuT lines• Only those links which are traversed by active PuT linesFrom the links of this basic network a graph is constructed which forms the basis for a shortestpath search. Because individual lines are not distinguished, transfer stops with their respectivetransfer times cannot be included in the search. It is possible, however, to include transfertimes between different transport systems (transfer penalties for transport system transfers,such as between bus and train). The transport system-based shortest path search can beexecuted between two zones or two nodes.

677 © PTV AG


678 © PTV AG

12 Tabular and graphic display

VISUM provides a wide range of graphical and tabular display options for the data of yourtraffic model. You can analyze the model data from different views. It is possible to output thelink volumes calculated in an assignment as a table in a list and graphically as link bars in thenetwork editor (see "Graphical and tabular display of link volumes" on page 679). Below,display types which are often used are introduced in examples. Primarily, these are there togive an idea on the diversity of the graphic display possibilities in VISUM. You can find allsetting possibilities for graphic parameters and lists in the detailed description (see UserManual, Chpt. 12, page 1227).

Illustration 235: Graphical and tabular display of link volumes

Subjects• Lists

679 © PTV AG

Chapter 12: Tabular and graphic display

• Bars• Categorized display with attribute values• Labeling with tables• Labeling with diagrams• Turn volumes• Desire lines• Stop catchment areas• Lane allocation• 2D display• Timetable network graph• Column charts• Evaluations in the timetable editor

12.1 ListsUse 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 criteriaThe list columns contain freely selectable attributes, the rows contain different objects. Inaddition to the direct network object attributes, you also have access to indirect attributes inlists, therefore attributes of other network objects, for example in the zone list to the number oforigin connectors (see User Manual, Chpt. 2.2, page 98).You can specify which attributes should be displayed in the table columns, in all lists. Theselection of displayed attributes together with the format of the table columns (e.g. decimalplaces, alignment) is called list layout (see User Manual, Chpt. 12.1, page 1227). There aretwo types of lists, specific lists for each network object type and evaluation lists.

12.1.1 Specific network object listsSpecific lists are provided for all network object types (see "Example for link lists" onpage 681). Here you can edit the input attributes of the network objects and display additionalnon-editable attributes, such as assignment results for example (see "Example for link lists" onpage 681). Some of these lists have special features that are explained below.

680 © PTV AG

Chapter 12.1: Lists

Illustration 236: Example for link lists

Territory listsBoth territory lists contain PrT and PuT indicators precisely broken down. This is how theindicators can be calculated based on spatial territories, for example the service kilometerswhich lie within a county (see "Spatial cut (Territory cut)" on page 608). The sublists Basis andPuT detail are available for territories.

Basis The list outputs precise indicators of PrT and PuT for each territory. Dependent on the indicator, an assignment or the procedure territory indicators or PuT operating indicators have to be calculated before.TipTo get more detailed information on how to calculate the values for this list, have a look at the files IndicatorOrigin.xls and IndicatorAvailability.xls in your Doc directory of your VISUM installation.

Table 268: Territory lists

681 © PTV AG


OD pair listsIn an OD pair list you can output the following attributes for each relation between two zones:• Values from the skim matrices of the model• Values from the demand matrices of the model• Direct distance between zones• Values from the direct and indirect attributes of the From zone or To zone of the relation

Stop listsVISUM provides lists for the network object stop, stop area and stop point. In addition to thebase list for the network objects themselves, you can also find a list for the timetables at stoppoints and the transfer times between the stop areas of the stops, the transport systems, andthe time profiles.

PuT detail

For PuT, the indicators for each territory can be refined on the following levels of the line hierarchy, and if desired also per vehicle combination (see "Spatial cut (Territory cut)" on page 608).• Territory x Transport system• Territory x Main line• Territory x Line• Territory x Line route• Territory x Time profile• Territory x Vehicle journey• Territory x TSys x Vehicle combination• Territory x Main line x Vehicle combination• Territory x Line x Vehicle combination• Territory x Line route x Vehicle combination• Territory x Time profile x Vehicle combination• Territory x Vehicle journey x Vehicle combinationThis is how you can evaluate service kilometers per line within a territory for example.NoteThe list only contains entries after the procedure PuT operating indicators has been calculated.

Note: The matrix values can also be edited in this list, so that you do not have to switch to thematrix editor.

Stop points arrivals/departures

The list exports the trips and attributes of any stop point selected by the user such as, Arrival and Departure. As an option, you can also filter according to time profiles at the selected stop point.

Stop areas: Transition walk times

For each stop, the list contains the transfer times between the stop areas of the stop. Use the list for example, if you want to change the transfer times of multiple stops. You therefore do not have to open the window Edit stop for each individual stop, to change the times.

Table 269: Stop lists

Table 268: Territory lists

682 © PTV AG

Chapter 12.1: Lists

Item listsIn addition to basis lists (for example line route list) for the network objects of the line hierarchyand for system routes, item lists are also offered (for example the line route items list). Theselists contain the individual elements (items) of the network object. These are:

Line listsIn addition to the base list for network objects of the line hierarchy and the respective courselists, VISUM offers two special lists for coupling.

Block listsTo display and edit input and output attributes of line blocking, the lists block versions, blocksand block items are available.

Time profiles: Transition walk times

For each stop, the list contains the transfer times between the time profiles of the stop.

Transport systems: Transition walk times

For each stop, the list contains the transfer times between the transport systems of the stop.

Line route items All nodes and stop points of the line route

Time profile items All profile points of a time profile (see User Manual, Chpt. 2.30.3.3, page 393)

Vehicle journey items All profile points of the time profile which are traversed by the trip selected by the user

System route items All nodes and stop points which lie on the system route

Table 270: Item lists

Coupling sections All coupling sections with their From stop point No and To stop point No. This is how you can illustrate which stop points are coupled between which time profiles.

Coupling section items The list shows which time profile is coupled between which time profile elements.

Table 271: Line lists

PuT Line block versions

Shows the block versions contained in the model.

Blocks The list shows the blocks of all block versions. As an option, only the blocks of a block version selected by the user can be displayed.

Block items The individual elements of all blocks are contained in this list. The list shows the parts which make up a block and in which order these are traversed (service trips, empty trips, stand times, but also user-defined block item types). As an option, only the items of a block version selected by the user can be displayed.

Table 272: Block lists

Table 269: Stop lists

683 © PTV AG


12.1.2 Matrix listThe matrix list shows an overview of all matrices (see User Manual, Chpt. 12.1.9, page 1249).

12.1.3 Evaluation listsEvaluation lists only contain results from calculations or statistical values on the networkmodel. Their entries can therefore not be edited. An example is the PrT path list:

Illustration 237: PrT path list

Evaluation lists for pathsThe paths found between origin and destination zone in the assignment, are output in the pathlists (see User Manual, Chpt. 12.1.8, page 1244).

Note: The lists are empty if no assignment was calculated.

PrT paths Lists the paths calculated in a PrT assignment for the selected demand segment. The rows contain the paths from one origin zone to a destination zone.

PrT path sets Displays any existing PrT path sets.

PrT paths on link level Compared to the PrT path list, the links which lie on the path are listed additionally for each path. This is how the exact course of the path can be comprehended.

OD pairs PuT Lists aggregated skims for each OD pair, which were calculated for the routes or connections found with the assignment.NoteYou must calculate the skims beforehand – for PuT with the assignment or in a separate procedure (see "PuT skims" on page 414), for PrT via the procedure Calculate skim matrix (see "PrT skims" on page 271).

PuT paths Lists the paths calculated in a PuT assignment for the selected demand segment. The rows contain the paths from an origin zone to a destination zone.

Table 273: Evaluation lists for paths

684 © PTV AG

Chapter 12.1: Lists

Evaluation lists for transfersThere are two different transfer lists, in which you can display the transfers for each stop ortime profile/transport system (see User Manual, Chpt. 12.1, page 1227).

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

Statistical evaluation lists

PuT path legs Lists all path legs (see "Network model" on page 17) of each route or connection of an OD pair from an origin zone to a destination zone for the selected demand segment, found by the PuT assignment.

Note: The lists do not contain any entries if no PuT assignment was calculated beforehand.

Note: A previously calculated assignment is not required.

Statistics - Network information

The list provides statistical information on the current network.• Network

Number of objects per network type• License

Maximum number of objects for the current VISUM license• Max

Maximum number of objects for the largest VISUM licenseFurthermore, the list also provides detailed information (with subattribute) on the specific number of network objects. These are for example• Number of origin connectors or destination connectors of PrT or PuT• Number of one-way roads or turning prohibitions for each transport

system

Statistics – Goodness of PrT assignment

Output of convergence criteria as indicators of the PrT assignment quality (see "Convergence criteria of the assignment quality" on page 288). NoteThe convergence criteria are automatically calculated for the PrT assignment procedures Equilibrium, Equilibrium_Lohse and Stochastic assignment.

Statistics - Goodness of PrT assignment with ICA

Output of convergence criteria as indicators of the PrT assignment quality for assignments with ICA

Statistics - Assignment analysis

Output of the statistical evaluation of the assignment analysis for PrT or PuT (see "Assignment analysis PrT" on page 403 and "Assignment analysis PuT" on page 475)

Statistics – PuT assignment statistics

Output of indicators for PuT assignments which refer to the entire networkNoteThe indicators are calculated automatically with a PuT assignment (see "Transport system-based assignment" on page 428).

Table 274: Statistical evaluation lists

Table 273: Evaluation lists for paths

685 © PTV AG


12.2 BarsYou can draw links and connectors, whose width complies with the values of an indirect ordirect attribute of the link or the connector (see User Manual, Chpt. 12.2.4.10, page 1289). Thelink volume from a PrT assignment can thus for example be visualized, like in illustration 238,by scaling the link bar with the attribute Volume [Veh] PrT.

Illustration 238: Link bars with PrT volume

Connector bars can also be drawn. In illustration 239 the attribute Volume [Veh] PrT isdisplayed on the connectors.

Emissions (HBEFA) Output of the skims calculated network-wide by the emission calculation according to HBEFA (see "Emission calculation according to HBEFA 3.1" on page 618)

Table 274: Statistical evaluation lists

686 © PTV AG

Chapter 12.2: Bars

.

Illustration 239: Connector bars with PrT volume

You can draw as many bars as you like with different attributes along the link or connector. Thisis how you can simultaneously display the volume from a PrT assignment (attribute Volume[Veh] PrT) and the volume from a PuT assignment (attribute Volume [Pass] PuT) on a link,as can be seen in illustration 240.

687 © PTV AG


Illustration 240: Two link bars with PrT and PuT volume

12.3 Categorized display with attribute valuesThe display of the active network objects in the network editor can be categorized with attributevalues of the network object (see User Manual, Chpt. 12.2.8, page 1315). This makes itpossible to draw links differently in dependency of their link type, for example. Inillustration 241, illustration 242 and illustration 243 link and zone categorizations areillustrated.

688 © PTV AG

Chapter 12.3: Categorized display with attribute values

Illustration 241: Categorized link display according to link category

689 © PTV AG

Chapter 12.3: Categorized display with attribute values

Illustration 243: Zone categorization according to origin traffic

Bars (see "Statistical evaluation lists" on page 685) can also be displayed in categories. Independency of attribute Saturation PrT, the link bar is colored red, green or yellow inillustration 244.

691 © PTV AG


Illustration 244: Link bar display categorized according to saturation PrT

12.4 Labeling with tablesIn the network editor, the network objects can be labeled with freely configurable tables. Youcan output up to 5 rows and 2 columns of attribute names and the respective values, but alsofree text, in the table (see User Manual, Chpt. 12.2, page 1253). This is how you can label thestop points in your model with tables for example, which show the number of boardingpassengers, transfers and alighting passengers (illustration 245).

692 © PTV AG

Chapter 12.5: Labeling with diagrams

Illustration 245: Table display of boarding passengers, transfers and alighting passengers at stops

12.5 Labeling with diagramsIn the network editor, the network objects can be labeled with freely configurable charts (seeUser Manual, Chpt. 12.2.3.5, page 1267). Bar and pie charts are available. For zones you candisplay the number of inhabitants and jobs in a column chart for example (illustration 246).

693 © PTV AG


Illustration 246: Number of residents and workplaces per zone

You can also display the results of the mode choice (see "Mode choice" on page 113) – thedistribution of travel demand to the individual transport modes – for each zone in a pie chart(illustration 247).

694 © PTV AG

Chapter 12.6: Turn volumes

Illustration 247: Display of the mode selection as pie charts for zones

12.6 Turn volumesTurn volumes visualize attributes of turns (see "Network model" on page 17) at individualnodes (see User Manual, Chpt. 12.5, page 1336). If you select the attribute Volume [Veh] PrT(AP) for example, after an assignment you can illustrate which traffic volumes apply to theturns of a node (illustration 248).The turn attributes can also be displayed in a turn list (see "Lists" on page 680).

Tip: In the junction editor, you can also display turn volumes (see User Manual, Chpt.2.39.18, page 542).

695 © PTV AG


Illustration 248: Turn volume with display of turn volumes

12.7 Desire linesA desire line visualizes the values for relations between zones (From zone to To zone). Thevalues displayed on the desire line may derive from different origins.• From a demand matrix (for example to visualize the demand between zones)• From a skim matrix (for example to visualize the journey time between zones)• As a value from the network model itself (for example the direct distance between zones)• From a zone attribute of the From zone or the To zone of the relation (for example to

illustrate the From zone\origin traffic to other zones)You can draw a desire line link (direct distance between the centroid of the zones) or a desireline bar for the proportional display of values, for each relation (see User Manual, Chpt. 12.4,page 1326).The display of desire lines is useful for illustrating demand matrices and indicator matrices inthe network editor. This is how you can get an overview, which OD pairs (From zone to Tozone) are especially in demand, for example. The example shown in illustration 249 shows thetravel demand between the zone Oppidum and all other zones. It is clear, that there is anespecially high demand between the zones Oppidum and B town.

696 © PTV AG

Chapter 12.7: Desire lines

Illustration 249: Desire line with bars scaled at the demand between zones

The desire line is drawn on the direct distance between the zone centroids. If you areinterested in the exact course of the paths between origin and destination zones, then use theShortest Path Search (see User Manual, Chpt. 11.3, page 1208).Combined with the OD pair filter (see User Manual, Chpt. 2.5.6, page 139) the display of thedesire lines on OD pairs, which correspond to the filter criteria, can be confined. As analternative, the number of the OD pairs displayed can also be displayed via a classified display(see User Manual, Chpt. 12.2, page 1253).Furthermore, the desire line can also be drawn classified. As shown in illustration 250, you canhighlight OD pairs with a high traffic demand with colors, for example.

697 © PTV AG


Illustration 250: Desire line with bars classified according to the demand between zones

12.8 Stop catchment areasUsing stop catchment areas, you can draw circles around the stops, to graphically display thePuT development quality in the network. The circle can either be drawn with a constant radiusor in proportion to the values of direct or indirect stop attributes. Circles were drawn with aconstant radius of 400m in the example in illustration 251. As you can see, the Eastern part ofthe small town is insufficiently accessible by PuT, so that the extension measures should aimtowards making this territory more accessible.

698 © PTV AG

Chapter 12.8: Stop catchment areas

Illustration 251: Stop catchment areas with a large radius of 400m

Stop catchment areas can also be drawn classified. In illustration 252 catchment areas with aradius of 300m are drawn around the stops. The circles of stops with more than 1000departures per analysis period are red, stops with less than 500 departures, orange and stopswith less than 100 departures, green. This is how you can display how strongly stops arefrequented and how the entire network is made accessible by PuT, in a graphic.

699 © PTV AG


Illustration 252: Stop catchment areas classified according to the number of departures

12.9 Lane allocationTo visualize the node topology in the network editor (see "Junction modeling" on page 66) youcan graphically display the lane allocation at nodes. A rectangle is then drawn for eachoutgoing link of a node, which is open for one or more PrT transport systems and which hasone or more lanes. Inside the rectangle, an arrow is drawn for each approach lane and anarrow head for each permitted lane turn. illustration 253 shows an example of a node with fourlegs.

700 © PTV AG

Chapter 12.9: Lane allocation

Illustration 253: Lane allocation in the network display

A classified display is also possible for the lane allocations, by direct and indirect nodeattributes. This is how you can export the lane allocation in different colors, depending on thenode volume. illustration 254 illustrates this with an example of a roundabout.

Illustration 254: Classified lane allocation according to the node volume

701 © PTV AG


12.10 2D displayFor point objects, (for example nodes or stops) the two-dimensional (extrapolated) display typecan be actuated for display of the distribution of attribute values. Any numerical attribute canbe selected for display of extrapolated attribute values.The attribute value of the point object is extrapolated over the entire network area. For two-dimensional visualization, up to 10 value ranges can be defined with a specific backgroundcolor 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 thisprocess, 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 attributevalues calculated from all VISUM objects.

ExampleNode P1 with co-ordinates (x,y) = (0,0) has AddVal1 = 100. Point P = (300, 400) has a distance

of 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 requiredif 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 ofthe network is the extrapolated AddVal attribute value of point P.Based on user-defined classification intervals, the graphical display of attribute valuedistribution will show rings of value ranges having specific colors around any point object(illustration 255) of the selected class.

500 4002 3002+=

702 © PTV AG

Chapter 12.10: 2D display

Illustration 255: Isochrone view

Originally, this display type has been implemented in VISUM for graphical display ofisochrones (see "Displaying isochrones and the accessibility of network objects" onpage 1197) showing accessibility of network objects. For the extrapolation of numerical attributes of VISUM point objects, the input parameters donot necessarily have to be of the speed or time data type.• V-access (access speed) for extrapolation of attribute values• tMax-access (maximum extrapolated attribute value) for classified display

V-access (access speed)

Internally, the formula is still used by VISUM. For calculation of t values, speed is

specified by the user as parameter v = v - access and distance s results from the network scale.For attributes of other data types (for example AddValues without [unit]) the following has to be

taken into account: Formula produces a value in [seconds], which is, depending on the

attribute’s data type, interpreted as 1 unit. See example above: the resulting 360 [s] are addedto the AddVal data.

v st--=

t sv--=

703 © PTV AG


12.11 Timetable network graphWith the timetable network graph you can illustrate the following:• Line route items in a PuT network with headway • Connections at stops• Service trip patterns in the network (see "Calculating Service trip patterns" on page 1016)The schematized view which could only be achieved with a third-party program called VIRIATO(SMA + Partner, Zurich) so far, visualizes the systematic of a PuT network that includes, forexample, service frequencies, depots and transitions.Service trip patterns as well as departure and arrival minutes are visible at a glance at centralpoints in the PuT network so that transfer waiting times are clearly evident and departures canbe shifted. Optionally, transfers can be displayed as connecting lines within a node.VISUM automatically generates the layout of the display. It can, however, also be editedmanually. The illustration 256 shows the network display for the example Example.ver and theillustration 257 the fixed time plans for the same network. illustration 258 shows the timetablenetwork graph created on this basis.

Illustration 256: Stops in the network display

704 © PTV AG

Chapter 12.11: Timetable network graph

Illustration 257: Regular services mode in the timetable editor

For a basic headway of one hour, the above network / timetable settings produce the followingtimetable network graph (1st service pattern directed).

Illustration 258: Timetable network graph

705 © PTV AG


12.12 Column chartsYou can create column charts with values of direct and indirect attributes (see "Attributes" onpage 80) from the network editor, for individual network objects (see User Manual, Chpt. 12.12,page 706). You can create common chart displays directly from VISUM, without having toexport list contents to Excel, to create the graphics there.There are two standard types of column charts:• Column charts for time intervals: If you have defined time intervals (see "Spatial and

temporal correlations in VISUM" on page 71) in your model, you can display an attribute foreach time interval, for a network object. This function especially supports you whenanalyzing dynamic assignments. illustration 259 shows a column chart, for which threecolumns with the passenger volume for the entire PuT, the tram and the bus are drawn fora link, for each time interval.

Illustration 259: Column charts for time intervals

• Column charts for relations between network objects. For a network object (for examplestop), you can display attributes, linked via the VISUM data model network object (forexample the stop points of a stop) as column charts. In illustration 260, a column chart wasinvoked for the stop Durlacher Tor and a column was drawn for each network object stoppoint. As you can see, the stops are assigned three stop points, for which each the numberof boarding passengers, alighting passengers and transfers is displayed as a column chart.

Note: An entry of 1 to 2 hours is recommended for the base headway. For a base headwayof 1h, a headway of 20 minutes would result in a drawn line with three departure times (forexample 09, 29, 49).

706 © PTV AG

Chapter 12.13: Evaluations in the timetable editor

Illustration 260: Column chart for relations between network objects

12.13 Evaluations in the timetable editorIn the VISUM timetable editor you are provided with the tabular timetable as a tabular and thegraphical timetable as a graphical evaluation tool (see User Manual, Chpt. 2.42, page 563).The Timetable editor also offers a block view for line blocks (see "Display of line blocks in theblock view" on page 1043).

Tabular timetableIn the standard view, the tabular timetable is presented as in illustration 261.

707 © PTV AG


Illustration 261: Tabular timetable in the standard view

In the regular service mode (see User Manual, Chpt. 2.42.4, page 567) all trips are displayedas regular trips with the additional attributes Headway start, Headway end, Headway timeand Number of vehicle journeys (illustration 262).

708 © PTV AG


Illustration 262: Tabular timetable in regular service mode

You can also display the columns of the tabular timetable as classified (see User Manual, Chpt.12.2, page 1253). In the following example, the table background is classified by revenues(illustration 263).

709 © PTV AG


Illustration 263: Table background classified by revenue

Graphical timetableTrips and trip sections are displayed graphically in the graphical timetable. In illustration 264,the stroke display is classified according to lines (see User Manual, Chpt. 12.2, page 1253), todistinguish trips of different lines by using different colors.

710 © PTV AG


Illustration 264: Graphical timetable with classified display of trip line style properties

Item bars, which can be scaled with direct and indirect trip or trip section attributes, can bedrawn for trips and trip sections (see User Manual, Chpt. 12.2, page 1253). In the followingexample, the Volume of the trips is used as scaling attribute (illustration 265).

711 © PTV AG


Illustration 265: Item bars for trips

Item bars can also be classified (see User Manual, Chpt. 12.2, page 1253). In illustration 266classification is carried out with the trip volume.

712 © PTV AG


Illustration 266: Classification of item bars with the trip volume

VISUM offers the possibility of displaying multiple bars with different attributes on trips or tripsections (see User Manual, Chpt. 12.2, page 1253). illustration 267 displays bars forBoarding passengers, Alighting passengers and Through passengers.

713 © PTV AG


Illustration 267: Display of item bars for boarding passengers, through passengers and alighting passengers

714 © PTV AG

Literature

Bellei, G.; Gentile, G.; Meschini, L.; Papola, N.: A demand model with departure time choice for within-day dynamic traffic assignment.In: European Journal of Operational Research 175 (2006), No.3, pages 1557-1576 (available online at URL http://www.sciencedirect.com)

Bellei, G.; Gentile, G.; Papola, N.: A within-day dynamic traffic assignment model for urban roadnetworks. In: Transportation Research B 39 (2005), No. 1, pages 1-29 (available online at URLhttp://www.sciencedirect.com)

Bregman, L.M.: Ein Beweis der Konvergenz des Verfahrens von G.W.Sheleikhovski für einTransportproblem mit Beschränkungen (in Russisch). Shurnal vycisl.mat.i mat.fiz.7 (1967),No.1, pages 147-156 (Convergence of the procedure)

Bregman, L.M.: Eine Relaxationsmethode zur Bestimmung des gemeinsamen Punktes konvexer Mengenund ihre Anwendung zur Lösung konvexer Optimierungsaufgaben (in Russisch). Shurnalvycisl.mat.i mat.fiz.7 (1967), Nr.3, page620-631 – [Engl. translation: The relaxation method offinding the common point of convex sets and its application to the solution of problems inconvex 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 ResearchA 28 (1994), No. 6, page 473 (available online at URL http://www.sciencedirect.com)

Brilon, W.; Weinert, A.: Bemessungsverfahren für Knotenpunkte mit abknickender Vorfahrt. In:Straßenverkehrstechnik 7, 2002, pages 346-356.

Bundesministerium für Verkehr (Hrsg.): Richtlinien für den Lärmschutz an Straßen, Ausgabe 1990(RLS-90). Federal Ministry of Transport, Building and Urban Affairs, 1990

EMNID-Institut GmbH (Hrsg.): KONTIV 89: Bericht zur Methode. Anlagenband und Tabellenteil.Bielefeld,1991 (Method report)

Evans, A.W.: Some properties of trip distribution methods. In: Transportation Research 4 (1970), No.1,pages 19-36 (available online at URL http://www.sciencedirect.com)

Evans, S.P.; Kirby, H.R.: A three-dimensional Furness procedure for calibrating gravity models. In:Transportation Research 8 (1974), No.2, pages105-122 (available online at URL http://www.sciencedirect.com)

Förschner, G.: Verkehrsplanerische Berechnungsmethode des Straßengüterverkehrs. In: Wissenschaftund Technik im Straßenwesen, Heft 20, Berlin, 1982 (Transportation planning calculationmethod)

Forschungsgesellschaft für Straßen- und Verkehrswesen (Hrsg.): Leitfaden für Verkehrsplanungen.Köln : FGSV, 1985. (Road Traffic Resarch Association in Germany), 1985

Forschungsgesellschaft für Straßen- und Verkehrswesen (Hrsg.): Richtlinien für die Anlage vonStraßen, Teil: Wirtschaftlichkeitsuntersuchungen (RAS-W86). Köln : FGSV, 1986 (RoadTraffic Resarch Association in Germany)

Forschungsgesellschaft für Straßen- und Verkehrswesen (Hrsg.): Empfehlungen fürWirtschaftlichkeitsuntersuchungen an Straßen (EWS-97): Aktualisierung der RAS-W86.Köln :

715 © PTV AG

Literature

FGSV, 1997. (Road Traffic Resarch Association in Germany)

Furness, K.P.: Trip forecasting. Unveröffentlichter Vortrag. London, 1962

Furness, K.P.: Time function iteration. In: Traffic Engin. Control 7 (1965), No.7, pages 458-460

Gentile G.: Linear User Cost Equilibrium: a new algorithm for traffic assignment. Submitted for publication, 2009

Gentile, G.; Meschini, L.; Papola, N.: Macroscopic arc performance models with capacity constraints forwithin-day dynamic traffic assignment. In: Transportation Research B 39 (2005), No.4, pages319-338 (available online at URL http://www.sciencedirect.com)

Gentile, G.; Meschini, L.: Fast heuristics for the continuous dynamic shortest path problem in trafficassignment. Submitted to the AIRO Winter Conference 2005 special issue of the EuropeanJournal of Operational Research on Network Flows, 2006

Gentile, G.; Meschini, L.; Papola, N.: Spillback congestion in dynamic traffic assignment: a macroscopicflow model with time-varying bottlenecks. In: Transportation Research B 41 (2007), No.10,pages 1114-1138 (available online at URL http://www.sciencedirect.com)

The Highways Agency (Hrsg.): The geometric design of roundabouts. In: Design Manual for Roads andBridges, 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 reportLR 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 Roadresearch Laboratory report LR 909.Crowthorne: Transportation and Road researchLaboratory, 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 zurEntwicklung von Verkehrsverteilungsmodellen.Braunschweig, Technische Universität, Institutfür Verkehr und Stadtbauwesen, Diss., 1970 (Dissertation on Trip distribution)

Kirchhoff, P.; Leutzbach, W.; Pampel, E.; Holz, S.; Mott, P.; Sahling, B.M.: Verkehrs- undBetriebsplanung. Forschung Stadtverkehr, Reihe Auswertungen, Heft A3, 1987. (Traffic andOperational Planning)

Lamond, B.; Stewart, N.F.: Bregman’s balancing method.In: Transportation Research B 15 (1984), No.4,pages 239-248, (available online at URL http://www.sciencedirect.com)

Lebeuf, R.; Jörnsten, K.; Stewart, N.F.: On the use of Bregman’s balancing method for the solution ofrelaxed distribution problems. Tech.Rep. No.Montréal, Université de Montréal, Départementd'informatique et de recherche opérationelle (IRO), 1980

Leutzbach, W.; Haupt, T.; Mott, P.: Ermittlung der Verkehrsnachfrage. Forschung Stadtverkehr, ReiheAuswertungen, Heft A4, 1988. (Determination of Travel Demand)

716 © PTV AG

Literature

Lohse, D.: Berechnung von Personenverkehrsströmen. In: Wissenschaft und Technik im Straßenwesen,Heft 17, 1977 (Calculating passenger demand flows)

Lohse, D.; Teichert, H.; Dugge, B.; Bachner, G.: Ermittlung von Verkehrsströmen mit n-linearenGleichungssystemen – Verkehrsnachfragemodellierung.Scientific series of Institut fürVerkehrsplanung und Straßenverkehr of TU Dresden, Vol. 5, 1997102, 1997 (Calculatingpassenger demand flows)

Lohse, D.; Wegener, B.: Abschnitt 3: Verkehrsplanerische Berechnungsverfahren.In: Bauakademie derDDR (Hrsg.): Richtlinie für Stadtstraßen. Teil I: Methoden und Verfahren der städtischenVerkehrsplanung, Ausgabe 1981. Berlin : Bauinformation, 1982 (Transportation planningcalculation procedures)

Mäcke, P.A.: Ruske, W.: Straßenverkehrstechnische Untersuchungen für den zweiten Ausbauplan. In;Straße und Autobahn 19 (1968), No.6, pages 201-211 (Transportation planning analyses)

Möhring, R.; Nökel, K.; Wünsch, G.: A model and fast optimization method for signal coordination in anetwork. In: van Zuylen, H.; Middelham, F.(Hrsg.): Proceedings of the 11th Symposium onControl in Transportation Systems - CTS 2006, pages 73-78, Delft, 2006

Nordic Council of Ministers (Hrsg.): Road Traffic Noise: Nordic Prediction Method. Tema Nord1996:525. Denmark : Nordic Council of Ministers, 1996. – ISBN 9291208361

Norm DIN 18005 Teil 2 September 1991. Schallschutz im Städtebau: Lärmkarten; KartenmäßigeDarstellung von Schallimmissionen. Berlin : Beuth Verlag, 1991 (Noise Prevention in UrbanDevelopment)

Ortúzar, J.D.; Willumsen, L.G.: Modelling Transport. Chichester : Wiley, 1990

Ortúzar, J.D.; Willumsen, L.G.: Modelling Transport. Third edition.Chichester : Wiley, 2001

Salzwedel, J.: Untersuchungen zur Einordnung der verkehrsplanerischen Berechnung des Güter- undWirtschaftsverkehrs in das Modell- und Programmsystem PEVA. (Transportation planninganalyses) Dresden, Technische Universität, Institut für Verkehrsplanung und Strassenverkehr,Diplomarbeit, 1997 (Degree dissertation)

Schiller, C.: Integration des ruhenden Verkehrs in die Verkehrsangebots- undVerkehrsnachfragemodellierung. Scientific series of Institut für Verkehrsplanung undStraßenverkehr of TU Dresden, Vol. 5, 1997 (Transport supply and Traffic demand modelling)

Schmiedel, R.: Bestimmung verhaltensorientierter Personenkreise für die Verkehrsplanung. Karlsruhe,Universität (TH), Fakultät für Bauingenieur- und Vermessungswesen, Diss., 1984(Diisertationon Behaviour-oriented coverage)

Schnabel W.; Lohse, D.: Grundlagen der Straßenverkehrstechnik und der Straßenverkehrsplanung.Berlin : Transpress VEB Verlag für Verkehrswesen, 1980 (Foundations of Traffic Engineeringand Transportation Planning)

Schnabel, W.; Lohse, D.: Grundlagen der Straßenverkehrstechnik und der Verkehrsplanung. Bd. Berlin :Verlag für Bauwesen, 1997 (Foundations of Traffic Engineering and Transportation Planning)

Sonntag, H.u.a.: Entwicklung eines Wirtschaftsverkehrsmodells. Bundesministerium für Verkehr. Berlin,1995 – Forschungsbericht im Auftrag des Bundeministeriums für Verkehr (Commercialtransport model development)

717 © PTV AG

Literature

Transportation Research Board: Highway Capacity Manual, Washington, DC, 2000.

Transportation Research Board: Highway Capacity Manual, Washington, DC, 2010.

U.S.Bureau of Public Roads (publisher): Traffic Assignment Manual.Washington, D.C.: U.S. Departmentof Commerce, Bureau of Public Roads, 1964

718 © PTV AG

List of illustrations


Illustration 1: VISUM network model and impact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Illustration 2: Example of the temporal distribution of travel demand by four intervals of 30 minutes . . . . 6Illustration 3: Network of the original version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Illustration 4: Network of the version used for version comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Illustration 5: Network with version comparison: The volumes of both versions compared as well their

difference is displayed. „Verscomp“ is the name of the version comparison.. . . . . . . . . . . . . 11Illustration 6: Network 1 for the merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Illustration 7: Network 2 for the merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Illustration 8: Merge network of network 1 and network 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Illustration 9: Connection between transport systems, modes, demand segments and demand matrices .

22Illustration 10: Example of a TURNSTANDARD table in the network file which is used to specify standard

values for turn penalties and turn capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Illustration 11: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red) . . . . . . . 30Illustration 12: Examples for defining transport systems of a link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Illustration 13: Example for the different speeds of two PrT transport systems depending on the volume .

32Illustration 14: Transportation demand between zones illustrated in the transport network and as a demand

matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Illustration 15: Supply of the travel demand via connectors to the network . . . . . . . . . . . . . . . . . . . . . . . 35Illustration 16: Possibilities for modeling connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Illustration 17: Intersection area with multiple nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Illustration 18: Node and link types of main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Illustration 19: Main turns open to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Illustration 20: Main turns not open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Illustration 21: The stop hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Illustration 22: Possibilities of modeling stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Illustration 23: The line hierarchy used to model the PuT supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Illustration 24: Example for two line routes of a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Illustration 25: Example for two time profiles of a line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Illustration 26: Lengths in VISUM and their coherence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Illustration 27: Assignment of run times in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Illustration 28: Example for the aggregation of line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Illustration 29: Examples: Coupling two and three line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Illustration 30: Calculation example for the calculation of indicators in case of couplings . . . . . . . . . . . . 57Illustration 31: Reachability analyses for secondary schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Illustration 32: Allocating POIs to links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Illustration 33: Visualization of the local position of count locations with the date of the count . . . . . . . . 62Illustration 34: The Congestion Charge in London is an area toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Illustration 35: Summation and average calculations with screenlines. . . . . . . . . . . . . . . . . . . . . . . . . . . 65Illustration 36: Calculation of the urban traffic volume with screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . 66Illustration 37: Time series by percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Illustration 38: Time series of matrix numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Illustration 39: The relationship between the different analysis time intervals . . . . . . . . . . . . . . . . . . . . . 76Illustration 40: Assignment not possible because the validity of the demand and the assignment time

719© PTV AG


interval do not overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Illustration 41: The demand between 6:30 and 7:30 am is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Illustration 42: The demand between 6:30 and 7:30 am is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Illustration 43: Structural data of zones stored in user-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . 88Illustration 44: Count data stored in user-defined link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Illustration 45: Generating a subnetwork with stop point matrices regarding path legs and stop point

matrices regarding paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Illustration 46: Positive and negative surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Illustration 47: Correlations between different demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Illustration 48: Integrated four-stage demand model in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Illustration 49: Extended four-stage model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Illustration 50: Modeling through decision tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Illustration 51: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden) . . . 119Illustration 52: EVA1 function in dependence of impedance w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Illustration 53: EVA2 function in dependence of the parameters a and b . . . . . . . . . . . . . . . . . . . . . . . 140Illustration 54: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min] . . . . 192Illustration 55: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Illustration 56: VD function type BPR according to the Traffic Assignment Manual. . . . . . . . . . . . . . . . 204Illustration 57: VD function type INRETS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Illustration 58: VD function type LOHSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Illustration 59: Capacity analysis process for signalized nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Illustration 60: Method of calculation at two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Illustration 61: Calculation process for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Illustration 62: Calculation process for roundabouts according to HCM 2010 . . . . . . . . . . . . . . . . . . . . 251Illustration 63: Approaching flows at a four-leg roundabout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Illustration 64: Calculation process for roundabouts according to the TRL/Kimber method . . . . . . . . . 255Illustration 65: Description of the node geometry for the TRL/Kimber model . . . . . . . . . . . . . . . . . . . . 256Illustration 66: Example network for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Illustration 67: Green time split at all nodes with succeeding left turns . . . . . . . . . . . . . . . . . . . . . . . . . 264Illustration 68: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002 . . .

265Illustration 69: Progression quality for approach West at node 8003. . . . . . . . . . . . . . . . . . . . . . . . . . . 265Illustration 70: Progression quality for approach North at node 8002 . . . . . . . . . . . . . . . . . . . . . . . . . . 266Illustration 71: Example network for proportional distribution of the traffic demand. . . . . . . . . . . . . . . . 273Illustration 72: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2. . . . . . 280Illustration 73: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1 . . . . . 280Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2 . . . . . 281Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1 . . . . . 281Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2 . . . . . 282Illustration 77: Blocking back model, phase 2, relief of congestion. Initial situation. . . . . . . . . . . . . . . . 282Illustration 78: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1. . . . . . . . 283Illustration 79: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2. . . . . . . . . 283Illustration 80: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1. . . . . . . . . 284Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2. . . . . . . . . 284Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1. . . . . . . . . 285Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2. . . . . . . . . 285Illustration 84: Integral indicating the overall wait time over the interpolated measured queue lengths 287Illustration 85: Parameterization of the Kirchhoff distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Illustration 86: Parameterization of the Logit distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

720© PTV AG


Illustration 87: Parameterization of the Box-Cox distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Illustration 88: Parameterization of the Lohse distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Illustration 89: Distribution with variable beta according to the modified Kirchhoff rule

(please refer to Schnabel / Lohse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Illustration 90: Parameterization of the Lohse distribution model with variable Beta . . . . . . . . . . . . . . . 294Illustration 91: Procedure of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299Illustration 92: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Illustration 93: Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Illustration 94: Procedure of the network balancing for an OD pair in the equilibrium assignment. . . . . 310Illustration 95: Linear User Cost Equilibrium between two paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316Illustration 96: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . . 320Illustration 97: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . . 321Illustration 98: Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Illustration 99: ICA-based impedance calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Illustration 100: Procedure of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Illustration 101: Turn volume delay function of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . 341Illustration 102: Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Illustration 103: Discarding routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Illustration 104: Example for similarity of routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Illustration 105: Volumes and link run times after the first internal iteration step m=1 . . . . . . . . . . . . . . 352Illustration 106: Example for area toll : The London Congestion Charging Zone . . . . . . . . . . . . . . . . . . 357Illustration 107: Reducing the area toll to the link toll case

(For clarity reasons, turns without toll are not displayed) . . . . . . . . . . . . . . . . . . . . . . . . . . . 358Illustration 108: Toll station at highway exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Illustration 109: Example of a matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Illustration 110: Shortest path search graph with matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Illustration 111: Time-cost diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Illustration 112: Density function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Illustration 113: Distribution function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Illustration 114: Path Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Illustration 115: Distribution of the traffic demand onto the routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Illustration 116: Equilibrium formation with TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Illustration 117: Attribute selection for the Toll systems list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Illustration 118: Attribute selection for the Toll matrices list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Illustration 119: The dynamic user equilibrium problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Illustration 120: Time slice approach (left side) and time profile approach (right side) to the Continuous

Dynamic Network Loading problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Illustration 121: Scheme of the fixed point formulation for the WDDTA with spillback congestion . . . . . 369Illustration 122: Recursive expressions of path exit time, entrance time and cost . . . . . . . . . . . . . . . . . 372Illustration 123: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among

vehicular flow, speed and density along a given arc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Illustration 124: The trapezoidal fundamental diagram suggested for urban links . . . . . . . . . . . . . . . . . 374Illustration 125: Scheme of the fixed point formulation for the NPM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Illustration 126: Arc with time-varying capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Illustration 127: Flow pattern given by the Simplified Theory of Kinematic Waves. . . . . . . . . . . . . . . . . 378Illustration 128: Flow pattern given by the Averaged Kinematic Wave model . . . . . . . . . . . . . . . . . . . . 379Illustration 129: Determination of the arc hypocritical exit time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Illustration 130: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles . . . . . . 382Illustration 131: Graphical determination of the time series of the inflow capacity in the case of triangular

721© PTV AG


fundamental diagram, piecewise constant inflow, and constant exit capacity . . . . . . . . . . . 383Illustration 132: Dynamic version of the Bellman relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Illustration 133: Variables and models of the fixed point formulations for the network performance model

(left hand side) and for the dynamic assignment with spillback (right hand side) . . . . . . . . 387Illustration 134: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389Illustration 135: Results of WDDTA without and with spillback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390Illustration 136: Shape of the fundamental diagram based on the link attributes . . . . . . . . . . . . . . . . . 392Illustration 137: Parabolic sub-critical branch in the fundamental diagram . . . . . . . . . . . . . . . . . . . . . . 393Illustration 138: Signalized intersection in reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Illustration 139: Diagram of the signalized node in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Illustration 140: Example of the impedance calculation of a connection . . . . . . . . . . . . . . . . . . . . . . . . 398Illustration 141: Example of the network volume along a connection . . . . . . . . . . . . . . . . . . . . . . . . . . 398Illustration 142: Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402Illustration 143: Different modeling options for main and subordinated networks . . . . . . . . . . . . . . . . . 408Illustration 144: Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Illustration 145: Line map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Illustration 146: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420Illustration 147: Example for skim value calculation for partially traversed links . . . . . . . . . . . . . . . . . . 428Illustration 148: Network volume after transport system-based assignment (parameters file TSys1.par) . . .

429Illustration 149: Network volume after transport system-based assignment (parameters file TSys2.par) . . .

430Illustration 150: Example network for choice models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442Illustration 151: Structure of the choice in scenario 1 (no information) . . . . . . . . . . . . . . . . . . . . . . . . . 442Illustration 152: Structure of the choice in scenario 2 (local information). . . . . . . . . . . . . . . . . . . . . . . . 443Illustration 153: Structure of the choice in scenario 3 (information in the vehicle) . . . . . . . . . . . . . . . . . 444Illustration 154: Volume for headway-based assignment, transfer penalty 2 min . . . . . . . . . . . . . . . . . 448Illustration 155: Coordination of lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449Illustration 156: Network volume for timetable-based assignment (parameter file timetab1.par) . . . . . 465Illustration 157: Flow chart of a timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467Illustration 158: Standard questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479Illustration 159: Processing of PuT passenger surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481Illustration 160: Validity check of the survey path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483Illustration 161: Validity check of the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484Illustration 162: Territories in the example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492Illustration 163: Line 2 traverses several territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494Illustration 164: Allocation of vehicles and operators in the line hierarchy. . . . . . . . . . . . . . . . . . . . . . . 499Illustration 165: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . . 501Illustration 166: Conflict between empty trips and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503Illustration 167: Line network of the example with three bus lines (red, blue and yellow) . . . . . . . . . . . 505Illustration 168: (Graphical) timetable of the example, color codes as above . . . . . . . . . . . . . . . . . . . . 505Illustration 169: Covering the timetable through pure line blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Illustration 170: Covering the timetable through blocks without empty trips . . . . . . . . . . . . . . . . . . . . . 509Illustration 171: Covering the timetable through line comprehensive blocks with empty trips . . . . . . . . 511Illustration 172: Unsymmetrical timetable with trips beyond 24 hours . . . . . . . . . . . . . . . . . . . . . . . . . . 513Illustration 173: Blocking days and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517Illustration 174: State model for blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526Illustration 175: Example for partitioning according to vehicle combination and operator . . . . . . . . . . . 529Illustration 176: Inserting the nodes and edges for vehicle journey sections. . . . . . . . . . . . . . . . . . . . . 530

722© PTV AG


Illustration 177: Inserting the edges for entering the depots and for empty trips between stop points . . 531Illustration 178: Inserting the edges for leaving from depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532Illustration 179: Example graph after inserting the timeline edges and edge reduction . . . . . . . . . . . . . 533Illustration 180: Optimal cost flow in the example graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535Illustration 181: Example 1 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536Illustration 182: Example 2 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Illustration 183: Example for block display of a block with 5 blocking days . . . . . . . . . . . . . . . . . . . . . . 543Illustration 184: Possibilities of fare modeling in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547Illustration 185: Example for a distance-based fare with 5 fare stages . . . . . . . . . . . . . . . . . . . . . . . . . 551Illustration 186: Example for a zone-based fare with three covering fare zones and six stops. . . . . . . . 553Illustration 187: Example network with two lines and volume data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569Illustration 188: Calculation of service kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . . . . . 579Illustration 189: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m. . . . . . . . . . . . . 583Illustration 190: Calculation of passenger kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . . 584Illustration 191: Calculation schema for costs and revenues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585Illustration 192: Calculation of the fare points for path legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597Illustration 193: Example network for fixed amount per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600Illustration 194: Time-distance diagram for a vehicle journey with two vehicle journey sections . . . . . . 605Illustration 195: Aggregation along the line hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607Illustration 196: Aggregation of the service kilometers from the trips onto the line. . . . . . . . . . . . . . . . . 607Illustration 197: Interpolation of passage times (run times in minutes). . . . . . . . . . . . . . . . . . . . . . . . . . 608Illustration 198: Partially traversed links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609Illustration 199: Influence of couplings on the indicator calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610Illustration 200: Extended projection of attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611Illustration 201: Illustration of noise volume as link bars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616Illustration 202: Emissions relative to speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617Illustration 203: Display of nitrogen monoxide volumes as link bars . . . . . . . . . . . . . . . . . . . . . . . . . . . 618Illustration 204: Evaluation period and annuities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Illustration 205: Depiction of the results in EWS window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631Illustration 206: Source and target attribute allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635Illustration 207: Land use from two shape files as background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636Illustration 208: Examples of overlapping network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639Illustration 209: Intersecting three polygon objects with a link buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 644Illustration 210: Intersecting point objects with a polygon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645Illustration 211: Intersecting point objects with a buffer polygon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645Illustration 212: Intersecting point object buffers with polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645Illustration 213: Legend with user-defined texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649Illustration 214: VISUM network display without background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650Illustration 215: VISUM network display with background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650Illustration 216: Display of the flow bundle paths in the PuT path leg list . . . . . . . . . . . . . . . . . . . . . . . . 656Illustration 217: PuT node flow bundle with additional filter criteria for lines. . . . . . . . . . . . . . . . . . . . . . 658Illustration 218: Some of the paths which traverse node 100001 and use line 002 . . . . . . . . . . . . . . . . 658Illustration 219: Display of through traffic with a flow bundle of active links . . . . . . . . . . . . . . . . . . . . . . 660Illustration 220: Paths which start in zone 102 and end in zones 1, 2 or 5. . . . . . . . . . . . . . . . . . . . . . . 663Illustration 221: All paths which traverse a link section in north direction . . . . . . . . . . . . . . . . . . . . . . . . 664Illustration 222: Combination of flow bundles for PrT and PuT by using an OR link . . . . . . . . . . . . . . . 665Illustration 223: Link flow bundle with AND THEN term and OR link . . . . . . . . . . . . . . . . . . . . . . . . . . . 666Illustration 224: Link flow bundle with alternative routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

723© PTV AG


Illustration 225: Isochrones to display the accessibility of stop areas . . . . . . . . . . . . . . . . . . . . . . . . . . 668Illustration 226: Functional principle of isochrones with a simple example . . . . . . . . . . . . . . . . . . . . . . 669Illustration 227: Accessibility of link sections from node 7357 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670Illustration 228: Zones classified according to their Isochrones time PrT . . . . . . . . . . . . . . . . . . . . . . . 671Illustration 229: 2D display of the accessibility of stop areas from the main station . . . . . . . . . . . . . . . 672Illustration 230: Classified display of stops on the basis of the isochrone time PuT . . . . . . . . . . . . . . . 673Illustration 231: Classified display of stops on the basis of the isochrone number of transfers . . . . . . . 674Illustration 232: Comparison of the accessibility in PrT and PuT in graphical display . . . . . . . . . . . . . . 675Illustration 233: Comparison of the accessibility in PrT and PuT in the list view . . . . . . . . . . . . . . . . . . 675Illustration 234: Shortest path search between two nodes in PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676Illustration 235: Graphical and tabular display of link volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679Illustration 236: Example for link lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681Illustration 237: PrT path list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684Illustration 238: Link bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686Illustration 239: Connector bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687Illustration 240: Two link bars with PrT and PuT volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688Illustration 241: Categorized link display according to link category . . . . . . . . . . . . . . . . . . . . . . . . . . . 689Illustration 242: Categorized link display according to saturation PrT . . . . . . . . . . . . . . . . . . . . . . . . . . 690Illustration 243: Zone categorization according to origin traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691Illustration 244: Link bar display categorized according to saturation PrT. . . . . . . . . . . . . . . . . . . . . . . 692Illustration 245: Table display of boarding passengers, transfers and alighting passengers at stops . . 693Illustration 246: Number of residents and workplaces per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694Illustration 247: Display of the mode selection as pie charts for zones . . . . . . . . . . . . . . . . . . . . . . . . . 695Illustration 248: Turn volume with display of turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696Illustration 249: Desire line with bars scaled at the demand between zones. . . . . . . . . . . . . . . . . . . . . 697Illustration 250: Desire line with bars classified according to the demand between zones . . . . . . . . . . 698Illustration 251: Stop catchment areas with a large radius of 400m . . . . . . . . . . . . . . . . . . . . . . . . . . . 699Illustration 252: Stop catchment areas classified according to the number of departures. . . . . . . . . . . 700Illustration 253: Lane allocation in the network display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701Illustration 254: Classified lane allocation according to the node volume . . . . . . . . . . . . . . . . . . . . . . . 701Illustration 255: Isochrone view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703Illustration 256: Stops in the network display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704Illustration 257: Regular services mode in the timetable editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705Illustration 258: Timetable network graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705Illustration 259: Column charts for time intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706Illustration 260: Column chart for relations between network objects . . . . . . . . . . . . . . . . . . . . . . . . . . 707Illustration 261: Tabular timetable in the standard view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708Illustration 262: Tabular timetable in regular service mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709Illustration 263: Table background classified by revenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710Illustration 264: Graphical timetable with classified display of trip line style properties . . . . . . . . . . . . . 711Illustration 265: Item bars for trips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712Illustration 266: Classification of item bars with the trip volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713Illustration 267: Display of item bars for boarding passengers, through passengers and alighting

passengers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

724© PTV AG

List of tables

List of tables

Table 1: Additional attributes for a compared numerical attribute after version comparison . . . . . . . . . . . 9Table 2: Basic network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Table 3: PuT network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Table 4: General network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Table 5: PrT transport systems properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Table 6: Flow hierarchy symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Table 7: OD pairs in the example Example.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Table 8: Example for three service trips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Table 9: Input data for the calculation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Table 10: Calculation of indicators for the line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Table 11: Calculation of indicators for the links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Table 12: Network objects of the Junction model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Table 13: Deriving projection factors for AP and AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Table 14: Example for the interaction of analysis time intervals and time series . . . . . . . . . . . . . . . . . . . 77Table 15: Examples of input and output attributes at the link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table 16: Example for a 1..1 relation in the VISUM network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Table 17: Example for a 0..1 relation in the VISUM network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Table 18: Example for a 0..n relation with aggregate function Num. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Table 19: Example for a 0..n relation with aggregate function Min. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 20: Example for a 0..n relation with aggregate function Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 21: Example for a 0..n relation with aggregate function Sum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 22: Example for a 0..n relation with aggregate function Avg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 23: Example for a 0..n relation with aggregate function Concatenate . . . . . . . . . . . . . . . . . . . . . . 86Table 24: Example for a 0..n relation with aggregate function Histogram . . . . . . . . . . . . . . . . . . . . . . . . 87Table 25: Saving the cost per kilometer to a user-defined attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Table 26: Time-varying attributes and their allocation to assignment procedures . . . . . . . . . . . . . . . . . . 90Table 27: Impact of time-varying attributes in the Dynamic Stochastic assignment. . . . . . . . . . . . . . . . . 92Table 28: Table Main nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Table 29: Table Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Table 30: Table Surface items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Table 31: Table Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Table 32: Table Face items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Table 33: Table Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Table 34: Table Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Table 35: Table Intermediate points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Table 36: Examples for the normalization of surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Table 37: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs

119Table 38: Examples of relevant structural properties and person groups of the demand strata . . . . . . 120Table 39: Trip generation in EVA model: OD type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Table 40: Trip generation in EVA model: OD type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Table 41: Trip generation in EVA model: OD type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Table 42: List of the activity chains: mobility rates per person group in %. . . . . . . . . . . . . . . . . . . . . . . 146Table 43: Basic matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

725© PTV AG

List of tables

Table 44: Result matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Table 45: Abbreviations used in the User model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Table 46: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Table 47: Link-based PrT paths of a PrT assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Table 48: Variables used in VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Table 49: Parameters for all VD functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Table 50: VD function type BPR2: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Table 51: VD function type BPR2: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Table 52: VD function type CONICAL (Spiess) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Table 53: VD function type CONICAL_MARGINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Table 54: VD function type EXPONENTIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Table 55: VD function type INRETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Table 56: VD function types LOGISTIC, QUADRATIC, SIGMOIDAL_MMF_NODES,

SIGMOIDAL_MMF_LINKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Table 57: VD function type AKCELIK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Table 59: VD function type ICA-Turn (illustration 100, query 2: Is the turn share T below p2?“) . . . . . . 207Table 58: VD function type AKCELIK2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Table 60: VD function type LOHSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Table 61: VD function type Linear Bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Table 62: Input data of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Table 63: Car travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Table 64: HGV travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Table 65: Calculation of link impedance for HGV and car. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Table 66: Advantages and disadvantages of the node impedance model . . . . . . . . . . . . . . . . . . . . . . 210Table 67: Attributes for the impedance calculation from Turns VD function . . . . . . . . . . . . . . . . . . . . . 212Table 68: Attributes for the impedance calculation from Node VD function . . . . . . . . . . . . . . . . . . . . . 212Table 69: Attributes for the calculation regarding uncontrolled nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 214Table 70: Input attributes for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Table 71: Output attributes for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Table 72: Input attributes for the calculation of two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Table 73: Ranking of movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Table 74: Calculation of the conflicting volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Table 75: Base values for the critical gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Table 76: Follow-up times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Table 77: Impeding movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Table 78: Allocation of a LOS to the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Table 79: Input attributes for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Table 80: Adjustment factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Table 81: Probability states calculation of degree-of-conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Table 82: Excerpt from the DOC table for two lanes per approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Table 83: Lookup table base follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Table 84: Base values for the saturation follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Table 85: Determining the LOS based on the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . . 250Table 86: Input attributes for roundabout nodes according to HCM 2010. . . . . . . . . . . . . . . . . . . . . . . 251Table 87: LOS per lane based on the mean delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Table 88: Input attributes for calculation according to the TRL/Kimber method . . . . . . . . . . . . . . . . . . 256Table 89: LOS for calculation according to Kimber based on the mean delay . . . . . . . . . . . . . . . . . . . 259Table 90: Input attributes with effect at signal coordination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

726© PTV AG

List of tables

Table 91: Output attributes for signal coordination results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Table 92: Procedure parameters for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Table 93: PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Table 94: Aggregation functions for the skim data calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Table 95: Parameters for the distribution with variable beta in illustration 89 . . . . . . . . . . . . . . . . . . . . 294Table 96: Distribution to two alternatives with the impedances 5 and 10. . . . . . . . . . . . . . . . . . . . . . . . 295Table 97: Distribution for two alternatives with impedance 105 and 110 . . . . . . . . . . . . . . . . . . . . . . . . 295Table 98: Distribution for two alternatives with impedance 50 and 100 . . . . . . . . . . . . . . . . . . . . . . . . . 296Table 99: Model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296Table 100: Example of the incremental assignment (BPR function a=1, b=2, R=tCur) . . . . . . . . . . . . . 298Table 101: Input attributes for the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Table 102: Output attributes of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Table 103: Calculation of the user optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . . . . 302Table 104: Calculation of the system optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . . 302Table 105: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Table 106: Assignment results for the three PrT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Table 107: Assignment result at the links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Table 108: Input attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Table 109: Output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Table 110: Example equilibrium procedure (BPR function a=1, b=2) . . . . . . . . . . . . . . . . . . . . . . . . . . 311Table 111: Impedance in unloaded network, input parameters of Equilibrium_Lohse method . . . . . . . 325Table 112: Example of Equilibrium_Lohse: 1. Iteration Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Table 113: Example of Equilibrium_Lohse: 2. Iteration Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Table 114: Example of Equilibrium_Lohse: 3. Iteration Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327Table 115: Input attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Table 116: Output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Table 117: Input attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Table 118: Additional attributes of turns and main turns for assignment with ICA . . . . . . . . . . . . . . . . . 336Table 119: Output attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Table 120: Input attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Table 121: Output attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Table 122: Impedance in the unloaded network, input parameters for stochastic assignment . . . . . . . 350Table 123: Calculation of the commonality factor C for all route pairs . . . . . . . . . . . . . . . . . . . . . . . . . 351Table 124: Volumes in the first internal iteration step m = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Table 125: Volumes in the second internal iteration step m = 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Table 126: Input attributes for TRIBUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Table 127: Output attributes for TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355Table 128: Toll amounts for the example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Table 129: Comparison of conventional toll assignment and TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . 360Table 130: Input attributes for the DUE procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Table 131: Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Table 132: Output attributes of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Table 133: Input attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Table 134: Output attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . 400Table 135: Calculation rules for the output attributes of the assignment analysis . . . . . . . . . . . . . . . . . 404Table 136: Demand matrix and temporal distribution of demand for the example . . . . . . . . . . . . . . . . . 410Table 137: PuT supply of the example with connections from A-Village to X-City . . . . . . . . . . . . . . . . . 411Table 138: Path legs after a timetable-based assignment (paths saved as connections) . . . . . . . . . . . 413

727© PTV AG

List of tables

Table 139: Path legs after a timetable-based assignment (paths saved as routes). . . . . . . . . . . . . . . 413Table 140: Skims of time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415Table 141: Skims of length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Table 142: Monetary skims [Currency units] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Table 143: Skims of frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Table 144: Skims of attribute data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Table 145: Derived skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Table 146: Example of the connection skims of an OD pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420Table 147: Availability of the skims in the PuT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . . 421Table 148: Combination of skim data to the mean skim value per OD pair . . . . . . . . . . . . . . . . . . . . . 422Table 149: Example for the determination of the time difference DT . . . . . . . . . . . . . . . . . . . . . . . . . . 425Table 150: Comparison of the impedance functions in the PuT assignments. . . . . . . . . . . . . . . . . . . . 426Table 151: Connector weights for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Table 152: Temporary demand matrix for the assignment in the example . . . . . . . . . . . . . . . . . . . . . . 427Table 153: Example for headway calculation from mean headway according to timetable . . . . . . . . . 432Table 154: Example for headway calculation from mean wait time according to timetable . . . . . . . . . 433Table 155: Considering elapsed wait time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438Table 156: Travel times and headways of the lines in the example network . . . . . . . . . . . . . . . . . . . . 444Table 157: Line shares and the mean costs depending on the information available. . . . . . . . . . . . . . 445Table 158: Headway calculation for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Table 159: Impedance calculation for the routes in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Table 160: Changes to shares with variation of the transfer penalty. . . . . . . . . . . . . . . . . . . . . . . . . . . 448Table 161: Mean indicators for the headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448Table 162: Calculation of the temporal distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458Table 163: Procedure parameters for the comparison of the distribution models . . . . . . . . . . . . . . . . . 462Table 164: Example 1 – Initial situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462Table 165: Example 2 – Isochronous, identical pair of connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 462Table 166: Example 3 – Identical pair of connections with high temporal proximity . . . . . . . . . . . . . . . 462Table 167: Example 5 - Differing pair of connections with moderate temporal proximity . . . . . . . . . . . 463Table 168: Result of connection search (transfer penalty 10 min, parameter file timetab1.par) . . . . . . 464Table 169: Temporal distances ΔT and impedances R of the connections for the two analyzed intervals of

travel demand. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464Table 170: Distribution of trips to the connections (Kirchhoff, β = 3). . . . . . . . . . . . . . . . . . . . . . . . . . . 464Table 171: Calculation rules for the output attributes of the assignment analysis. . . . . . . . . . . . . . . . . 476Table 172: Status indicators for the surveyed path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485Table 173: Status indicators for the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485Table 174: Status indicators for the succeeding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486Table 175: Status indicators for the entire survey data record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486Table 176: Level Territory x Transport system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491Table 177: Indicators for line route analysis by territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492Table 178: Territory-based indicator data for transport performance and revenue analysis . . . . . . . . . 493Table 179: Territory-based analysis on aggregation level Territory x Line . . . . . . . . . . . . . . . . . . . . . . 494Table 180: Analysis of the Vol/Cap ratio of seats on the line route level. . . . . . . . . . . . . . . . . . . . . . . . 495Table 181: Service kilometer analysis on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495Table 182: Cost and revenue computation on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496Table 183: Evaluation of transport performance indicators on the level of operators . . . . . . . . . . . . . . 497Table 184: Evaluation of service kilometers per time interval for the bus operator . . . . . . . . . . . . . . . . 497Table 185: PassengerKm-to-ServiceKm ratio for the Bus operator . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

728© PTV AG

List of tables

Table 186: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . . . . . . 502Table 187: Block data of the three approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506Table 188: Block items of the line blocks in block version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Table 189: Block items of the line blocks in block version 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Table 190: Block items of the line blocks in block version 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Table 191: Open block and closed block for the unsymmetrical example (illustration 172) . . . . . . . . . . 514Table 192: Block items of both blocks in the example – Block items in the recurring rhythm were omitted for

a better overview. Block 1 is open, block 2 is closed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514Table 193: Block version attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515Table 194: Block attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517Table 195: Block item attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519Table 196: Block item type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521Table 197: Attributes of the line blocking cost function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521Table 198: Depot attributes of stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522Table 199: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in Table 197 refer

to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523Table 200: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates in

Table 197 refer to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523Table 201: Objective function components for line blocking with vehicle interchange . . . . . . . . . . . . . 541Table 202: Line blocking and vehicle requirement indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543Table 203: Example illustrating different variants of distribution of empty time and empty kilometers on in-

dividual service trips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545Table 204: PuT interlining matrix with t-PuTSys between stop points . . . . . . . . . . . . . . . . . . . . . . . . . . 546Table 205: Linking fare systems and demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560Table 206: Transport supply in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569Table 207: Projection factors for the valid days in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . 570Table 208: Projection factor for the demand segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570Table 209: Total capacity provided in the vehicles of example Example_LLE.ver. . . . . . . . . . . . . . . . . 570Table 210: Fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570Table 211: Fares of the fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571Table 212: Transport demand between the zones in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . 571Table 213: Cost rates for vehicles in Example_LLE.ver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571Table 214: Indicators for line route and timetable evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572Table 215: Indicators of the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Table 216: Indicators of the network performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580Table 217: Vehicle type-dependent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586Table 218: Infrastructure costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586Table 219: Total costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586Table 220: Cost rates for the vehicle units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587Table 221: Cost rates for the vehicle combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587Table 222: Distances and times for the vehicle combination Train in the analysis period . . . . . . . . . . . 588Table 223: Formulas for calculating link costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589Table 224: Example calculation for link depreciation costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589Table 225: Example calculation for running costs of links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590Table 226: Example calculation for link utilization costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590Table 227: Formulas for the calculation of stop point costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591Table 228: Formulas for calculating operator costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592Table 229: Calculation example for depreciation costs of the operator . . . . . . . . . . . . . . . . . . . . . . . . . 593Table 230: Calculation example for the running costs of the operator . . . . . . . . . . . . . . . . . . . . . . . . . . 593

729© PTV AG

List of tables

Table 231: Revenue indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Table 232: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595Table 233: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596Table 234: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596Table 235: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597Table 236: Calculation of the revenues per path (PuT routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598Table 237: Revenue calculation for the path leg Bus1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599Table 238: Aggregation of the path leg revenues to lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600Table 239: Input data for the calculation example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600Table 240: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0 . . . . . . . . . . . . . . . . 601Table 241: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.00 . . . . . . . . . . . . . 601Table 242: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.20 . . . . . . . . . . . . . 601Table 243: Indicators for the cost coverage calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602Table 244: Cost coverage calculation from revenues and costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602Table 245: Which projection factor applies for the calculation of indicators? . . . . . . . . . . . . . . . . . . . . 603Table 246: Difference in the projection to AH for ServiceKm and PassengerKm . . . . . . . . . . . . . . . . . 603Table 247: Further specifications for the vehicle journey with two VJ sections. . . . . . . . . . . . . . . . . . . 605Table 248: Calculation of seat kilometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606Table 249: Calculation of service kilometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606Table 250: Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614Table 251: Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618Table 252: EWS-specific link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628Table 253: Reading shape files in VISUM network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634Table 254: Illustration of VISUM files of shape types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637Table 255: Calculating the number of PuT passengers per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640Table 256: Calculating the number of inhabitants in the catchment area of lines . . . . . . . . . . . . . . . . . 640Table 257: Calculating the number of inhabitants in the catchment area of stops . . . . . . . . . . . . . . . . 641Table 258: Calculating the vehicle kilometers within territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641Table 259: Calculating the zone number where a stop point lies (). . . . . . . . . . . . . . . . . . . . . . . . . . . . 642Table 260: Calculating the average number of PuT passengers at the stops of a zone . . . . . . . . . . . . 642Table 261: Planar coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647Table 262: Geometric coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647Table 263: Background formats supported by VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651Table 264: Example for a World file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652Table 265: The flow bundle as path filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656Table 266: Traffic types against the status (active / passive) of the path legs . . . . . . . . . . . . . . . . . . . 661Table 267: Meaning of traffic types in path filters for active time profiles . . . . . . . . . . . . . . . . . . . . . . . 661Table 268: Territory lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681Table 269: Stop lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682Table 270: Item lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683Table 271: Line lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683Table 272: Block lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683Table 273: Evaluation lists for paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684Table 274: Statistical evaluation lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

730© PTV AG

Index

Index

AActivities 5, 106

attributes (EVA) 115Activity chains 107, 144, 146Activity pairs 5, 107

attributes (EVA) 115Air pollution emissions 616

pollution-Emis procedure 616Akcelik (VD function) 206Analysis

analysis horizon 75analysis period 75analysis time intervals 75, 76, 79

Annual calendar 72Assessment types 136Assignment

distribution models 289PuT procedure

see PuT assignment procedureAssignment analysis

PrT 403PuT 475

Assignment proceduresee Assignments

Assignment quality 288Assignment time interval 75Assignments

demand segments 25PrT procedures

see PrT assignment procedureAttraction 111, 118, 122, 134Attributes

direct 81indirect 82time-dependant 90user-defined 87

Average Excess Cost AEC (PrT assignment qua-lity) 288

BBackground formats 651Backgrounds 649

automatic positioning 652

Bar display 7, 686Best-route assignment 296Block check 525

forced 527general 527

Block element types 519Block elements 519Block version 515Blocking-back model 273Blocks 516Bounding 454Box-Cox model 291BPR (VD function) 204Branch and Bound 453Buffer 642

CCalculate skim matrix (procedure) 271Calculated results

temporal distinction 79, 80Calendar 45, 72Calendar period 75Capacities

adjust to demand values 80Cascetta 347Charts 7

column charts 694, 706pie charts 695

C-Logit approach 347Column charts 8, 706Commonality factor 347Complex terms

add 173Conical (VD function) 204Conical marginal (VD function) 205Connection choice

timetable-based assignment 458Connection search 453Connections

distribute traffic demandPrT 272PuT 426

independence (Timetable-based assignment)

© PTV AG 755

Index

460indicators 415

Connectors 34destination connector 34distribute traffic demand

PrT 35PuT 35

impedances 201multi point assignment (MPA) 35origin connector 34

Constant from time profile attribute (Headway cal-culation) 432Constraints 122, 145Controller types at node 213Co-ordinate systems 646Coordination groups 449Cordon links 37Cost (PuT) 584Cost-benefit analyses

see Modal SplitCost-Benefit Analysis 625, 630Cost-benefit ratio (CBR) 626Count locations 61Coupling time profiles 55Crosswalk 69Cycle time optimization 260

DdeltaT 457

early 457late 457

Demandsee transport demand

Demand matrices 3, 104updating 179

Demand model structure 105Demand models 1, 3

activity basedsee Demand models, VISEM model

EVA model for passenger demand 4, 115standard four-stage model 4, 110time series 5VISEM model 5, 144

Demand objects 5, 103Demand segments 22, 24, 104Demand strata 5, 108

attraction 111, 118, 122, 134attributes (EVA) 116

demand strata 134home trips 147production 111, 118, 122, 134

Desire lines 696Detectors 61Difference network

analysis time intervals 15examples 12see network merge

Direct assignment 487Display

2D 702Display turn volumes 7, 695Distribution models 289

box-Cox model 291kirchhoff model 290logit model 290lohse model 292

with variable Beta 293with independence 461

DMRB guideline TD 16/93 (roundabouts) 255Dominance 453Duality gap (PrT assignment quality) 288DUE 367Dynamic equilibrium assignment (DUE) 367Dynamic stochastic assignment 396

input and output attributes 399procedure 400

Dynamic User Equilibrium (DUE) 367evaluation 367input and output attributes 396

EEconomic assessment 625Edge 96Environmental impact model 613

air pollution emissions 616noise volume 613

Equilibrium assignment 301evaluation 302examples 303, 311input and output attributes 305procedure 307

Equilibrium_Lohse 342evaluation 331examples 325input and output attributes 328procedure 330

756 © PTV AG

Index

E-ticketing 481EVA

see EVA Model for Passenger DemandEVA Model for Passenger Demand 103

activities 115activity pairs 115assessment types 136balance factors 141, 144balancing 126constraints 122demand strata 116elasticity functions 138evaluation 136

evaluation functions 135, 137weighting probabilities Evaluation (EVA)

weighting probabilities 136furness method

trilinear 141home trips 134mobility rates 121mode choice 135multi procedure

trilinear 141structural properties 115study area factors 121trip distribution 135trip generation 118zones 117

EVA model for passenger demand 4, 115Evaluate results 7Evaluation (EVA) 136, 144

evaluation functions 135, 137weighting Matrices 144

EWS-97 625Excess emissions

calculation according to HBEFA 622

FFace items 96Faces 96Fares 424Flow bundle 7Flow bundles 655

alternative routes 665combine floe bundle criteria 662display paths 665flow bundle definition 657link flow bundle 659

main node flow bundle 658node flow bundles 657select network objects 657select transportation type 660stop point, stop area, and stop flow bundle 659zone and main zone flow bundle 659

Formula German 112

GGeographic information systems (GIS) 633Georeferenced 646GIS objects 64, 633Go to the operation (procedure) 4, 169GPS tracking 653Graphic display 679Graphic objects 648Graphical timetable 710Gravity model 112, 157

calculate 157calibrate 156

Green time optimization 260

HHBEFA

Basis for calculating cold start excess emissi-ons 622Basis for calculating warm emissions 619emission calculation 618

HBEFA-based emission calculation 618HCM 213Headway calculation

from mean headway 432from mean wait time 433

Headway-based assignment 430calculate headway 432coordination 449generalized costs 433impedances 433

Highway Capacity Manual (HCM) 213Histogram 172Home trips 134, 147Hypothetic vehicle impedance (PrT assignment quality) 288

IICA 213Impact Models

environmental impact model 191

© PTV AG 757

Index

operator Model 190user model 189

Impact models 1, 6, 189Impedance

headway-based assignment 433Impedance Functions 191Impedance functions

at node 210EVA Model for Passenger Demand 136headway-based assignment 433PrT assignments 200timetable-based assignment 455

Impedancesconnectors 201examples 209links 201main turns 202nodes 201preloaded volume 202routes 200turns 201

Incremental assignment 296evaluation 301examples 296input and output attributes 299procedure 298

Independence of connections 460Indicators 193

calculate (PrT) 271global indicators 194PuT 415, 416, 417, 418skim matrices 193

Indirect attributesaggregation functions 83average and AverageAktive 85concatenate and ConcatenateActive 86count and CountActive 83frequency and FrequencyAktive 86max and MaxAktive 84min and MinActive 83relations 82sum and SumActive 84

INRETS (VD function) 206Interactive analyses 655

flow bundles 655isochrones 667shortest path search 676

Intermediate points 96

Intersection Capacity Analysis (ICA) 213all-way stop 243Roundabouts 250signalized nodes 214two-way stop nodes 234uncontrolled nodes 214

Isochrones 7, 667combine PrT and PuT isochrones 674PrT isochrones 669PuT isochrones 671

JJunction modeling 66

KKirchhoff model 290

LLane 68Lanes

lane allocation 700lane turn 69

Leg templates 69Legend 648Level of Service 242Line blocking 500, 501

block check 525block element and block element type 519block version 515blocks 516check coverage 528cost function 521data model 504depots 522distribute empty trips and empty times 543evaluation of the procedure 503examples 504lists 683optimzation problem 502procedure 529, 535PuT interlining matrix 543stand times 522with vehicle interchange 538

Procedure runs 538without vehicle interchange 528

Line hierarchy 45data consistency 53

Line routes 46

758 © PTV AG

Index

aggregate 54edit shape with system routes 58specify lengths 51

Linear bottle-neck (VD function) 208Lines 46Link orientations 67Links 28

impedances 201link types 29major flows 29permitted transport systems 30PrT capacity 31PrT speed 31PrT travel time 31PuT running time 32specify lengths 51specify link run time 51

Lists 7, 680assignment analyses 685couple sections 683Coupling section items 683emissions HBEFA 686line blocks 683

block items 683block lists 683line block versions 683

line lists 683line route items 683lines 683network information 685OD pair lists 682PrT

path sets 684paths 684paths on link level 684quality assignment 685quality assignment with ICA 685

PuTassignment statistics 685detail list 681OD pairs 684path legs 685paths 684

PuT assignment statistics 685shortest path search 685stop lists 682stop points - Arrivals/Dep. 682system route items 683

territory lists 681time profile items 683Time profiles

Transition walk times 683transfer walk times at stops 682transfers 685Transport systems

Transition walk times 683vehicle journey items 683

Logit model (Distribution model) 290Lohse (VD function) 208Lohse model 292

with variable Beta 293

MMain lines 46Main nodes 36Main relations 39Main turns 38

impedances 202Main zone matrices

disaggregate 175Main zones 39Major flows 29Matched transfers 450Matrices 3, 104

Add complex term 173Adding columns or rows 176aggregate 177calibrate (PrT) 187classify matrix values 172correct 179demand matrices 104diagonal

extract 172set 172

edit 170functions 170

exponential function 173extend 176

see Matrices, splitform reciprocal 173forming maximum or minimum 173gravity model

calculate 157calibrate 156

logarithmic 173matrices and combining vectors 173

© PTV AG 759

Index

mean value upper/lower triangle 173project 173projecting path volumes (PrT) 187raise to power 173reflect 172split 178symmetrize 173transpose 172weighting Matrices 144

Matrix correction 179calibrate matrix (PrT) 187projecting path volumes (PrT) 187TFlowFuzzy 179

Matrix Editor 170Matrix editor 5, 104Mean value

calculatingattributes 169matrices 169

Merge network 13Method of Successive Averages 169Metropolis 402Modal Split 165Mode choice 4

EVA Model for Passenger Demand 135nested (Standard four-stage model) 111, 114standard four-stage model 113VISEM model 151

Model transfer files 15Models

compare 8Modes 22, 24MPA

see multi point assignmentMSA

see Method of Successive AveragesMulti Point Assignment 35Multi procedure 157, 159, 174

trilinear (EVA) 141

NNCHRP 255 402Nested Mode Choice

see Mode choice, nestedNetwork check 71Network display

bars 686classified 688

Labeling with diagrams 693Labeling with tables 692

Network merge 12Network model 1, 2Network objects

block 516block element type 519block elements 519block item types 21block version 515block versions 21buffer 642connectors 18, 34count locations 21, 61demand segments 17, 22, 24, 104detectors 22, 61fare zones 21GIS objects 22, 64, 633intersect 638, 642line blocking 504line routes 20, 46lines 20, 46link types 18links 18, 28main lines 20, 46main node 18main nodes 36main relations 39main turns 18, 38main zones 18, 39modes 17, 22, 24node 17nodes 26OD pairs 19operator model (PuT) 498paths 19, 40points of interest (POI) 21, 59PuT coordination groups 21PuT operators 20, 44PuT vehicles 45screenlines 22, 64stop areas 19, 43stop points 19, 42stops 19, 44system routes 20, 58territories 18, 40ticket types 21time profiles 20, 48

760 © PTV AG

Index

toll systems 22transport systems 17, 22, 23trips 20turning standards 18turns 18, 26valid days 19, 45, 72vehicle combinations 20, 45vehicle journey sections 20, 50vehicle journeys 49vehicle units 21, 45zones 18, 32

Neworkscompare 8

Nodecontroller types 213impedances 210

Node geometry 68Node impedances 210

calculate according to HCM 213node VD function (TModel) 212turn VD function 212

Node legs 68Node model 66

crosswalk 69lane turn 69lanes 68leg templates 69link orientations 67node legs 68node templates 69node topology 68signal control 70

Node templates 69Node topology 68

display graphically 700Node VD function (TModel) 212Nodes 26

impedances 201signal control 70signal time optimization 260traffic-related modeling 66

Noise volume 613noise-Emis-Nordic procedure 613noise-Emis-Rls90 procedure 613the Noise-Emis-Nordic procedure 614

OOD matrices

see Demand matricesOD pairs 33Operator model 498Operator Model (PuT) 190Operator model (PuT) 489

example 497examples 491, 494line blocking 500network objects 498parameters (aggregation levels) 490territory section (aggregation levels) 493work stages 499

Operatorsin the operator model 498

Origin wait time (Timetable-based assignment) 456

PParameters 193

calculate aggregation levels 490examples 491, 494, 497territory section (aggregation levels) 493

Passenger survey 477direct assignment 487survey data

assignment 487plausibilization 481read 481

Path legsPrT 199PuT 412

Paths 40, 192display (Flow bundles) 665filter (Flow bundles) 655PrT 199PuT 412

Perceived journey time 424, 456Person groups 5Personal Geodatabase (PGD) 633Pivot-Point model

see Modal SplitPoint 96Points of Interest (POI) 59Pollution-Emis procedure 616Polygons 652Population groups 105Procedure runs

Line blocking without vehicle interchange 528

© PTV AG 761

Index

Production 111, 118, 122, 134Projecting path volumes (PrT) 187Projection 75

examples 76Projections 646PrT

path legs 199path object 40paths 199

PrT Assignment proceduredynamic equilibrium assignment 367dynamic stochastic assignment 396metropolis assignment 402toll 353TRIBUT 353

PrT assignment procedure 195convergence criteria 288equilibrium assignment 301Equilibrium_Lohse 342incremental assignment 296stochastic assignment 342use solution as starting solution 202VDR functions 202

PrT assignment proceduresimpedance functions 200

PuToperational indicators 545

analyze line route and timetable 572calculate fare revenues 594calculate transport performance 580costs and revenue model 584Distribute empty trips and empty times 543examples 569, 593hourly costs 587kilometer costs 587link costs 588, 589measure transport supply 576operating cost 584, 585operator costs 591stop point costs 590vehicle costs 587vehicle type costs 586, 587

operator 498Operator model 6operator model 498operators 44Passenger surveys 477Path legs 412

paths 412revenues 594vehicles 45

PuT assignment procedure 407PuT assignment procedures

headway-based 430timetable-based 452transport system-based 428

PuTAux transport system 465

QQueues 205

RRamp metering 205RAS-W-86 625Relative Gap RG (PrT assignment quality) 288Revenue (PuT) 584

fares 424RLS-90 613Route search

transport system-based assignment 430Route volume

transport system-based assignment 430Routes

distribution of demand 289impedances 200indicators 415

SSC 70Screenlines 64Shape files 634Shortest path search 7, 454, 676

PrT 7, 676PuT 7, 677

Signal control 70stage templates 71

Signal controls 70Signal coordination 262Signal time optimization 260Skim matrices 7Skim matrices Matrices

skim matrices 104Standard four-stage demand model 4, 110Standard four-stage model 103, 111, 112

mode choice 113nested 111, 114

762 © PTV AG

Index

time-of-day choice 114Standardized assessment

see Modal SplitStochastic assignment 342

commonality factor 347distribution models 289evaluation 342examples 350

Stop points 42Stops 44

display catchment areas 698hierarchies 41zones 43

Structural properties 111EVA Model for Passenger Demand 115VISEM model 144

Subnetwork generator 93Surface items 96Surface model 93

multi-part surface 98standardize surfaces 98table 96

Surfaces 96Survey data

assignment 487plausibilization 481read 481

System optimum 205, 302System routes 58

TTables 7Tabular display 679Tabular timetable 707tCur 202Temporal utility 425Territories 40, 80Texts 648TFlowFuzzy 179The 453Time profiles 48

coupling 55specify run times 51

Time series 73, 105examples 77matrix numbers 5, 74, 105percentage 5, 74, 105

Time-dependant attributes 90

Time-of-Day Choicestandard four-stage model 114

Timetable 53Timetable editor 8, 707

evaluations 707graphical timetable 710tabular timetable 707

Timetable network graph 704Timetable-based assignment 452, 458

connection choice 458, 463connection preselection 455connection search 453

branch and bound 453shortest path search 454

distribution of trips for connections 459evaluation 452impedance 455independence of connections 460opening 466perceived journey time 456PuTAux transport system 465temporal utility 425, 457

TModel 212Toll in the assignment 353Toll systems 63Total Excess Cost TEC (PrT assignment quality) 288Traffic demand 1, 3

distribute on PuT connections 426distribute to PrT connections 272model 1, 3

Traffic demand matricessee demand matrices

Traffic demand model 1, 3Transfer wait time (Timetable-based assignment) 456Transport system-based assignment 428

evaluation 429route search 430route volume 430

Transport systems 22, 23Transportation deman 103

model 109Transportation demand 4

distribution on routes 289time reference 73time series 73

Transportation demand model 103

© PTV AG 763

Index

TRIBUT procedure 353Trip distribution 4, 112

EVA Model for Passenger Demand 135standard four-stage model 112VISEM model 147

Trip generation 4, 111EVA Model for Passenger Demand 118standard four-stage model 111VISEM model 146

Trips 49Turn VD function 212Turns 26

Impedances 201PrT capacity 28PrT turn time 28turn standards 27turn types 27

UUser model 6User optimum 205, 302User-defined attributes 87

VValid days 45, 72Value of time (VT) 355VD functions 202

akcelik 206BPR (according to Traffic Assignment Manu-al) 204conical 204conical marginal 205INRETS 206linear bottle-neck 208logistic 206lohse 208quadratic 206SIGMOIDAL_MMF_LINKS 206SIGMOIDAL_MMF_NODES 206user-defined 209

Vehicle combination set 538Vehicle combinations 45

in the operator model 498Vehicle journey sections 50Vehicle journeys 49Vehicle units 45

in the operator model 498Version comparison 9

Versionscompare 8

VISEM model 5, 103, 144activity based model 144constraints 145destination choice 147home trips 147mode choice

combined 151structural properties 144trip distribution

combined 147trip generation 146utility function 148, 151

WWeekly calendar 72Weighting (EVA)

evaluation functionsBoxCox 138Box-Tukey 138combined 138EVA1 137EVA2 137, 140kirchhoff 138logit 138schiller 137, 140TModel 138

Weighting matrices 104World files 652

ZZone matrices

aggregate 175Zones 32

attributes (EVA) 117

764 © PTV AG

Traffic SoftwareLogistics SoftwareTransport Consulting

PTV AGStumpfstr. 176131 KarlsruheDeutschland

Tel.: +49 721 9651-300Fax: +49 721 9651-562info.vision@ptv.dewww.ptv.dewww.ptvag.comwww.ptv-vision.de

ptv visum-fundamentals

Documents

demand model structure1053

surface model

demand objects

demand time series

environmental impact

user model prt

demand model31

demand segments222