Professional Documents
Culture Documents
FUNDAMENTALS
Copyright
2013 PTV AG, Karlsruhe, Germany
All brand or product names in this document are trademarks or registered trademarks of the
corresponding companies or organizations. All rights reserved.
Cover picture: VBZ
Legal agreements
The information contained in this documentation is subject to change without notice and
should not be construed as a commitment on the part of the vendor.
Without the prior written permission of PTV AG, this manual may neither be reproduced or
stored in a retrieval system, nor transmitted in any form or by any means, electronically,
mechanically, photocopying, recording, or otherwise, except for the buyer's personal use as
permitted under the terms of the copyright.
Warranty restriction
The content accuracy is not warranted. We are grateful for any information on errors.
Imprint
PTV AG
76131 Karlsruhe
Germany
Tel. +49 721 9651-300
Fax +49 721 9651-562
E-mail: info@vision.ptvgroup.com
www.ptvgroup.com
www.vision-traffic.ptvgroup.com
Last amended: May 28, 2013 EN-US F
Structure
1
Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10
11
12
Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
PTV AG
Structure
II
PTV AG
Contents
1
1.6
Managing scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.1
1.6.2
Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1
Network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.1.9
2.1.10
2.1.11
2.1.12
2.1.13
2.1.14
2.1.15
2.1.16
2.1.17
2.1.18
2.1.19
2.1.20
2.1.21
2.1.22
2.2
34
37
40
45
46
46
48
51
52
52
54
56
57
57
70
72
74
75
76
77
78
84
PTV AG
III
Contents
2.2.4
2.2.5
2.3
Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
2.3.1
2.3.2
2.3.3
2.3.4
2.4
2.5
3.2
3.3
Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Time series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Demand model structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Person groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Activities, activity pairs, activity chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Demand strata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
IV
Direct attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Indirect attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Time-varying attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Contents
3.4
4.2
4.3
4.4
5.5
228
228
229
277
PTV AG
5.9
5.10
216
218
224
225
5.6
5.7
5.8
309
309
310
311
312
314
Contents
5.11
5.12
5.13
TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376
5.17.1
5.17.2
5.17.3
5.17.4
5.17.5
5.17.6
5.17.7
5.17.8
VI
5.17
5.16
Equilibrium_Lohse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
5.14.1
5.14.2
5.14.3
5.14.4
5.15
5.14
PTV AG
Contents
5.18
5.19
389
390
393
397
406
408
410
412
418
5.20
5.21
6.5
6.6
6.7
6.8
453
454
456
459
465
470
471
474
PTV AG
6.10
437
446
447
447
6.9
VII
Contents
6.10.2
6.10.3
6.10.4
6.10.5
6.10.6
6.10.7
6.10.8
6.11
6.12
7.2
7.3
7.4
7.5
7.6
VIII
PTV AG
Contents
8.2
8.3
10.3
10.4
10.5
10.6
Intersect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Processing the network display with graphic objects . . . . . . . . . . . . . . . . . . . . . 688
10.5.1
10.5.2
10.5.3
10.5.4
11
10
Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
688
688
689
694
11.2
PTV AG
699
701
705
706
711
Isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
11.2.1
11.2.2
11.2.3
11.3
IX
Contents
12
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .726
12.1.1
12.1.2
12.1.3
12.1.4
12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
12.10
12.11
12.12
12.13
Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .733
Categorized display with attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .736
Labeling with tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .740
Labeling with charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .741
Turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743
Desire lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744
Stop catchment areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .746
PuT transfer relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .748
PuT connections and transfer flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .749
Lane allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .750
2D display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .752
Schematic line diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .754
12.13.1
12.13.2
12.13.3
12.13.4
Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
PTV AG
PTV AG
The demand model contains travel demand data. Information on the demand within a
planning area is required for the analysis of transportation networks. Demand matrices can
only partially be created based on survey data. This is why mathematical models are used
to reproduce real demand ratios. They allow you to calculate the traffic flows between
zones of the planning area based on structure and behavior data, the spatial utilization
structure and the transport system. Visum includes the Standard 4-step model, the EVA
model, and the Tour-based model. Thus you can create your own travel demand matrices
in the program (see "Demand model" on page 119).
The network model stores the transport supply-side. The network model consists of traffic
zones, nodes, public transport stops, links representing roads and railway tracks, and the
public transport lines with their timetables. Transport supply data can be visualized with
Visum and edited interactively with different methods.
The impact models use input data provided by the network model and the demand model.
Visum offers several impact models for analysis and evaluation of transport supply. The
user model simulates the travel behavior of public transport passengers and car drivers
(see "User model PuT" on page 429 and "User model PrT" on page 211). It calculates
traffic volumes and service skims (such as journey time or number of transfers). An
operator model determines operational indicators of a public transport service, like service
kilometers, service hours, number of vehicles or operating costs (see "Operator model
PuT" on page 521). Revenues by ticket type derived from the demand data allow line
related revenue estimates for a line costing calculation. An environmental impact model
offers several methods to assess the impacts of motorized private traffic on the
environment (see "Environmental impact model and HBEFA" on page 651).
Visum displays the calculation results in graphical and tabular form and allows you to
perform various graphical analyses of the results. You can e.g. display and analyze routes
and connections per OD pair, flow bundles, isochrones and turning volumes at nodes.
Indicators such as journey time, number of transfers, service frequency, and many more
are computed as skim matrices.
You can compare different versions using the version comparison or network merge
functionalities. You can further exchange the changes made to your model via model
transfer files.
Transport model
Demand model
Network model
Impact model
contains methods to determine impacts:
User model:
assignment, calculation of service indicators,
Operator model:
number of vehicles, line costing, revenues,
Environmental model:
pollution and noise emissions.
Results
Listings and statistics
Indicator matrices
Graphical analysis
Plots
Like all models, a transportation represents an abstraction of the real world. The aim of the
modeling process is system analysis, forecasting and model-based preparation for decisions
taken in the real world.
In the following, especially the network data model and the procedures available in Visum are
described and explained in a simple way.
1.1
PTV AG
Zones (also called traffic cells) describe areas with a particular land use and their location
in the network (for example residential areas, commercial areas, shopping centers,
schools). They are origin and destination of trips within the transport network, which means
zones and the transport network are connected through connectors.
Nodes are objects which define the position of intersections in the link network and of
switches in the railway network. They are start and end points of links.
Links connect nodes and thus describe the rail and road infrastructure. A link has a
particular direction, so that the opposite link represents a separate network object.
Turns indicate which turning movements are permitted at a node and store the turning time
penalty.
Connectors connect zones to the link network. They represent the access and egress
distances to be covered between a zones center of gravity and the nodes/stops of the
network.
Stops are subdivided into stop areas and stop points served by lines where passengers
may board or alight.
Lines which are listed with a name in a timetable usually go into both directions. A line can
consist of several line variants, so-called line routes which differ for example, in their route
courses. Line routes describe the spatial course of line services, for each line route one or
several time profiles can be defined.
Territories are network objects, which can be used for example, to model districts or
counties. Based on a polygon which defines the territorial border, PrT and PuT indicators
for regular or single PuT line services can precisely be accounted for each territory.
Every network object is described by its attributes. Attributes can be subdivided as follows:
For all network object types, users can define additional so-called user-defined attributes. They
can contain additional information or temporary values which are like "normal" attributes
presented in lists and graphically, and are available as filter criteria. Because these are not
required to understand the basics, no further detail is required at this point.
The integrated network model distinguishes between transport systems of the private transport
and the public transport type. PrT transport systems depend on permissible speed and link
capacity. PuT transport systems are bound to a timetable.
1.2
PTV AG
A PrT demand matrix element has the unit car trips, a PuT demand matrix element has the
unit passenger trips (do not mistake with the vehicle journey of a PuT line). It contains the
number of travel demand from a traffic zone i to a traffic zone j.
A travel demand matrix refers to a time interval (analysis time interval) and thus only
contains trips which depart within the time interval.
Trips of a demand matrix can refer to the total transport system, to partial transport systems
(for example pedestrian, bicycle, PuT, car), to person groups (for example employed,
students, retired persons) or to purposes (for example commuting, shopping, leisure).
A demand matrix is assigned to exactly one demand segment. A demand segment
describes a group of road users with homogeneous travel behavior.
Travel demand can be divided into surveyed and calculated demand as well as into today's
and future demand.
Surveyed travel demand describes the number of trips and the trip distribution within a fixed
time interval for an existing transport supply system. It represents a snapshot of the current
traffic situation and cannot be reproduced again practically. An exact survey of today's
current travel demand in an area of interest is not possible in practice because all travelers
would have to be interviewed at the same time. For this reason, only a representative, random
sample of travelers is interviewed to determine travel demand for the purposes of
transportation planning. From this survey a matrix of today's travel demand is then deducted.
It represents the travel demand for the existing supply system.
Calculated travel demand contains assumptions about the number of trips and trip
distribution. To calculate travel demand, demand models are used which, for example,
differentiate between the three steps of Trip generation, Trip distribution and Mode choice. The
calculated travel demand can be designated differently depending on the used input data.
Calculated travel demand is called today's travel demand if the input of the demand
calculation is today's land use structure, today's population and economic structure, and
today's transport supply system.
Forecasted travel demand is based on data on future land use, future population and
economic structure and the future transport supply system.
An overview of the procedures for determining travel demand can be found in Leutzbach et al.
(1988).
Within Visum all 4 stages of the classical traffic model (4-step model) can be calculated,
besides traffic assignment (choice and volume of the route to get from origin zone to
destination zone) the other three steps Trip generation, trip distribution and Mode choice
(choice of means of transport), too.
In the first step of the classical model, Trip generation, the production and attraction (origin and
destination traffic) of each zone is determined on the basis of socio-demographic data (for
example, number of inhabitants and jobs). These production and attraction values define the
totals of the total demand matrix, which is determined by means of relevant skim data (for
example, journey times, fares etc.) in the second step, Trip distribution. In the third step the
total demand matrix is distributed onto the different traffic modes (for example, PrT, PuT) on
the basis of mode-specific skims. In a fourth step the resulting mode-dependent demand
matrices can be assigned to the supply (Visum network) by means of the PrT and PuT
assignment procedures in order to obtain link volumes and new skims. This skim data can
again be used as inputs for trip distribution or mode choice of a new demand calculation. The
Go to the procedure function allows you to iterate the calculations until a convergence
criterion concerning link volumes or matrix values is satisfied.
Visum contains three alternative calculation models for the demand modeling.
PTV AG
The Standard 4-step model is based on North American practice for aggregated demand
models (see "Standard 4-step model" on page 126).
The EVA model is another aggregated demand model for passenger demand. It differs
from the Standard-4-Step Model by a simultaneous trip distribution and mode choice as
well as by its particular method of balancing the differences between origin and destination
traffic (see "EVA model for passenger demand" on page 132).
When calculating demand matrices, the Tour-based model (traffic in cities generation
model) takes into consideration activity chains which homogenous-behavior user groups
(for example employees with or without a car, pupils, students) perform during the course
of the day (see "Activity chain based model (tour-based model)" on page 161).
The matrix editor integrated in Visum supports matrix processing and provides a gravity model.
The calculation models are based on specific Visum demand objects describing the
characteristics of trip purposes and road users. Person groups combine road users featuring
comparable mobility behavior to groups. The break-down of the population into person groups
may be based on their job status (employed, students, retired persons) and (optionally) their
car ownership (with/without car). Activities are activities or locations of a person in the course
of the day which are not traffic related (work, school, home). Activity pairs describe transitions
between two activities and may imply trips from one place to the other (home - work, home school). They are then called trip purposes.
A demand stratum combines one or several person groups with an activity. Almost all
calculations of the first three stages of the model are carried through separately for each
demand stratum and their results are stored separately for a better illustration and verification.
The resulting demand matrices always have the unit [persons].
By aggregating the demand strata to demand segments parts of the demand jointly to be
assigned are combined prior to the fourth stage, which is the assignment. Hereby, the PrT
demand matrices are converted into the [Vehicles] unit by dividing the demand stratum
matrices by the occupancy rate of the respective transport system.
A time series by percentage specifies the proportion of trips with the desired departure time
within the respective time interval. Demand distribution curves can cover more than 24 hours
if a weekly or annual calendar is used. An equal distribution of travel demand during the
observed time period is assumed as default. Instead of this default, a user-defined demand
distribution curve can be specified for the entire matrix. This user-defined demand distribution
PTV AG
curve can be overwritten again for selected pairs of origin-destination zone types with specific
demand distribution curves. In this way, it is possible to specify deviating distribution curves for
zones, for example, with known structural features (for example purely residential or
commercial areas) that reflect the different traffic loads in one direction (illustration 2) at certain
times of the day for journeys between home and work.
%
40
35
30
25
20
15
10
5
0
7:00
7:30
8:00
8:30
9:00
Illustration 2: Example of the temporal distribution of travel demand by four intervals of 30 minutes
A time series of demand matrices allocates a separate matrix to each time interval which
contains the demand with the desired departure time in the respective time interval. It should
be used if for example matrices on an hourly basis already exist based on a trip generation
model. Contrasting time series, here the time dependent course of the demand can be freely
selected for each matrix item. However, the data entry expenditure and the memory
requirements are higher accordingly, because several complete matrices are supplied.
1.3
PTV AG
1.4
Analysis of results
Transportation demand and the results of the impact models can be evaluated and output
under different aspects. The following functionalities are available (see "Tabular and graphical
display" on page 725 and "Interactive analyses" on page 697).
PTV AG
Flow bundles, which filter demand segment-specific paths traversing network objects
selected by the user (nodes, links, zones, stop points, stop areas and stops)
Flow bundles for the analysis of network volumes according to traffic types (origin,
destination, through, external, internal and bypassing internal trips)
Turn volumes, which display PrT turning flows at intersections
Isochrones for classifying the reachability of network objects and for comparing PuT
journey times and PrT travel times
Graphical shortest path search for the PrT, which visualizes the shortest path between
zones or nodes in the network for a PrT transport system
Graphical shortest path search for the PuT, which visualizes the shortest path between
zones, nodes or stop areas. The shortest paths can be based on transport systems or
determined on the basis of the timetable provided in Visum
Skim matrices describe different properties for each OD pair from origin zone to a
destination zone in the traffic model. Each skim (such as the in-vehicle-time) is derived from
the properties of all paths found from origin zone to a destination zone
7
1.5
Lists for all network object types, which allow a tabular display of all attribute values of a
network object
Display of bars, charts and tables on the map (for example to visualize the link volumes)
Statistics for the assignment analysis and the analysis of the assignment quality. This is
how the coefficient of determination R2 can be determined approximately between the
volumes calculated in the assignment and the observed values, and the assignment model
can continue to be calibrated.
Column charts for the display of time series (for example link volumes in the course of the
day)
Graphic and tabular display of vehicle journeys in the Timetable editor. This is how
volumes from the assignment can be displayed as bars for each journey.
Comparing and transferring networks (Network merge, Version comparison, Model
transfer files)
In contrast to the first variant, which includes the transfer of selected attributes into the opened
version, the second variant builds relations to the loaded network in the background. This
means that all attributes of the loaded network are visible in the opened version. Additionally to
the existing relations to other objects (for a node, for instance, to the in-links, out-links, turns
etc.) another relation to the loaded network will appear in the attribute selection windows.
The unique feature of the network merge is the unification of different data.
The following table gives an overview of the essential differences between network merge and
version comparison. In most cases you will be working with the new version comparison in
future.
Version comparison
PTV AG
Version comparison
Not updatable
1.5.1
PTV AG
PTV AG
This includes indirect active attributes. The link filter criterion can only be evaluated in the
opened network.
Value of network B
VolVehPrT,B(AP)
VolVehPrT,-B(AP)
VolVehPrT,B-(AP)
VolVehPrT,-B%(AP)
VolVehPrT,B-%(AP)
VolVehPrT,B,Min(AP)
VolVehPrT,B,Max(AP)
Table 1: Additional attributes for a compared numerical attribute after version comparison
The values of the additionally read attributes cannot be modified manually. However, all
calculated values, i.e. all values except the value of network B, are recalculated automatically
as soon as the corresponding values of network A are modified.
With the version file containing the version comparison you can continue to use all Visum
functions, including calculations. The comparisons read can be saved together with the
version.
The additionally read attributes can be displayed and evaluated, as required (see "Analysis of
results" on page 7).
PTV AG
11
12
PTV AG
Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference are displayed. "Verscomp" is the name of the version comparison.
Above all, you can convert the attribute values of the additionally read version easily into userdefined attributes so that they are still available after the version comparison has been
terminated.
The reference to the additionally read data is not updated automatically, but can be updated, if
required. Thus, for example, you can read the same version file at different times, thus tracing
the modifications.
The reference to the additionally read data can be dropped again at any time.
Special cases
If the compared versions do not contain the same network objects or attributes, the following
will happen (opened version: A, additionally read version: B)
PTV AG
13
Special cases
Objects are generally identified via their key. Using the opened network version (network A),
you can create a relation to the object in the comparison network (network B). If the compared
versions do not contain the same network objects or attributes, the following rules apply:
1.5.2
If an object exists in B only, access to this object is only provided via indirect attributes (e.g.
a node existing in B only belongs to all nodes in B - the latter is a relation within network B,
to which a relation from network A refers).
If an object exists in A only, the attribute values of the relation to B are empty.
If an attribute has different sub-attribute variants in A and B, then indirect attributes provide
access to the variants which exist only in B. If there is no sub-attribute variant in B, then the
attribute value calculated for the relation is empty.
Network merge
The network merge function provides for the comparison of two transport networks and the
output of their differences. For network merge any networks can be combined with each other.
After that, however, only evaluation functions are available, hardly any editing functions.
14
PTV AG
PTV AG
15
In no network: The object exists only in the merge network and has no attribute values.
Example: A turn between a link of network 1 and a link of network 2. Such objects are
created in rare cases, so that the merge network is a permissible Visum network. They
have no real equivalent and no attribute values.
In the merge network, a read-only attribute is created for each network 1 and/or network 2
attribute (Visum attributes and user-defined attributes). This attribute has the following
properties:
The Difference sub-attribute value serves to output the difference and has the following
values.
For numerical attributes, the difference is calculated from Net1 and Net2 data
For strings, "==" is output in case of identical strings, whereas "<>" indicates deviating
strings. Blanks are output for objects which are not part of both original network
versions.
Note: In case of user-defined attributes with identical IDs but different min/max value ranges,
the value range of Net1 will be used. For objects with coordinates, the coordination values are
taken from network 1for the display in the network.
Note: Network merge ignores the following objects and settings:
Junction geometry/control objects
Demand description (neither matrices nor time series)
All path information
Analysis periods and horizons
Filters
Blocks
Graphic parameters
16
PTV AG
The illustration 8 displays the merge network of network 1 (illustration 6) and network 2
(illustration 7).
In the network view of the merge network, you can see that the link at the bottom left of network
2 has a lower speed of about 20 km/h and varies in TSysSet. The link at the bottom right is,
however, identical in both networks.
1.5.3
PTV AG
17
1.6
Managing scenarios
In most Visum applications you create a model of supply (the network) and demand for an area
of investigation. Then you develop several variants of the initial situation and various
scenarios. The variants are then compared and evaluated based on calculation results.
Thereby numerous files (including and excluding calculation results) are created for the
individual variants. You can use the Compare networks function to organize the file contents,
making sure that information is only saved to one storage location (see "Comparing and
transferring networks" on page 8). This allows you to reduce data maintenance when changing
your model. In Visum, scenario management takes care of maintaining all your files.
It provides the following benefits:
1.6.1
18
PTV AG
A project contains all data required to use Visum. It has a unique name and a protocol in which
users can save notes on the project status. Each project is based on a base model which is
also called initial situation, analysis case or null case. It is saved as a version file, the so-called
base version. Just as other supporting files (procedure and graphic parameters, etc.), the base
version is saved to a uniform folder structure for which you can specify the path. All other
project information, specifically definitions of modifications and scenarios, are saved to the
Visum project database, a database file that is saved to the same folder structure.
A modification is a grouping of changes that belong together content-wise and are made to the
supply or demand. A modification could refer to the building of a by-pass road and include
several new links, changes to existing links and to nodes. Another modification might describe
the introduction of a speed limit on certain roads. It would consist of changing a single attribute
(v0) for several network links. Modifications may also refer to PuT supply, for example
describing line route or headway changes as well as new stops. On the demand side, typical
modifications include changes to data on the socio-demographic structure, i.e. changes to the
zone attributes. Modifications may also change matrix content, e.g. externally specified
matrices for through trips. The number of modifications is not limited per project. Modifications
may also be based upon other modifications, e.g. one describes the construction of a by-pass
road and another its extension by a second lane per direction. The second modification only
changes the attributes Capacity PrT and Number of lanes for those links that were added
through the first modification of the base model. When creating a modification, you specify the
other modification it is based on.
A scenario corresponds to a variant you want to investigate. It is often also called planned
case. Each scenario is based on the base version of the project and includes one or several
modifications. The distinction between modification and scenario has the advantage that you
can easily investigate all combinations of several measures. Let us assume your project is
about the construction of a by-pass road. At the same time it is suggested to introduce a speed
limit in the city center for traffic calming. Define two modifications for your project: M1 for the
by-pass road and M2 for the speed limit. Using these two modifications, you can easily define
four scenarios without any additional modeling effort:
PTV AG
19
Scenario code
Meaning
Base version
M1
S0
B
M2
Null case
BS
Should your customer additionally ask for an investigation of the demand variant for 2020, you
can change your project with a minimum effort. First define a modification M3 for the second
demand variant. Then duplicate all previously created scenarios and in the copy additionally
activate M3. Now you are ready to calculate the model for all eight scenarios.
Scenario code
Meaning
Base version
M1
M2
M3
S0
Null case
BS
S0_2020
B_2020
S_2020
BS_2020
When combining scenarios based on modifications, make sure that the modifications do not
contain any contradictory information on the value of the same attributes. Visum can account
for this and check whether it is possible to combine two modifications. In few cases, you might
want modifications to overlap. Example: M1 describes the extension of a link sequence to two
lanes. M2 includes a third lane for some of the same links. For some links, M1 and M2 contain
contradictory information on the attribute Number of lanes. If you first apply M1 and then M2,
you will still achieve the desired result: for some links the attribute Number of lanes will be
overwritten twice. This way you need not define a copy of M1 without the links mentioned in the
original M1. In these cases, it is important that you can specify in which sequence the
modifications are applied. To avoid conflicts when combining scenarios, you can also specify
which scenarios must not and which ones may be combined when defining the modification.
1.6.2
20
PTV AG
All steps are carried out in the Project view. The Project view is a modeless window and
remains open while you are working on the project. It provides an overview of all modifications,
scenarios and other parts of the project.
You can find a detailed description on how to use the Project view in the User Manual (see
User Manual, Chpt. 1.13, page 115). In the following, you will find useful information on each
step.
1.6.2.1
When working on a new project, you first specify the version file of the base model. In most
cases, the version file already exists. Especially, if you have already started working on the
project without using scenario management. Select the existing version file, when creating the
project. Visum stores a copy of this version file with a different name to the project directory
structure. This copy is now used in scenario management. The original version file is not
touched. Alternatively, you can use the model currently loaded as the base version. If you
select this option just after project start, the model will still be empty and you can create your
base model from scratch. All options are equally suitable to create a base model, no matter
whether you create the model within the context of scenario management or of a project. The
project becomes important once you define modifications and scenarios.
PTV AG
21
1.6.2.2
Defining modifications
When adding a new modification to your project, you assign a unique name and a project
description, if required. You further specify any existing modifications your new modification
depends on and the ones it cannot be combined with. Visum then loads the base version and
all its modifications. A floating window informs you that all changes you now make to the model
will be included in the new modification.
Now you can use all editing functions to change the model. Data processing, however, is
disabled in the Project view. After making all your changes, click the Finish button in the
floating window. Visum calculates the differences between the current model and the base
model. These differences are saved as content of the new modification.
Of course you can add modifications during any stage of your project. You can also change
modifications later on. You can further have the content of modifications displayed any time.
If you are working on an extensive project, you might want to assign the creation of
modifications to several users. To do so, proceed as follows:
This procedure allows you to use files centrally under scenario management, although they
were created decentrally by several users.
Note: If several users are working on creating model transfer files, they might use the same
code for a new network object, although the content of their objects differs. Visum will
recognize these code conflicts when you use the model transfer files in scenario
management. So, if the same code has been assigned twice, one of the objects is
automatically assigned a new, unique code.
22
PTV AG
1.6.2.3
After you have defined modifications for your project, you can combine them to create
scenarios. Scenarios are also assigned a unique name and a description. For each scenario,
you can choose several modifications that are applied to the base version. If you do not select
a modification, the scenario simply corresponds to the base model. If you select several
modifications, Visum applies them according to the sequence in your list of modifications. Then
check to make sure the modifications you selected can be combined. You can also remove or
add modifications to a scenario later on.
Under Project view, you can open any scenario in the entry view or the results view. Choose
the entry view to check the scenario or to perform an interactive analysis, e.g. isochrones
calculation or shortest path search. Avoid editing the model in this view, as your changes
will then be lost the next time you open the scenario. Instead, always make your changes
to the base version or the modifications. If you save a scenario as a version file, your version
file will have no connection to scenario management. However, you can use it to pass on the
entry data of a certain scenario to other users. The results view is described further below.
1.6.2.4
In most cases you will want to apply the same model calculation to several or all scenarios in
order to compare the results. By default, Visum uses the procedure parameters of the base
version to calculate a scenario. To specify the calculation sequence, in the Project view, click
the Edit base version button. Then, under Procedure sequence, choose the sequence in
which you want the operations performed.
Some operations require reading or writing access to files, e.g. to externally saved skim
matrices or filter files. Under Project view, you specify whether Visum has access to one file for
the entire project or to file copies of the respective scenarios. You can specify this for all files
of a certain type or globally for the entire project.
However, sometimes you might want to use a different than the default calculation sequence
for a scenario, e.g. when changing the procedure parameters. If you do not wish to change the
network or demand in a scenario, but the Value of Time, change the fare or toll coefficient in
the impedance definition. These parameters are not taken into account for difference
calculation when you create modifications. Instead change the procedure parameters of the
base version and add the edited procedure parameters file to the project. Then close the base
version without saving the changes. Assign the scenario the procedure parameters saved to
the project. This setting has a higher priority than the procedure parameters of the base
version.
1.6.2.5
Calculating scenarios
After specifying the calculation sequence for the project, assign it to all or part of the scenarios
in the Project view. If you select several scenarios, Visum will automatically load the scenarios
in the sequence selected and will perform the respective calculations. This function is very
helpful if you have to carry out numerous calculations, e.g. overnight, and no interaction is
required. Moreover, you can distribute scenario calculations across multiple computers to
exploit the computing power available (see "Distributing scenario calculations across multiple
computers" on page 24). After all calculations have been performed, Visum saves the model
PTV AG
23
state with all results to a version file in the project directory. Saving the results of each scenario
to a separate version file might seem like a "disruption" of scenario management, but this is the
only way to save the many results (e.g. assignment results) in a compact form.
In the Project view, the scenarios for which calculations have been performed are marked
"calculated". If after scenario calculation you change the base version, its modifications, the
calculation sequence or the number of modifications, Visum will reset the status to "not
calculated". The results version file then still exists, but the results might no longer be up-todate and you should have the calculation performed again.
1.6.2.6
You can distribute scenario calculations across multiple computers to calculate multiple
scenarios simultaneously and obtain the results earlier for analysis purposes. You do not
require any additional system or other software, provided that the add-on module is licensed.
Then you can use all software belonging to the license group installation of Visum.
Workstations used during the day for project work, e.g., can be used at night for extensive,
automated scenario calculations (see User Manual, Chpt. 1.13.7.2, page 130).
24
The computers must have compatible Visum versions installed (with the same binary
version, e.g. 13.00-xx).
All computers must be licensed for the add-on modules required for calculation and for an
adequate network size.
If you are using Python scripts or add-ins, the respective Python version and add-ins must
be installed on the computers.
Depending on the use case, ensure that additional resources, e.g. HBEFA data files or
user-defined VD functions, are available on the computers. Project-specific data is
automatically copied to the respective computers by Visum.
Do not specify absolute paths for additional files, e.g. matrices or scripts, within the
procedure used for scenario calculation. On the compute node, the files might not be
available under the path specified. Only specify project folders available within scenario
management.
Ensure the same program options are selected on each computer. This is not done
automatically.
The computers must be connected via the network. If required, in the firewall of the
computers, open the ports used for communication and assign the corresponding user
rights. The ports can be freely selected. The compute nodes must be located in the same
subnetwork as Visum to be found automatically by the program. If this is not the case, you
can still use them for distributed calculation. However, you need to enter the computer
addresses manually.
The PTV Visum Scenario Calculation Server of the respective installation must run on
the compute node. Only if this software is run, can the calculation orders be carried out. The
Scenario calculation server is automatically installed with Visum. It is not necessary to start
Visum on the compute node.
PTV AG
The Scenario calculation server is not a Windows service. The software is only run when a
user logs on to the computer.
Besides the number of Visum instances and cores you want to use, you can specify a Base
directoryto which the scenario data is saved during the calculation process. In the Service
address section, specify the name and port under which the compute node shall be available.
You can use the same computer to simultaneously run multiple instances of the Scenario
calculation server for different Visum installations, e.g. different service pack versions. To do
so, for each installation, you must start the Scenario calculation server and configure a different
port. Each server started uses the respective Visum version located in its installation folder.
The Base address of the service box contains the URL based on these settings. If the
compute node is not automatically found by the controlling Visum version, the URL can be
used for manual configuration. You can select the option Start Visum Scenario Calculation
Server when logging in to start the server automatically, as soon as a user logs on to the
system.
PTV AG
25
1.6.2.7
You need not open the results version file in the Windows file system. In the Project view,
simply open the respective scenario in the results view. Visum then loads and displays the
resulting version file and all functions are available for analysis of the results for this scenario.
If you want to compare two or several scenarios with each other, highlight them in the Project
view. Then specify one of them as the master scenario. In the master scenario, open the
version comparison. Visum shows a comparison of the master scenario with each of the other
scenarios. Version comparison works the same way when used outside scenario management
(see "Comparing version files" on page 9). In the course of the project, you are likely to use
version comparison many times. You can combine the parameters of version comparison
(optionally also graphic parameters and filter settings) to a so-called comparison pattern and
save it to the project. Then you can open version comparison in the Project view, without
having to change the settings again each time.
You can also compare all scenarios at a glance by using selected, network code numbers. You
specify the code number in the Basic settings tab of the Project view. They can then be
selected as columns in the Scenarios tab. You can use them to create a table with the
scenarios as rows and the columns containing the code numbers.
26
PTV AG
You can use the Copy & Paste command to copy this table to a project report.
PTV AG
27
28
PTV AG
Network model
The supply data of the transport network are described in a network model consisting of
various network objects.
Subjects
2.1
Network objects
Spatial and temporal correlations in Visum
Attributes
Subnetwork generator
The surface data model in Visum
Network objects
The network model differentiates basic network objects such as nodes and links, which
illustrate a network structure (see "Basic network objects of a transport network" on page 29).
Additionally, there are network objects which are only used for modeling PuT networks (see
"PuT network objects of a transport network" on page 31) and general network objects, which
do not have to have any relevance to traffic and especially no influence on procedure
calculations (see "General network objects" on page 33).
Network object
Description
Transport system
(TSys)
Mode
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).
PTV AG
29
Network object
Turn
Turn standard
Link
Link type
Zone
Connector
Main node
Main turn
Main zone
Territory
Description
Turns specify which movements are permitted at a node, that is, whether
turning at a node from one link to another link is permitted.
For PrT transport systems, turning time penalties and capacities can be
specified which describe the influence of the intersection on the performance of
the network.
Turning prohibitions are taken into consideration as follows:
For public transport systems in the construction of a line route
For private transport systems in a route search
Turn standards are templates used to create new turns with default values for
the attributes Time penalty and Capacity PrT. Which turn standard is used for
the allocation of turn attributes, depends on the node type, the turn type and the
flow hierarchy.
Links connect nodes and thus describe the structure of the road and rail
network. A link is a directed edge, i.e. both directions of a link are independent
network objects and thus, can have different attributes.
Link types are used as a template when inserting new links. When inserting a
link, a link type has to be specified. The link then takes over the attributes
permitted transport systems (TSysSet), Capacity PrT, velocities (v0-PrT,
vMin-PrT, vMax-PrT und vDef-PuT), Number of lanes and the link rank as
default values.
Zones (traffic cells) describe the positions of utilities in the network (for
example, residential areas, commercial areas, shopping centers, schools).
They are origins and destinations of movements within the transport network,
which means of traffic. Zones and the transport network are connected through
connectors.
Connectors connect zones to the link network. They represent the distance to
be covered between a zones center of gravity and the connector nodes. For
public transport demand, the zone has to be connected via a stop area with
stop(s) allocated to a node.
Several nodes can be aggregated to one main node. Each node is only allowed
to be part of a main node. Using main nodes is useful, if the Visum network is
strongly disaggregated and lanes are available as individual links, for example,
and intersections therefore consist of several nodes (this situation can occur
when working with navigation networks in Visum).
Main turns are created when using main nodes. Each movement via the main
node is represented by a main turn. Main turns possess the same attributes as
turns. In the assignment, the main turn replaces the node turn, which has the
effect that only one turn penalty flows into the assignment for each main turn.
Main zones group multiple zones and allow aggregated evaluations. A main
zone can represent a county for example, which has multiple communities as
traffic cells.
Territories are network objects, which can be used for example, to illustrate
districts or counties. Based on a polygon which defines the territorial border, PrT
and PuT indicators can be precisely accounted for each zone (for example the
driven service kilometers within a zone).
30
PTV AG
Network object
Description
OD pair
OD pairs exist between all zones of the network. The values in skim matrices
and demand matrices (see "Matrices" on page 120) refer to one OD pair each.
Compared to the other network objects, you cannot edit OD pairs interactively
in the network editor, but you can filter OD pairs and display them graphically.
For each OD pair you can select the skim matrix values, the demand matrix
values and the direct distance as attributes.
Path
For assignment calculation, paths are found between the origin and destination
zone, and their volume is calculated. Paths are therefore the central result of
the assignment procedure. In PrT, the user can manually edit paths. This is how
the assignment results could be manually imported to Visum or the Visum
assignment results could be adjusted manually. Both the path volumes and the
course of the path can be edited.
Valid day
Valid day is a freely definable set of days of the calendar used. If a weekly
calendar is used, a valid day may comprise the days from Monday to Sunday
(e.g. "Monday to Friday"). If an annual calendar is used, any individual days can
be selected within the validity period. If no calendar is used, there is only the
valid day "daily". It is then not possible to create new valid days.
In PuT: a valid day can be assigned to each vehicle journey section.
In PrT: in the Dynamic stochastic assignment and DUE, traffic supply can be
time-varying. Time-varying attributes are used (see "Time-varying attributes" on
page 105). When using a calendar, valid days can be specified for these timevarying attributes, on which they should have an effect.
Network object
Description
Stop
A stop combines stop areas and therefore also stop points. To ensure that a
stop can be localized and displayed in graphical form, it has a coordinate, but it
is not assigned directly to a network node or link.
Stop area
Stop point
A stop area divides a stop into areas. It can, for example, represent a train
station platform, intersections with multiple stop points or a station concourse.
A stop area has the following properties:
It is assigned exactly one stop.
It can comprise multiple stop points.
It can be assigned a network node. This allows a PuT connection of a zone
to the road network.
The stop areas are connected with each other with a transfer walk matrix
(walk times between the stop areas). It contains the transfer walk time of
each PuTWalk for example.
A stop point is the location, where PuT lines stop for passenger boarding. A
stop point can either lie on a node or on a link (link stop point).
A stop point at a node can be served by all lines which pass the node.
A stop point on a link can only be served by lines which pass this link. A
detailed direction modeling based on masts is optionally possible with link
stop points. Alternatively, undirected stop points can also be inserted on
links.
PTV AG
31
Network object
Line
Description
Lines combine all line routes and timetables of a line. A line has at least one line
route and this at least one time profile. For line variant modeling, several line
routes can be specified for the line, and several time profiles can be specified
for each line route.
Line route
Line routes describe the spatial course of the line route for one direction as a
sequence of route points. Route points are selected points in the line routes,
namely all stops and possibly traversed nodes. The first and last route point of
a line route must be stop points that are open for the transport system of the
line.
Time profile
Time profiles describe the length of travel times between stop points of a line
route and if boarding or alighting is allowed at the stop points of the line route.
Since it is possible to create several time profiles per line route, you can model,
for example, that the travel times of a tram between stop points are longer
during evening rush hours than during the rest of the day. Time profiles are
allocated at vehicle journey level so that each vehicle journey can be allocated
a different time profile.
Vehicle journey
Vehicle journeys (also called journeys only) are the basic objects to describe
the timetable. Each vehicle journey has exactly one time profile. In most cases
all vehicle journeys of a line route use the same time profile, if this does not vary
depending on the time of day.
Vehicle journey section Vehicle journey sections (also called journey sections) are used to sub-divide a
vehicle journey. You can define different valid days and different vehicle
combinations for the individual vehicle journey sections of a vehicle journey.
This is how you can achieve, that a train travels on days with high saturation
with a vehicle combination, which has more coaches attached. Furthermore,
you can specify different start and end points for each vehicle journey section,
and therefore achieve for example, that the additional coaches are only
attached to one part of the line route course.
Main line
System route
Main lines are used to aggregate several lines and evaluations (such as for PuT
operating indicators) on this aggregation level. Aggregation can also be carried
out via lines with different transport systems.
A system route describes the in-vehicle time and the spatial course between
two stop points. Compared to the line route, it is independent of the affiliation to
a line or even a concrete vehicle journey. System routes with their path and invehicle-time information are used as a template for the efficient digitalization of
line routes and for setting in-vehicle-times in the time profile. System routes are
optional network objects, therefore not mandatory when creating a PuT model.
PuT operators
You can assign an operator to each vehicle journey section. When working with
the operator model, you can evaluate PuT operating indicators per operator
(see "Operator model PuT" on page 521). Furthermore, you can assign each
operator cost values for depreciations and running costs, and then evaluate
operator costs referring to different network objects.
Vehicle combination
You can optionally assign each vehicle journey section a vehicle combination.
To a vehicle combination you can allocate time and distance dependent cost
rates for vehicle journeys and empty trips, and cost rates for the layover in the
depot and the stand time. These cost rates are applied within the operator
model (see "Operator model PuT" on page 521).
32
PTV AG
Network object
Description
Vehicle unit
A vehicle combination consists of one or more vehicle units. This is how you
can compose a vehicle combination Intercity out of several vehicle units
Coach, for example. For each you can specify the number of seats and total
seats. Furthermore, you can assign time and distance dependent cost rates for
vehicle journeys and empty trips, and cost rates for the layover in the depot and
stand time. You can also define a fixed cost rate per vehicle. This allows much
differentiated modeling of your vehicle pool.
Block version
In Visum multiple line blocking results can be kept simultaneously. These are
saved in so-called block versions. This is how alternative plans with different
parameter settings can be compared with each other. In the model, for example
one block version can be kept where interlining is allowed, and another block
version where it is not allowed.
Each block is composed of individual sections, which are called block items.
Each block item is of a special type (block item type). By default, Visum
provides the block item types vehicle journey, empty trip, layover time, and
stand. You can also create user-defined block item types and include these
manually in your blocks (for example for maintenance or wash).
Ticket type
If revenues are modeled with a fare model, the ticket type creates the basis for
the fare calculation of a connection. Basic fares and transport system
dependent supplements can be defined.
Fare zone
For revenue calculation with fare model and zone-based fare, fare zones are
used to calculate the fare of a connection. For the zone-based fare this
complies with the number of traversed fare zones. To determine the number of
traversed fare zones, stops are assigned to the fare zones.
PuT coordination group This network object is only relevant for headway-based assignment. If there are
two lines for example, which complement each other on a common section of
the route course to a headway interval half the length, we speak of
coordination. The coordination group combines two or more time profiles over
a common section of the line courses. If two or more time profiles were
coordinated via a route section, they behave like a time profile with a
corresponding increased frequency on this section. The random variable,
which illustrates the waiting time within headway-based assignment, thus is
reduced to the coordinated section.
Table 5: PuT network objects of a transport network
Network object
Count location
Description
Points of Interest are user-defined network objects with a spatial reference, e.g.
parking facilities, pre-emption points for AVLS (automatic vehicle location
systems) or SCJ controllers in public transport. POIs are used to display special
land uses such as restaurants or hotels, for data management as well as for
reachability analyses.
A count location is an independent network object allocated to a link by
direction. Count locations serve for data management and display of counted
link data.
PTV AG
33
Network object
Description
Detector
Detectors are optional network objects of the count locations add-on. They are
used for lane-based management of counted data and for signal control
modeling.
Toll system
Toll systems are optional network objects which can be used to integrate toll
zones into the network model. For the TRIBUT procedure, they are the basis for
the calculation of road tolls.
GIS objects (GIS = geographic information system) extend the network model
by special layers which are directly incorporated from GIS ArcGIS and can be
linked with the Visum network data via blending features. The objects are only
available during the connection with a Personal Geodatabase (PGD).
GIS object
Screenline
Network processing modifies the properties of the transport network which produces different
indicator values and assignment results.
2.1.1
Priv.TSys2
(e.g. Car)
HGV
Car
Publ.TSys1
(e.g. Bus)
Park&Ride
(Car, Bus, Tram)
Publ.TSys2
(e.g. Tram)
Publ.Transport
(Bus+Tram)
Transport systems
Modes
HGV
Carprivate
Carbusiness
P&R
Publ.Transp
Students
Publ.Transp.
Adults
Demand
segments
Matrix
Matrix
Matrix
Matrix
Matrix
Matrix
Demand
matrices
Illustration 10: Connection between transport systems, modes, demand segments and demand matrices
34
PTV AG
2.1.1.1
Transport systems
The transport supply consists of several transport systems. Links, turns and connections can
be attributed subject to the transport system ("transport system-based"). It can be specifically
determined, if a transport system is allowed to traverse one of these network objects or not. For
example, links can only be opened for the transport system Car, but not for the transport
system HGV. Furthermore, the impedance functions (see "Impedance and VD functions" on
page 216) are defined for the assignment transport system dependent.
A transport system has the following properties:
Note: The number of modeled transport systems, modes or demand segments is not limited.
The four types of transport systems are different in the following ways.
PTV AG
PrT
Travel times of a private transport system depend on the following attributes:
Maximum speed of the means of transport for example 100 km/h for HGV
Permitted speed of the traversed link for example 80 km/h
Capacity of the traversed link
PuT
Run times of vehicles of a public transport system and the dwell times at stops are
determined by the timetable.
PuTWalk
This mode serves to model entrance and exit paths for public transport and walking transfer
links between stop points of a stop or several stops. In order to calculate a public transport
assignment, at least one transport system of type PuTWalk must exist. Several transport
systems of type PuTWalk can be defined.
PuTAux
This type describes subordinated PuT transport systems without a specified timetable. It is
suitable for the following use cases.
Modeling lower-ranking public transport (supply systems):
In large networks, for example in train networks, one often does not want to enter the
reachability of long-distance stations by means of a connector, but in instead one wants
to roughly display the available public transport supply. For a simple representation
such as this, it is meaningful to define one or several additional public transport
systems. In this case, the successive public transport supply is only described as a link
network with run times. Line routes and timetables are not used.
Modeling different types of public transport connectors:
A zone is connected to the PuT supply via one or several PuT systems. In many cases,
passengers not only select nearby start stops for their PuT journey that can be reached
on foot, but they also select distant stops that can be reached by bicycle or car
(Park&Ride, Kiss&Ride, Bike&Ride). In order to be better able to model these
alternatives, for connectors it is possible to disable individual transport systems of type
PuTWalk or to define different connector times. Two modes can then be defined for the
PuT assignment: one mode that is only used if the stop is reached on foot and one
mode that can be used if the stop is reached by car or bicycle.
35
Note: Transport systems of type PuTAux are only taken into consideration for the
transport system-based and timetable-based assignment. In headway-based
assignment, however, they are not considered.
The table 7 provides an overview of properties of the transport system types:
TSys type
Description
Example
PrT
Car,
HGV
PuT
PuTAux
PuTWalk
Footpath,
Escalator,
Lift
2.1.1.2
Modes
A mode can include either one private transport system or several public transport systems.
Examples for modes are for example:
HGV mode
Transport system HGV
PuT mode
all PuT transport systems, for example bus, tram, subway
Park & Ride mode
PuT transport systems and transport system PuTAux car
You can define multiple PuT modes. This way it is possible to model that for example longdistance passengers (Mode PuT-Long) may use all public transport systems (e.g. Intercity,
Regional train, Bus) whereas, for example, commuters (Mode PuT-Local) may use only
particular transport systems (Regional train, Bus).
2.1.1.3
Demand segments
A demand segment belongs to exactly one mode. It is the link between transport supply and
transport demand. As several demand segments can be defined for each mode, different types
of demand can be combined in the transport model.
36
PTV AG
Population groups
Employed PrT (car drivers), Employed PuT, Students PuT, etc.
Ticket types
Single trip ticket, monthly pass, etc.
Trip purposes
to work, shopping, home
Vehicle types
Car - diesel, Car - petrol, etc.
To each demand segment a demand matrix is assigned. Assignment results therefore always
exist on the level of a demand segment (for example the volume for the demand segment PuT
pupil transport).
In principle, it is assumed that demand matrices are available in the following units.
PrT
in car units (CarUnits)
PuT
in passenger units
For the calculation of person trips (PrT) from car units, the occupancy rate can be specified for
each demand segment (see User Manual, Chpt. 2.11.3.2, page 243).
For public transport, only the demand segments of one public transport mode can be selected
for assignment calculation (see "User model PuT" on page 429). For modeling more than one
PuT mode (for example PuT-Long, PuT-Local), a separate assignment is required for each
mode, as route search needs to consider different transport systems. For each demand
segment, particular split parameters can be defined (see assignment parameters). This serves
to model for example, deviating tolerance levels towards transfers or of specific fares due to
the tariff (students, employees, pensioners).
2.1.2
PTV AG
37
2.1.2.1
Node
Nodes determine the locations of street junctions and points in the railway network. They are
starting and terminating elements of links, where there are turning relations from one link to
another in PrT or PuT transport systems (see "Turn" on page 38). Optionally, a major flow can
be defined for every node specifying the direction of the flow with the right of way. The major
flow which has the right of way can be determined automatically by Visum from the ranks of the
intersecting links (see "Links" on page 40). Any number of nodes can be incorporated in a main
node (see "Main node" on page 48). Impedances can be modeled for nodes, which then have
an effect on the route search and thus on the assignment results (see "Impedances at node"
on page 226). This is how influential factors on time can be integrated in the assignments,
which a vehicle needs to cross an intersection.
2.1.2.2
Turn
Turns indicate whether turning is permitted at a node and what time penalty has to be
considered for PrT transport systems.
For private transport systems, time penalty and capacity can be specified which describe
the impact of the intersection on the network performance. Turns are considered for PrT
transport systems during assignment.
For public transport systems turning prohibitions are considered during the construction of
a line route and during transport system-based PuT assignment.
Turns representing a change of direction are important for PuT line blocking.
When inserting a link, Visum creates all theoretically possible turns at both nodes of the link
and uses the standard values from the user-defined turn standards.
For example, at a four-way intersection, there is a total of 16 turns (4 right turns, 4 straight
ahead, 4 left turns and 4 U-turns).
Each turn is described by the following elements:
For each turn, the transport systems have to be specified which may use this turn. A turn
differentiates permitted and blocked transport systems.
Permitted PuT
transport systems
Permitted PrT transport The turn can be used for the assignment taking the PrT capacity and the PrT
systems
time penalty into account.
Blocked transport
systems
Prohibited turns
Per default, the following rule applies when you insert a new turn:
38
All turns are open to all transport systems that are allowed on both the "from link" and the
"to link". This also applies to u-turns.
PTV AG
An exception are the PuTWalk transport systems: These are not automatically incorporated
into the transport system set of turns.
2.1.2.3
Turn types
2.1.2.4
Turn standards
Turn standards are templates which assign a newly created turn with values for their attributes
Turn time penalty (t0-PrT) and Capacity. Which turn standard is used to assign attributes of
each turn, conforms to the three following criteria.
For each node, Visum evaluates the rank of the links involved and thus determines a major
flow (see "Link types" on page 41). This automatically determined major flow can be edited
manually. The flow hierarchy describes whether a turn follows this major flow, from this one
into a minor flow, from one minor flow into the major flow or leads from minor flow to minor flow.
These four steps of the flow hierarchy are designated with the symbols from table 8.
Symbol
Right of way
++
+-
-+
--
In combination with node types, turn types and flow hierarchy, you can assign the turns very
differentiated turn times as standard. These turn times can then be considered within the
assignment (see "Impedances at node" on page 226). The illustration 11 shows an example of
turn standards.
PTV AG
39
2.1.2.5
Turns show basically the same correlation between capacity and travel time as links. The only
difference results from the fact that a turn does not have a length and that the travel time t0
therefore comes from the turn time penalty.
The turn time tCur in the loaded network then results from the selected VD function and the
relationship between the current traffic volume q and the capacity qmax:
Input: VD function, for example BPR function from U.S. Bureau of Public Roads
Result: current turn time in the loaded network (1), for example
b
q
t cur = t 0 1 + a ------------------
q max c
(1)
To model turn times which do not depend on capacity, a constant VD function must be chosen.
How the impedance at a turn depends on these parameters in particular, depends on the set
method for impedances at nodes (see "Impedances at node" on page 226).
2.1.3
Links
Links describe roads and railways of the transport network. They connect nodes, which means
intersections in PrT or stop points in PuT. A link is represented as a directed element and is
described by the From Node number and To Node number. Both directions of a link are two
independent objects in the network model, who are assigned the same link number and whose
From Node number and To Node number has been swapped. This means, that you can
attribute both directions of a link differently. For every link, you must specify the permitted
transport systems of PrT and PuT (which are allowed to use the link). This means, that you can
close one of the directions to any traffic and model a one-way road in this way.
40
PTV AG
2.1.3.1
Link types
Visum describes the traffic-related properties of links with link attributes. It also offers the
possibility of dividing links with the same properties into 100 link types, which themselves have
attributes. Each link belongs to a link type via its attribute Type number. The 00 to 99 link types
serve as network classifiers and make it possible to assign type-specific standard values for
the following link attributes.
In principle, the values of the attribute of a link of the assigned link type, is independent. This
means, that you can attribute each link independent of the link type. However, it is
recommended to apply exactly those values of the link type in the link. This is how you will
achieve as consistent as possible modeling of links and modifications to attributes can be
made more easily, because you can change these in the link type and then apply these to the
links (see User Manual, Chpt. 2.14.2, page 276).
For the assignment, each link type can be assigned a capacity restraint function, which thus
applies for all links of this link type (see "Impedance and VD functions" on page 216). This
allows you to apply a different mathematical correlation for the calculation of impedance on non
built up rural roads and built up urban roads.
Major flows
From the rank of the link types of the link which flow into a node, Visum determines a flow
hierarchy with a major flow. This always refers to two different link orientations (see "Network
objects of the junction model" on page 79). The major flow is taken from one of the three
criteria (see "Turn standards" on page 39) to determine the time penalties for the exiting
turning processes from the major flow or from another link. If possible, it should correspond to
the right of way or movement, advantaged through the SC. With this the rank of the link types
indirectly influences the result of the PrT assignment. The illustration 12 shows an example of
determining the flow hierarchy and particularly the major flows.
PTV AG
41
Illustration 12: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red)
Note: In the PuT model, the rank has no influence on the assignment result.
2.1.3.2
The permitted transport systems specify the configuration of a link. The following types can, for
example, occur:
The illustration 13 shows three examples for permitted transport systems on different types of
links.
42
PTV AG
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
Car
Car
HGV
HGV
Bus
Bus
Tram
Tram
PuT-Walk
PuT-Walk
The number of the lanes of a link is entered as an attribute, but also has to be considered for
the capacity (this means that the entered capacity does not refer to one lane, but to all lanes).
A link is always meant for both directions. In order to define a one-way road, close the opposite
direction to all transport systems.
Links which are open to PrT transport systems are taken into account during private
transport assignment.
Links which are open to PuT transport systems are taken into account during the
construction of line routes for public transport lines. PuT assignments (headway-based
or timetable-based procedures) are not based on link data, but on PuT line timetables.
To model passenger transfers between certain public transport stops, a special public
transport system PuTWalk may be introduced. These links are taken into consideration for PuT
assignments.
2.1.3.3
If there is free traffic flow in an unloaded network, the travel time t0 of a link can be determined
from the link length and the free flow speed v0.
The free flow speed v0-TSys of vehicles of a particular transport system can be lower than the
free flow speed v0 of a link, because special speed limits might apply to these vehicles or
because the vehicles cannot drive faster. The maximum speed of a PrT transport system
vMax-TSys is an attribute of the link type.
Therefore, for speed v0-TSys and travel time t0-TSys applies:
PTV AG
43
Input: VD function, for example BPR function from U.S. Bureau of Public Roads
Result: Current in-vehicle time in the loaded network, for example
b
q
t cur = t 0 1 + a ------------------ (dependent on VD function type)
q max c
The illustration 14 illustrates how speeds vcur of two PrT transport systems develop depending
on the volume.
Link type Motorway
vmax (car) = 150 km/h
Link
v0 = 130 km/h
130
100
Car
HGV
2.1.3.4
With every link, a PuT run time is stored for each PuT transport system. When inserting a link,
this run time is automatically calculated from the link length and the link type specific speed of
the PuT transport system. From the PuT run times of the traversed links the run time between
the stop points is then calculated when constructing a line route. This run time is in the
respective time profile (see "Specifications of lengths and times" on page 63).
44
PTV AG
2.1.4
Zones
Zones (also traffic cells) are the origins and destinations of movements (demand). This means
that each trip starts in a zone and ends in another zone. Zones connect the transport supply
(network model with nodes, links, PuT lines, etc.) and the travel demand (in form of demand
matrices (see "Matrices" on page 120)), which contain the demand (trips) of all OD pairs of the
model.
Every zone can be assigned a zone boundary (zone polygon) which represents the spatial
extension of the zone. In the network model, zones are reduced to a zone centroid. Here the
trips of a demand matrix are fed into the network. Every zone must be connected via a
connector (see "OD pairs" on page 46) to at least one node. The optional zone polygon has no
influence on the calculation results in the assignment; however, typical GIS functions such as
intersecting can be realized with the zone polygon (see "Intersect" on page 677). Multiple
zones can also be combined to a main zone for evaluation purposes.
The zone size can vary depending on the level of detail of the model. Zones generally describe
the position of places or utilities (for example, residential areas, work places, shopping centers,
schools). Structural data such as the number of inhabitants, the number of jobs or the number
of school places are stored here, which are used for calculating the traffic demand as input
data (see "Demand modeling procedures" on page 125).
The illustration 15 shows an example of the transport demand between the zones and how
they are available in the demand matrix.
Illustration 15: Transportation demand between zones illustrated in the transport network and as a demand
matrix
Note: Zone boundaries are managed (see "The surface data model in Visum" on page 111)
like surfaces and can consist of multi-face polygons and polygons with holes.
PTV AG
45
2.1.5
OD pairs
OD pairs exist between all zones of the network. The values in skim matrices and demand
matrices (see "Matrices" on page 120) refer to one OD pair each. Compared to the other
network objects, you cannot edit OD pairs interactively in the network editor, but you can filter
OD pairs and display them graphically. For each OD pair you can select the skim matrix values,
the demand matrix values and the direct distance as attributes. The table 9 shows a demand
matrix value for Matrix 1 X and the skim matrix values for the skim of mean travel time for all
OD pairs in the example Example.ver.
From zone
To zone
100
100
100
200
2,000.00
38.00
100
201
200.00
12.00
0.00
100
202
0.00
32.00
200
100
2,000.00
38.00
200
200
0.00
0.00
200
201
5,000.00
16.00
200
202
2,000.00
13.00
201
100
200.00
12.00
201
200
5,000.00
16.00
201
201
0.00
0.00
201
202
0.00
20.00
202
100
0.00
32.00
202
200
2,000.00
13.00
202
201
0.00
20.00
202
202
0.00
0.00
2.1.6
Connectors
Connectors connect zones to the link network. Each zone has to be connected to at least one
origin zone and one destination connector to the network for the assignment, so that the road
users can exit and enter this zone. A zone can be connected to the network with any number
of connector nodes.
A connector corresponds to an access or egress route between the zone centroid and the
connecting node. A connector has therefore two directions.
46
PTV AG
The illustration 16 shows an example of how the travel demand between the zones, which is
saved in the demand matrix, is applied via the connectors to the network.
Illustration 16: Supply of the travel demand via connectors to the network
For each direction, the permitted transport systems, meaning those transport systems which
are permitted to use this connector, can be determined. In PrT, connections can be opened for
all PrT transport systems. In PuT, however, a path always starts and ends with a route traveled
by PuT pedestrian transit system on the connection. It is therefore assumed, that the access
and egress of the stop is always by foot. For connectors in PuT there are basically two
possibilities of modeling.
One or more nodes in proximity to the zone centroid are connected. A PuT path always
starts and ends with a walk link on the connector and continues on the network links to the
access nodes of the next stop area and from there to the stop point, from which a vehicle
journey is used (this approach is not recommended).
Only nodes which are also access nodes of a stop area are connected. In this case, each
path starts and ends with a walk link on the connector and within the stop continues to the
start stop point. Links are not used like that (this procedure is recommended).
The transport system dependent Connector time in unloaded network t0 is the time which
each transport system requires to pass the connector. The standard value for t0 per transport
system is calculated from the connector length (standard value is the direct distance) and the
connector speed which also exists as a standard value (see User Manual, Chpt. 2.18.1,
page 329). The standard value for the connector speed can be assigned separately for PuT
and PrT connectors. t0 can be overwritten manually by the user.
2.1.6.1
For modeling connectors in PuT and PrT, there are different possibilities of influencing the
distribution of a zone demand to the connectors (see "Distribution of the traffic demand to PrT
connectors" on page 291 and "Distribution of the travel demand to PuT connectors" on
page 448). The illustration 17 provides an overview of these possibilities and describes each
effect.
PTV AG
47
2.1.7
2.1.7.1
Main node
For the illustration of roads and other transport-related areas, which are more or less structured
by central reservation or traffic islands, there are several possibilities of displaying these in a
transport model. For relatively strong abstraction, the correlation of components with regard to
content, for example lanes of both directions on a road are illustrated by an individual link. This
is the best view for traffic engineering analyses. With the increasing application of navigation
networks with disaggregated illustrations of reality as a basis for transportation models,
networks divided into small sections play an increasing role. These models then have both lane
directions as two separated links in the Visum model. However, combining these in an
aggregated display would create a lot of work as well as a loss of information, because the
existing refined distribution is required when carrying out micro-simulations with the microsimulation program Vissim.
48
PTV AG
For conventional modeling, there is a contradiction between the activated demand for
disaggregated network display and that of differentiated turn delays per turn type. We want to
make it clear using an example.
If two roads intersect as in illustration 18 with separated lanes, the intersection area splits up
into four nodes. If a triangle island is also present, the turns with the respective node are also
added. A road user who comes from the bottom of the image and turns left, successively
passes nodes 1 to 5. Only at node 3 he follows a turn, which constitutes a left turn; all other
nodes he passes straight. Right turns only meet two nodes, at both nodes they traverse a turn
to the right, whereas straight paths pass four nodes. If turn penalties were assigned, the sum
of all traversed turns effects the node, although the contained shares, such as waiting at a SC
only once has an effect in reality. A possible solution could be, to individually set the turn times
of each movement, so that the sum of all traversing turns results in the desired value for the
movement. This, however, is not possible with a type-based allocation of values, because
turns of the same type would have to be attributed differently at the same node. There should
rather be a linear equation system for each intersection area.
The main node puts the thought underlying such a solution into effect by incorporating the
nodes belonging to an intersection area explicitly in a separate object. All nodes of the
intersection area thus form a logic unit, which takes the place of the previous nodes. Turns are
regarded on the logic level of the main node and are called main turns here.
Links whose From node and To node belong to the same main node are called inner links of
the main node. It is called a cordon link if only one of the nodes is part of the main node. These
constitute the access to and egress of main node: Each OD pair accesses the main node via
a cordon link and egresses it via another one. A link is also a cordon link, if both nodes are
allocated to different main nodes.
The combination of several nodes in a main node defines, based on the nodes of the main
nodes, different kinds of links:
Inner links: From node and To node belong to the main node (illustration 19: (1)).
Cordon links: one of the two nodes belongs to the main node, the other one lies
outside of it (illustration 19: (2)).
Directed links or One-way streets: this is a link with at least one direction with an
empty TSys set or zero lanes.
There is also cohesion between main nodes and different node types:
PTV AG
Inner nodes: only inner links originate here (illustration 19: (3)).
49
Cordon nodes at least one cordon link originates here, additionally possibly inner links
(illustration 19: (4)).
Partial nodes: any nodes that are allocated to a main node. These could be inner
nodes, cordon nodes, and nodes lying beyond the boundary of the main node.
2
4
1
3
Note: Main node polygons are managed like surfaces and can be made up of multi-face
polygons or polygons with "holes" (see "Multi-part surfaces" on page 114).
2.1.7.2
Main turns
Main turns are constituent parts of main nodes. They are created automatically when defining
a main node and can be edited manually.
Main turns possess the same attributes as turns. They are automatically inserted or deleted
when editing cordon links, i.e. when inserting or deleting cordon links and when editing the
allocations to main nodes or relevant attributes (TSysSet, NumLanes).
Each movement via the main node is represented by a main turn. A main turn is therefore the
transfer from one cordon link to another. If the main node consists of a single node only, the
main turn corresponds to exactly the turn between the links concerned. It is thus a
generalization of the usual turns at a node on the level of the main node.
If we reconsider the intersection area in illustration 18, assuming that all displayed nodes were
incorporated in a main node, seven cordon links exist. Since a main turn leads from each
cordon link to each cordon link, there are 49 main turns at this main node. However, it does not
make sense to traverse some of them, as they enter one-way roads in opposite directions (see
"Main turns not open to traffic" on page 51). Exactly the 16 (or 12, in case of closed U-turns)
convenient movements via the main node remain the main turns that are open to traffic (see
"Main turns open to traffic" on page 51).
50
PTV AG
Within a main node the main turn completely takes the place of the network. This means that
all traffic-related properties which take effect when crossing the main node are described
exclusively by the attributes of the main turn and the main node. A path that crosses the main
node only uses the main turn between the incoming and the outgoing cordon link. Neither the
attributes of the (inner) links, nodes and turns in between are evaluated, nor will these network
objects be loaded during assignment.
2.1.8
PTV AG
Multiple zones can be aggregated to larger study areas in very detailed modeled networks.
This often also makes the graphical display in the network editor clearer.
Display of flow bundles on main zone level
51
Note: It is currently not possible to calculate assignments or demand models on main zone
level.
2.1.9
Territories
Local authorities such as counties or districts can be displayed as territories, for example. PrT
and PuT attributes can be calculated precisely by inserting territories and applying the
operations territorial indicators (see User Manual, Chpt. 4.4.3, page 970) and PuT operating
indicators (see User Manual, Chpt. 7.3.1, page 1219). This means, that the indicator share is
calculated which applies to a territory. Use cases occur especially when calculating PuT
operating indicators.
Note: Zone boundaries are managed (see "The surface data model in Visum" on page 111)
like surfaces and can be made up of multi-face polygons or polygons with "holes".
2.1.10
Paths
All assignments in Visum in PrT as well as in PuT are path based, meaning that possible paths
in the assignment are calculated for each origin-destination relation and loaded with a demand
share. All other results, especially the volumes of the different network objects and the skim
matrices are derived from these loaded paths. Paths are therefore the central result of the
assignment procedure.
In Visum the definitions path (PrT path and PuT path), PuT path leg and PrT paths on link level
are used. PuT paths are thus described with a sequence of PuT path legs. Link-based PrT
paths display all links which lie on a PrT path.
On the basis of assignment results, using paths you can execute detailed evaluations, such as
flow bundles (see "Flow bundles" on page 697), or verify the assignment results. As an option,
Visum saves the assignment of paths found (see User Manual, Chpt. 5.1.2, page 975).
52
Creating an own assignment result either by creating a network file in a text editor or
interactively by digitalizing paths.
Editing assignment results calculated by Visum. This may occur interactively by digitalizing
the path course in the network editor or by editing the path volume in the path list. On the
other hand, the paths can be written as network files and edited in a text editor.
PTV AG
Maintaining different assignment results in a network as path sets. Each path set then
contains the paths in an assignment.
Maintaining different flow bundle results as path sets. Each path set then contains the
result (the paths) of one flow bundle calculation.
Overwriting a selected section of the assignment result with external data. This is how only
paths which start in this planned residential area can be edited manually and the rest of the
assignment maintained in a transportation analysis.
Distributing a matrix on paths. For a given matrix and given paths, the matrix values are
distributed to the paths. This enables you to replicate the trip distribution and quickly update
the manual assignment.
There are two procedures for handling PrT path objects, which can be integrated into
calculation processes (see User Manual, Chpt. 2.23, page 380):
Converting paths (see User Manual, Chpt. 2.23.12, page 394). The procedure can be used
for example, to replace one assignment result with another. There are the following
possibilities:
Converting assignment result to path set
Converting path set to assignment result
Converting path set to path set
Converting assignment result to assignment result
Distributing a matrix to paths (see User Manual, Chpt. 2.23.14, page 396). Based on a
matrix and paths, the trips of the matrix are distributed to the paths. This enables you to
modify the demand on the level of OD pairs and then distribute the new demand to all
existing paths of the OD pair, in proportion to the previous shares. Distribution is carried out
with the attribute ShareOfPathTarget. The attribute can be defined for each path by the
user. For each OD pair of a path set the attribute ShareOfPathTarget is first added up
(total weight) on all paths.
P
Total weight =
i = 1 ShareOfPathTarget
Where P is all paths in a path set of origin O to destination D. If e.g. there are five paths
from zone A to zone B, the ShareOfPathTarget of the five zones is added together.
The volume of an individual path p then results from the following equation.
p.ShareOfPathTarget
p.Load = Matrix value --------------------------------------------------------Total weight
PTV AG
53
2.1.11
Stop point
Specified departure point for one or more lines. PuT lines stop here for passenger
boarding. In the most detailed model, the stop point corresponds to a stop sign for bus
services or the edge of a platform in the case of rail services.
Stop area
Combines several stop points in close proximity and displays the access to the stop points
in the remaining transport network via an access node.
Stop
Is the object which comprises the entire complex of stop points and stop areas. It is the
highest object of the stop hierarchy and carries the name of the stop and others, for the
entire construction applying attribute. In the real network, it is therefore of more
organizational nature.
Stop point
at link 1-2
after 50 m
Stop area
H
1
H
Stop
54
PTV AG
Undirected
stop point on link
H
Directed
stop point on link
The differentiation between stop points on nodes and links allows network models of different
levels of detail to be generated with Visum:
For strategic planning, stop points on nodes are sufficient, since the exact position of the
stop point in front of or behind the road junction is usually of no interest. The stop area
and stop are generated automatically in the background, but generally remain hidden to the
user, if desired.
For operational planning and AVLS supply, it is useful to model the stop points on links, as
you can then achieve the required degree of detail.
It is also possible, of course, to mix both types in Visum, for example by using the more
accurate link-based model in built-up areas and the node-based model in non-built-up areas.
A stop point can be permitted or blocked for each existing transport system. Only line route
vehicle journeys, whose transport system is permitted, can stop there.
Notes: We recommend to set the start or end point of a line route only at stop points which
are located on nodes, because inaccurate results might occur if a line route starts or ends at
link stop points, for example, when calculating PuT operational indicators or in case of PuT
volumes which are displayed on link level.
Because vehicle journey stops always occur at a stop point, each stop has to have at least
one stop point.
PTV AG
55
walkway) is used. The transfer time for a demand segment is always the minimum time
required for all permitted PuTWalk systems. User group-dependent transfer times, for example
for mobility-impaired persons, can be modeled by permitting selected PuTWalk systems (for
example, ground-level walkways and lifts) only for specific demand segments. Stop areas can
also represent intermediary levels in large station areas. In this case, while transfer times to
other stop areas exist, the stop area itself does not contain stop points.
Note: The transfer walk times (transfer walk times matrix) between the stop areas is defined
at the stop.
The second function of stop areas is to connect stops to zones and the walkway network
beyond the stop. As an option, to each stop area a network node which can be reached with
the same transfer times like each stop point of the area can be allocated. The time within a stop
area (diagonal of the transition matrix) is not used for the transfer to the access node. Via this
network node, PuT paths can change from a public transport line to links with PuTWalk or PuTAux transport systems as well as to connections to zones and vice versa.
2.1.11.3 Stops
A stop comprises the entire complex of stop areas and thus also stop points. To ensure that a
stop can be localized and displayed in graphical form, it has a coordinate, but it is not assigned
directly to a network node or link.
The stop contains information on route times within each stop area (on the transfer walk time
matrix diagonal) and between two stop areas. In addition to these walk times, as an option the
stop also has transfer walk times and wait times between transport systems. With this a
particularly through structural or organizational measures aggrieved or favored transfer
between vehicle journeys can be illustrated, for a modeled stop without stop areas, for
example. The general transfer walk time of eight minutes could apply in a large train station,
when changing from an ICE train to another train, however, because of track information, three
minutes should be sufficient, for example. In such a case, these three minutes could be defined
as transfer time of the transport system ICE in the same transport system.
2.1.12
PuT operators
Providers of public transport vehicle journeys, for example local transport services or train
operating companies, are called operators. The network object operator is the starting point for
analyses of the public transport supply from operator point of view. It is therefore used within
the network for grouping lines and vehicle journeys to jointly evaluate units. An example is the
distribution of the revenues to the various operators of a transportation agency. This is often
based on service kilometers or seat kilometers. If you have assigned operators to the vehicle
journeys in your model, you can evaluate these and many other indicators (see "Operator
model PuT" on page 521).
Operators can either be assigned to a whole line (one then talks about a standard operator) or
individual vehicle journeys.
Note: Please note that changing the standard operator of a line subsequently, does not
overwrite the operators of existing vehicle journeys.
56
PTV AG
2.1.13
2.1.14
PTV AG
57
Main line
Line
Line route
Time profile
Vehicle journey
Vehicle journey item
Illustration 24: The line hierarchy used to model the PuT supply
Main lines
This optional network object is used for an aggregated evaluation of the lines allocated to the
main line. A main line can also incorporate lines of different transport systems. The network
object does not affect the assignment or the structure of the timetable.
Lines
A line structures the public transport supply. Within the Visum data model, it is mainly used to
aggregate several line routes. Each line has at least one line route or multiple line routes. The
line itself neither has a spatial course in the network (see "Line routes" on page 58), nor are run
times specified between the stop points (see "Time profiles" on page 60). Each line belongs to
exactly one transport system. You can optionally allocate a standard operator and a standard
vehicle combination to a line. When creating new vehicle journeys, they will then be suggested
as default values.
Line routes
A line route is part of exactly one line and describes the Spatial route course of the line for
one direction (from now on called the Line route course).
The line route course is issued as a classified series of route points. The length data of the line
route course are output between two consecutive route points. A route point can be a node or
a stop point along the line route course. All stop points along the course at which the line route
can stop, are always route points. All nodes along the course can optionally be declared as
route points. The line route course must start and end at a stop point that is located on a node.
The line routes of a line are usually available in pairs for the two directions. However, each line
can incorporate any number of line routes (cf. for example illustration 25). Different line routes
(pairs) of a line represent different route courses, which are organized in lines.
58
PTV AG
Line routes can be generated either manually or based on existing system routes (see "System
routes" on page 70).
Link network
Line route 1
Line route 2
M
S
PTV AG
59
Time profiles
Each line route has one or more time profiles. A time profile describes the temporal sequence
of the line along the line route. However, specific departure times are not specified, but the run
times between the individual route points.
Analogous to the line route (route points), the time profile is described by a sequence of profile
points. This sequence of profile points is called the course of the time profile. Any route points
of the underlying line route can be profile points. However, the start stop point and the end stop
point of the line route as well as all stop points, at which passengers can board or alight must
be among them. The time profile may also contain passage times for any route points of the
line route, e.g. for a conflict check of the timetable routes. Profile points are the points in the
network, between which the run times are specified in the time profile. The run time is specified
for the section between the previous and the current profile point. In case of stop points, a stop
time can additionally be specified and boarding and alighting can be permitted or prohibited.
Multiple time profiles of a line route can, for example, differ in the selection of the profile points
or the run times on the different sections between the profile points (cf. for example
illustration 26). If a vehicle journey of a line route shall stop at a stop point along the route yet
another one shall not stop, you need to define two time profiles for the same line route (yet not
if a vehicle journey shall serve just a section of the line route and thus of the time profile).
Furthermore, each time profile has a name and an allocation to a direction. Optionally, a
standard vehicle combination can be allocated to the time profile. When inserting a new vehicle
journey, this is then applied automatically as a default value.
Note: Please note that the vehicle combinations of existing vehicle journeys are not
overwritten. If a standard vehicle combination is specified for the line also, the standard
vehicle combination of the time profile takes effect when inserting a new vehicle journey.
Fare points can still be specified at the time profile, for each profile point. These can enter the
calculation of revenues (see User Manual, Chpt. 7, page 1157).
When modeling public transport, time profiles are important in the following use cases:
Couplings are set on time profile level (see User Manual, Chpt. 2.31.5.5, page 483).
Headways for the headway-based assignment are specified on time profile level (see User
Manual, Chpt. 6.9, page 453).
As a consequence, all network objects which, in the line hierarchy are located below the time
profiles (vehicle journeys and vehicle journey sections), are not relevant when defining
headways or couplings. Therefore, if you want to couple profiles on vehicle journey level or
specify headways, you need to create a separate time profile for the respective vehicle
journeys and carry out the coupling or the definition of the headways here.
60
PTV AG
Line route 1
SPoint
Stop
Dep.
SPoint
Stop
0:00
Arr
Dep.
1:00
1:02
2:00
2:02
1:50
1:52
3:00
3:02
2:50
2:52
5:00
5:02
4:50
5:02
6:00
6:00
0:00
M
Illustration 26: Example of two time profiles of a line route
PTV AG
61
Furthermore, the vehicle journey contains a departure time at the start stop point from which,
together with the relative times of the time profile, all arrival, departure and non-stop run times
of the vehicle journey are determined.
A vehicle journey can optionally be assigned an operator. You can then calculate aggregated
evaluations of PuT operating indicators on operator level (see "Operator model PuT" on
page 521).
Valid day
Vehicle combination
Start and end stop point
Pre and post preparation time for line blocking (see "Line blocking" on page 532)
A vehicle journey, which traverses from A to C via B from Monday to Friday, on the
weekend however, only from A to B, can be modeled by two vehicle journey sections, which
only differ in their valid days.
A train, running from A via B to C, between A and B however with less coaches, can be
modeled by two vehicle journey sections, which differ in their vehicle combinations and
start and end stop points.
Any combinations are possible, for example a train which runs between A and B and which
is only short on the weekend.
Vehicle journey sections are network objects, with which line blocking is carried out (see
"Line blocking" on page 532).
The table 10 shows an example with three vehicle journeys of a line route. The line route has
two time profiles. Vehicle journey 993 is divided into three vehicle journey sections, which differ
in valid days and vehicle combinations.
62
Trip number
from -> to
Departure time
Valid day
Vehicle combination
991
NH
Daily
Loco + 6 coaches
992
MH
Daily
Loco + 6 coaches
993
MH
Daily
Loco + 6 coaches
HS
11:02 a.m.
(Sat+Sun)
Sat+Sun
Loco + 6 coaches
MN
1 additional coach
PTV AG
Line
Line route
Time profile
IC1
IC1
1.1
1.2
1.1
Trip number
991
992
Valid day
Daily
Daily
Vehicle combination
L+6C
-
M dep.
IC1
993
-
Mon-Fri
Sat+Sun
Mon-Fri
L+6C
L+6C
L+6C
1C
5:10
6:00
I arr.
07:00 a.m.
I dep.
07:02 a.m.
N arr.
N dep.
W arr.
W dep.
H arr.
H dep.
11:02 a.m.
S arr.
12:00 a.m.
PTV AG
The link length can be allocated from the direct distance of the link (see User Manual, Chpt.
2.14, page 276).
The link length can be allocated from the polygon length of the link (see User Manual, Chpt.
2.14, page 276).
When shaping the link, it can be specified that the link length should comply with the
polygon length (see User Manual, Chpt. 2.14.11, page 290).
You can overwrite the link length in the link list manually, for example, and thus assign any
length to the link (see User Manual, Chpt. 12.1.10, page 1386).
63
Link
Length
When editing the shape of the link: Take over Length-Polygon
Manual overwriting
Standard
To Length
Manual overwriting
Legend
Standard
The value of the attribute is used as standard value for another attribute. Please note: when subsequently
editing the attribute (e.g. t-PuTSys), the value is not adjusted automatically (for example for the Run time
at time profile). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from link run time)
Visum offers different possibilities to assign times to links and time profiles. The illustration 28
provides an overview on how you can influence the run time values for links and time profiles.
The standard values for the link run time of a PuT transport system (t-PuTSys) is calculated
from link length divided by the link-specific speed of the PuT transport system. The link run time
of the PuT transport system again provides the standard values for the travel times in the time
profile. The departures and arrivals of a vehicle journey always automatically result from the
times provided in the respective time profile. The run times for each PuT transport system can
be changed as follows.
The run times can be assigned from the line run times.
The standard value (quotient of link length and link-specific speed of the PuT transport
system) can be restored.
You can overwrite the times manually in the link list, for example (see User Manual, Chpt.
12.1.10, page 1386).
64
PTV AG
Link
Standard values
Manual overwriting
Standard
Set times: from link run time
Time profile
run time
Auto
Manual overwriting
Vehicle journey
Departure/ Arrival
Legend
Standard
Auto
The value of the attribute is used as standard value for another attribute. Please note: when editing the
attribute (for example t-PuTSys) afterwards, the value is not adjusted automatically (e.g. for the Run time
at time profile). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from link run time)
For the temporal scheduling of the vehicle journeys, the times of the associated time profile are transferred
automatically. If you thus change a run time in the time profile, the time of the associated vehicle journeys
will be changed automatically.
PTV AG
65
66
PTV AG
F
A
As an option, aggregating line routes can be made more difficult with the following conditions.
Time profiles must have the same run and dwell times.
Time profiles must have the same settings for boarding and alighting.
Time profiles must have the same vehicle combination.
PTV AG
67
H1
L1-1
H4
H3
L1-2
L1-3
L1-1
H2
H1
H3
H2
H5
L1-2
H5
H4
H6
H3
L1-1
L1-1
H5
L1-2
L1-3
H1
H2
H4
H6
H1
H2
H3
H4
L1-2
The number of vehicle journeys and their departure times from From/To Stop Points of coupled
sections may deviate. Missing vehicle journeys are generated.
In Visum, coupled line routes form a coupling group. Visum adjusts the times and the timetable
of the coupled line routes. Visum automatically adjusts the data of all line routes of the coupling
group after changes to the time profile of a single coupled line route.
Inserting and deleting vehicle journeys (see User Manual, Chpt. 2.43, page 658)
Inserting and deleting vehicle journey sections (see User Manual, Chpt. 2.43, page 658)
Changing the length of vehicle journeys (see User Manual, Chpt. 2.43, page 658)
These changes need to have an effect on coupled time profiles, so that the supply of vehicle
journeys in each coupling section is synchronized again.
68
PTV AG
As service-km, service-time and the infrastructure cost influence the operating cost of a line
route, coupled line routes which result in lower costs.
Coupling does not have an impact on line blocking or assignments.
During assignment, changing seats within a coupled line is thus regarded as a regular transfer
between line routes.
40 km
30 min
50 km
30 min
40 km
30 min
H1
H4
L1-1
H3
H2
L1-2
H5
H6
40 km
30 min
50 km
30 min
40 km
40 min
Illustration 31: Calculation example for the calculation of indicators in case of couplings
PTV AG
69
Number of trips
10 trips
Empty time
10 min/trip
Kilometer costs
1 euro/km
Hourly costs
60 euros/h
Track price
1 euro/km
Seats
Not coupled
Coupled
Coupled
L1-1
L1-2
L1-1
L1-2
Line route
ServiceKm
SeatKm
Service time
Out-of-depot time
1,300 km
1,300 km
1,050 km
1,050 km
13,000 km
13,000 km
13,000 km
13,000 km
900 min
1,000 min
750 min
850 min
1,000 min
1,100 min
850 min
950 min
Cost
1,300 EUR
1,300 EUR
1,050 EUR
1,050 EUR
Cost
1,000 EUR
1,100 EUR
850 EUR
950 EUR
Track costs
1,300 EUR
1,300 EUR
1,050 EUR
1,050 EUR
Total cost
3,500 EUR
3,600 EUR
2,950 EUR
3,050 EUR
10
10
10
10
Num Vehicle
journeys
H2-H3
H3-H4
H2-H3
H3-H4
1,000 km
400 km
500 km
400 km
20
10
10
10
2.1.15
System routes
A system route describes a route within the network from one stop point to another, with the
time required. As an option, this required travel time as well as supplements for starting and
braking per vehicle combination can be further specified. It is important that the travel times are
always stored independent of concrete lines in the system route. The system route thus
represents a time which a certain vehicle combination requires on a given route between two
stop points, independent of whether they belong to a line or even to a concrete vehicle journey.
This travel time and route information can be used in two ways for creating a timetable.
70
PTV AG
If several matching system routes exist, the times are not set for the sections in question.
When new time profiles are created, the run times are calculated on the basis of the system
route (if available). Special defaults are taken into account for the vehicle combination if it is
specified for both the system route and the time profile.
If no system routes have been defined, link times are used as before.
Besides being used in the timetable, system routes play an important role in line blocking. As
an option, system routes can be used for empty trips within line blocking or new system routes
can be generated automatically for that purpose (see User Manual, Chpt. 2.33.8, page 527).
PTV AG
71
2.1.16
72
PTV AG
POIs are managed in POI categories. Each POI must be allocated to a POI category. Before
inserting the first POI, you thus have to create a POI category (see User Manual, Chpt. 2.34.1,
page 532). Any number of POI objects can then be inserted in the defined POI category, in the
network.
POI categories in a transport network are for example
POI categories can be organized as a hierarchy. This is how you can create a POI category
schools with the three subcategories secondary schools, junior high schools and elementary
schools.
Each POI can be assigned to a node, a link, another POI, a stop area, a stop point or a POI
category. You can illustrate this assignment graphically in the network (see User Manual, Chpt.
12.3.5, page 1411). In the example of illustration 33 allocations are used to illustrate for
parking lots in a downtown area which links the approaches lead to.
If you want to import data from GIS systems into Visum, these data can be stored as POIs in
the network model (see User Manual, Chpt. 10.4, page 1295).
PTV AG
73
Notes: POIs and their assignment to network objects do not have an influence on procedures,
such as assignments for example.
If you create a user-defined attribute for a POI category, it will also be created for all
subcategories of the POI category.
2.1.17
The detector is allocated to a node or a main node. This type of detector serves for
modeling signal control, for example, traffic-responsive signal control. It is not possible to
define a reference to count locations.
The detector is defined freely in the network and as an option, it can be allocated to a count
location, and so also indirectly to a link. In this case the detector constitutes a lane-based
count location. It breaks down the count data of a count location precisely by lane. The
number of observed lanes is defined via the observed lanes attribute. The lane observed
on the far right is defined via the Lane position attribute. If a detector is allocated to a count
location and therefore, to a link, the observed lanes have to be compatible with the number
of link lanes. This means that no lane which is not defined on the link may be observed.
With a lane number of two the detectors for lanes 1 and 2 are allowed to be defined. It is
however permitted, that a lane is observed by several or no detectors.
Count locations and their detectors are used less to maintain data, but more to visualize and
process thematic maps. Even though you can save count data to user-defined attributes of
count locations, you can also save them directly to user-defined attributes of the link (see
"User-defined attributes" on page 101). The advantage of saving count data directly at links is
that, in evaluations, you can compare them directly with the calculated volumes, which are also
saved with the link attributes. This approach is particularly recommended if you want to use the
matrix correction technique TFlowFuzzy (see "Updating demand matrix with TFlowFuzzy" on
page 195).
Count locations are thus primarily used for marking the position of a count in the network. You
can use the number to refer to external data, where applicable. The illustration 34 shows a
map, which is illustrated in the local position of the count location in the network, together with
the date of the last traffic count.
74
PTV AG
Illustration 34: Visualization of the local position of count locations with the date of the count
Notes: Do not just use count locations to integrate count values into the network. Instead use
user-defined attributes on links. However, if the current project requires the visualization of
counts or count location-related values shall be managed externally, the effort for the
coverage of count locations and detectors can pay off.
Compared to assignments for example, count locations and detectors do not have an
influence on procedures. The only exception are detectors near nodes which can be taken
into account for traffic-responsive signal control. Information provided by these detectors are
also used for ANM export to Vissim.
2.1.18
Toll systems
Toll systems are network objects which can be used to integrate toll zones and tolls into the
network model (see User Manual, Chpt. 2.38, page 561). They represent the basis for the
calculation of road tolls in the Tribut procedure (see "Basics of the assignment with toll
consideration" on page 378).
PTV AG
75
Area toll
In case of an area toll, a geographically contiguous part of the network is designated as a
toll zone and a distance-independent charge applies if a portion of the route is located
within the toll zone. In Visum, you can define such toll zones by inserting a polygon and
specifying a toll for all associated chargeable links.
The "Congestion Charge" in London is an example of an area toll. In the city center, a toll
is charged as soon as the specified area is entered.
Matrix toll
This type of toll model is the typical road pricing scheme for motorway corridors. A subset
of links is designated as a toll zone with a small number of connections (entries and exits)
to the rest of the network. Toll prices are not defined as a total of link toll prices, but there
is an individual price for each pair (entry exit). Because of these pairs, this type of road
pricing scheme is called a matrix toll. Toll typically increases with distance but in a
degressive way, i.e. the toll per km decreases with distance.
2.1.19
GIS objects
GIS objects are POI-like network objects (n categories with m objects of the type point, polyline
or polygon) that are only available during a Personal Geodatabase (PGD) connection (see
"Connection to the Personal Geodatabase and GIS objects" on page 671). This is how GIS
data can constantly be synchronized between the PGD and Visum.
76
PTV AG
2.1.20
Screenlines
A screenline is a polygon, which can be inserted into the network by the user with any number
of intermediate points. The screenline is inserted so that it intersects multiple links. The values
of any attributes of all links, which are intersected by the screenline, can then be aggregated
with the screenline. The following aggregate functions are thus available respectively for all or
only for the active links (see "Indirect attributes" on page 95).
The orientation of a screenline depends on the sequence of the polygon points along its
course. It is always oriented to the right in the direction of creating. By default, arrow heads
along the course indicate the orientation. For the aggregation, you can take into account all
links in screenline orientation, all links against the screenline orientation, or all links,
independently of the direction.
In the following example, the screenline intersects two links whose volume amounts to 1,000
and 3,000 persons. The screenline then aggregates the values of the links that it intersects. In
the example it identifies a total of 4,000 persons in screenline orientation for all links and an
average of 2,000 persons.
PTV AG
77
With the aid of screenlines, you can for example determine the traffic that enters and exits the
downtown area every day in a traffic engineering study which analyses the traffic volume of a
downtown area. In illustration 37, 149,334 vehicles in PrT and 76,370 persons in PuT are
entering the downtown area.
2.1.21
Junction modeling
Visum provides the possibility to model junctions in detail. There are two major fields of
application, namely the use of a detailed node impedance model among others in assignment
procedures, and the export for a micro-simulation in Vissim.
78
PTV AG
Element
Description
Geometry
Geometries are used to describe the geometry of nodes and main nodes in
detail. The principal elements of geometries are legs.
Leg
A leg geometry consists of a set of legs. A leg describes an entry to the node
section and the corresponding exit. A set of legs at a node or main node is
defined by the set of link orientations.
Lanes
A leg consists of a set of incoming and outgoing lanes. Through lanes are the
ones that lead right up to the adjacent node and pocket lanes start and end at
a certain distance from the node area.
Lane turn
Lane turns define a relation between an incoming lane and an outgoing lane.
They are used for detailed transport system and lane-based descriptions of the
turn conditions at a node.
Signal control
A signal control describes the total of all signal control data at one or more
nodes or main nodes. There are stage based and signal group based signal
controls, as well as external signal controls of the type RBC.
Stage
A stage is the basic unit of a signal plan in case of stage-based signal controls.
A set of signal groups is allocated to each stage. Then the green times of the
signal group result from the green times of the stages.
Signal group
Crosswalk
Detector
PTV AG
79
roads and outgoing one-way roads in one leg (see "Geometries" on page 80), if you give them
the same orientation.
Whether Visum calculates the link orientations automatically at a node or main node or not,
depends on the attribute Use automatic link orientation. If the link orientations are calculated
automatically, the type of calculation depends on the option set under Network > Network
parameters > Network objects > Link orientations (see User Manual, Chpt. 2.14.4,
page 280). Normally, the value is set to 8. This means that Visum picks the best orientations
from the four main directions (N, E, S, W) and the four secondary orientations (NE, SE, SW,
NW). The entry angle of the link at the node or main node is decisive when selecting the
orientation. If the orientations do not suffice i.e. the node or main node has more than eight
legs Visum adds the subordinated secondary orientations (e.g. NNE).
Notes: In Visum versions prior to 11.5, this setting did not exist for the calculation. Visum used
to implicitly calculate with today's setting 4. This means that Visum first tried to allocate only
the main orientations, and only switched to the secondary orientations in case of nodes with
more than four legs. The subordinated secondary orientations were not used in earlier Visum
versions.
Please note that you can define varying numbers of legs at a node or main node, depending
on the number of pairs of incoming and outgoing one-way roads that are given the same
orientation.
2.1.21.2 Geometries
In macroscopic traffic models, an at-grade junction is represented by a node (point object) with
turns. Macroscopic modeling, however, does not reveal anything on the detailed geometry or
the geometric design of a junction. Nearly the same applies to the node control. The optional
extension of the Visum network model by node geometry and junction control can be used in
the following fields:
A node geometry consists of the items node legs, lanes, lane turns, detectors, and crosswalks.
If a signal control is allocated to a node, its data refer to the node geometry. By default, no
geometry data are provided at a node. These are generated not until the first access.
Legs
The principal elements of the geometry are the legs. A node/main node can have up to sixteen
legs. The set of legs is determined by the orientations of the incoming and outgoing links (see
"Network objects of the junction model" on page 79). For each used link orientation, exactly
one leg is generated. Legs can thus either consist of an incoming link and its opposite direction,
or of an incoming one-way road and an outgoing one-way road.
Legs can have a center island, a channelized island, or both. For a center island to exist, the
center island length and width both need to have a value > zero. For a channelized island to
exist, the channelized island length needs to be > zero. The Stop line position attribute is only
used for the export to Vissim. Legs also possess a set of lanes.
80
PTV AG
Lanes
There are incoming lanes and outgoing lanes, as well as through lanes and pockets. The
number of through lanes at a leg cannot be changed. It is based on the set number of lanes at
the links which underlie the leg. Therefore, if the incoming link of the leg has three lanes
(Number of lanes attribute on the link) and at least one transport system, the leg features
three incoming through lanes. If the number of lanes at this link is changed, the number of
through lanes at the leg will be adjusted automatically. We recommend double-checking the
adjusted geometry data after such modifications. Since at least one open link underlies each
leg, each leg features at least one through lane.
The number of lanes at a leg can be changed by creating pocket lanes (pockets). Pocket lanes
always refer to a through lane on which they originate (origin lane). In contrast to through lanes,
pockets can be removed again. For pockets, a length can be specified. This is used during
Vissim exports and for specific methods of impedance calculations at nodes.
By default, the transport system set permitted on a lane corresponds to the transport system
set of the underlying link. For pockets, the transport system set of the origin lane is used by
default.
Note: The numbering of the lanes differs from the one in Vissim.
Lane turns
A lane turn connects an incoming lane with an outgoing lane. When generating a geometry
automatically, a set of lane turns is also generated automatically. In order to define a lane turn,
the turn or main turn between the link underlying the incoming lane and the link underlying the
outgoing lane must be open. This means that it needs to have at least one transport system.
It is usually not desired that lane turns intersect. Two lane turns, for example, intersect if one
of them makes a left turn on a right lane and the other one goes straight on a left lane. This is
yet possible and desired, if the left turn is a PrT turn and the other one a PuT turn. In this way,
a tram can, for example, be modeled in central position.
The set of lane turns basically determines the results of the node impedance calculations at a
node/main node.
Crosswalks
Crosswalks are objects that connect the sides or the islands of a leg per direction. Depending
on the combination of islands at a leg, you can define up to six crosswalks. If the node leg e.g.
has a center island (i.e. its center island length and width are both > zero) and a channelized
turn, six crosswalks can be defined: One between a side and the center island, one between
the center island and the channelized island, one between the channelized island and the other
side, and one each in the opposite direction.
Crosswalks are exported to Vissim. For crosswalks, a pedestrian volume can be specified.
This is relevant when calculating the node impedance using ICA (see "Intersection Capacity
Analysis according to the Highway Capacity Manual (ICA)" on page 229).
PTV AG
81
82
PTV AG
of stage-based SCs, green time start and green time end of a signal group correspond to the
green time start and green time end of its stage. If for a signal group or stage, the Green time
start attribute is 0 and the Green time end attribute is identical with the SC cycle time, this is
interpreted as permanent green. Both attributes are restricted by the cycle time of the SC. The
Green time end can have a smaller value than the Green time start. In this case, the green
time is calculated by subtracting the difference of both values from the SC cycle time. The
green time cannot fall below the minimum green time of a signal group.
Signal groups also have the attributes Amber and Allred. Furthermore, intergreens can be
defined between signal groups. All of these values are important when calculating the signal
cycle and split optimization. Hereby, the Used intergreen method attribute of the signal
control determines whether the amber and all-red time or the intergreen matrix is used for
optimization. The ICA loss time adjustment attribute is used in the calculation of the
impedances with ICA to determine the effective green times with the aid of the specified green
times. The Minimum green time attribute is used for signal cycle and split optimization,
serving as a low threshold value for the green time calculated. The Vissim coordinated
attribute is only relevant for the Vissim export.
The relation between the signal control and the network is established when allocating the
signal groups to lane turns. Each signal group can be allocated to any number of lane turns.
Prerequisite is, that the lane turns are located at nodes or main nodes which are allocated to
the SC of the signal group. Likewise, any number of signal groups of the SC can be allocated
to each lane turn that is allocated to the node or main node of the lane turn. A signal group can
also be allocated to any number of crosswalks. A crosswalk, however, can only refer to one
signal group. The data model is not restricted here. As an example, Visum does not check
whether a signal group is allocated to each lane turn. It does not check either whether
conflicting volumes have overlapping green times. Should the signal control be used to
determine node impedances, it is recommended to carry out the respective ICA network check
option to detect incomplete junction models (see User Manual, Chpt. 2.41, page 640).
Note: It is recommended to complete the modeling of a node or main node, before allocating
signal groups to lane turns. When deleting or inserting lane turns, the signal control data can
get lost.
External controls
A special feature of external SCs is that the data are not saved in the version file. Vissig control
files are saved in the *.sig format. This way, they can also be accessed by other programs, for
example Vissim. To edit external control data in Visum, you use the Vissig program. In external
controls, multiple signal programs can be stored. This is not the case for signal group based or
stage based controls. Therefore, the SC attribute Signal program number is only relevant
when dealing with external controls. Visum accesses the data saved in the control file at certain
times. This is, for example, the case when opening a version file or when running the
operations Signal cycle and split optimization and Update impedances at node via ICA.
Note: Up to Visum 12, RBCs belonged to the external controls. Now RBC files in the *.rbc
format are still read in, but are no longer used.
PTV AG
83
Stage templates
Stage templates can be used to easily generate signal control data at a node or main node
(see User Manual, Chpt. 2.40.13.3, page 629). If a stage template is allocated to a node, the
SC of the node then possesses a lot of stages and signal groups. Lane turns are already
allocated to the signal groups. This means, for example, that conflicting volumes are signalized
with different green times.
Note: Prerequisite for the use of a stage template is, however, that a stage-based SC is
already allocated to the node or main node.
2.1.22
Network check
Visum supports the user when checking the consistence of the network model. If the network,
for example, contains zones which are not connected to the rest of the network, this indicates
a modeling error. To identify such errors, several tests are provided (see User Manual, Chpt.
2.41, page 640).
2.2
2.2.1
Calendar
Valid days
Time series
Analysis time slots
2.2.1.1
Calendar
With the aid of the calendar, the modeling of transport supply (in PuT and for the DUE
procedure in PrT) and demand (for the dynamic procedures of PrT and the headway-based
and timetable-based assignments of PuT) can be refined considerably. It is not only possible
to model any day, but also to manage any combination of weekdays or individual days. The
calendar is global, i.e. only one of the following three calendar options can be applied to the
entire model. Use of the calendar is optional. The following options can be selected for a
network model:
84
No calendar
The transport options for one day are indicated. The analysis period is thus automatically
one day and cannot be edited by the user.
PTV AG
Weekly calendar
The demand (for the dynamic procedures of the PrT and for the headway-based and
timetable-based procedures of the PuT) and the PuT supply can be differentiated for the
individual weekdays Monday to Sunday. It is possible to specify for each vehicle journey
section weekdays on which there will be a service. The analysis period can be any time
period of entire days within the week (such as Monday to Friday).
Annual calendar
Valid days can be defined for any day of the year. The analysis period can be set to any
time period (in entire days) within the calendar period (e.g. 14th July 2008 to 20th July
2008).
The calendar takes effect in the following procedures (all other procedures are not affected):
2.2.1.2
Valid days
Valid days are closely linked to the calendar as they can be specified on the basis of the
selected calendar. First the kind of calendar is thus chosen when modeling, and then valid
days are specified on the basis of the respective calendar.
Valid day is a freely definable set of days of the calendar used. If a weekly calendar is used, a
valid day may comprise the days Monday to Friday, for example (the valid day then is
designated Mondays to Fridays).
In PuT the timetable is based on a calendar (see "Calendar" on page 84). A valid day can be
assigned to each vehicle journey section. Optionally, this can consist of an individual day or an
example week, however, a defined period on the calendar can also be used. In each case, the
availability of individual vehicle journey sections can be specified by valid days. A valid day is
a freely definable set of days of the underlying calendar. For each valid day a separate name
can be allocated. Valid days usually represent regularly recurring patterns, such as Monday to
Friday, but these could also be individual days (for example 01.01.2009). How to define a valid
day depends of the selected calendar:
PTV AG
No calendar
Exclusively uses the valid day daily. It is not possible to create further valid days. Demand
and supply are modeled for an unspecified, recurring day in this case.
Weekly calendar
Apart from the predefined valid day daily any desired valid days can be created, which are
specified by entering one or several valid weekdays (e.g. all weekdays with the valid day
name Mon-Fri).
85
Annual calendar
Valid days can be defined for any day of the year within the calendar period. The following
possibilities are provided:
fixed time period (e.g. 01.01.2008 to 30.06.2008)
weekdays (e.g. Mon-Fri)
hard rule (for example during the summer holidays)
free selection of calendar days (for example 24.12.2007 and 31.12.2007)
Valid days play a minor part in PrT. Valid days can be used in the following assignment
procedures:
Tip: In these procedures, the transport supply can be time-varying. Time-varying attributes
are used (see "Time-varying attributes" on page 105). When using a calendar, valid days can
be specified for these time-varying attributes, on which they should have an effect.
2.2.2
86
For time series as percentages a weight is specified for each time interval. It specifies
which share of the total demand accounts for the respective time interval. If a time series
as percentages is used for a demand segment, a demand matrix must also be specified,
whose demand is distributed temporarily with the specified weights. This matrix must
contain the number of travel demands in the time period, defined by the starting time and
the length of the time series.
PTV AG
However, for time series of matrix numbers for each time interval a separate demand matrix
is specified. It contains the travel demands of this time interval only.
Note: When using time series of matrix numbers, it is possible to specify a value for the
demand for each OD relation and time interval. This way, asymmetric changes of the demand
(load direction) can be illustrated. For time series as percentages however, the same factor
applies to each OD relation per time interval.
Time series of matrix numbers require a full matrix for each time interval, which must be
generated and also saved. In order to save the effort and still be able to model a certain load
direction in the demand, Visum provides demand time series as a compromise. These are
generated on the basis of a standard time series, whereas a different standard time series can
be specified for each pair of zone types. In this way, it is possible to specify deviating time
series for selected pairs of origin and destination zones with known structural features (for
example purely residential or commercial areas).
For each demand segment, either a fixed demand matrix together with a time series as
percentages is specified, or a demand time series which itself is a time series of matrices.
Moreover, a start day and the start time per demand segment must be specified.
PTV AG
87
Note: The start time shifts the time intervals of the time series since it is specified relative to
this start time point. If the time series defines an interval A from 0 am to 1 am and an interval
B from 1 am to 2 am, and the start time is set to day 2 at 2 pm, the share of the demand
defined in interval A will arise on day 2 from 2 pm to 3pm, and the share of interval B on day
2 from 3 pm to 4 pm. Outside of these times, for example on the first day of the calendar,
there is no demand.
2.2.3
88
The calendar period calendar period covers the set calendar, i.e. one, seven or any
number of days.
The Time reference of the demand determines the number of travel demands within the
assignment time interval. The time reference is established by the start time of the demand
segment and the time series allocated to the demand segment (see User Manual, Chpt.
3.1, page 731).
The assignment time interval mainly serves to determine the share of the demand that
needs to be assigned. It is crucial that the assignment time interval of each assignment lies
within the analysis time period. In the assignment, the share of the demand that accounts
for the assignment time interval according to the time series is assigned to the paths found
in this time period. The assignment area and the demand time series need to overlap, since
otherwise no demand exists within this time period and no assignment can be calculated.
An assignment time interval can only be specified for dynamic assignments (DUE, Dynamic
Stochastic assignment) of the PrT and for the headway-based and timetable-based
assignment of the PuT. The assignment time interval is specified in the parameters of the
assignment procedure. In all statistic PrT assignments (Equilibrium assignment,
Incremental procedure, Equilibrium_Lohse, Stochastic assignment, Tribut), the assignment
time interval automatically corresponds to the analysis period.
The analysis period (AP) represents the period on which all evaluations are based. If no
calendar is used, the analysis period is one day. If a weekly or annual calendar is used, the
analysis period is specified in the procedure parameters. The analysis period is a time
period between at least one day and a maximum of the whole calendar period Initially,
calculated results are available for the analysis period, before they are converted into
analysis time intervals or the analysis horizon. The analysis period must be within the
calendar period. The assignment intervals must lie completely within the analysis period.
For the analysis period projection factors can be specified at the demand segments, which
project the assignment results from the assignment time interval to the analysis period.
They serve to scale the demand to the analysis period. If the time period of the demand
matrix is identical to the analysis period, the projection factor is 1. If the demand matrix is
based on one day, yet the analysis period on a week, the factor would have to be set to 7
(when assuming that the traffic is the same on all 7 days of the week).
PTV AG
The analysis horizon (AH) is a longer time period on which the results can be projected.
It is not specified explicitly. Instead, the projection factors on the analysis horizon are
predefined. These can be specified at the demand segment (for the volumes) and at the
valid day (for the operator model) (see "Basic calculation principles for indicators" on
page 641). As a rule, an analysis horizon of a year is regarded. Since a different projection
factor can be specified for each demand segment, the projection factor of daily values to a
year can for example be smaller for a demand segment Pupils than for a demand segment
Commuters, as the pupils have more vacation days on which they do not generate any
traffic. The volume of a network object in terms of the analysis period is the total of the
volumes of all paths traversing the network object, multiplied by the projection factor of the
demand segment. This projection factor compensates that the assignment time interval
may cover only a part of the analysis period.
Analysis time interval (AI)
For a more refined temporal evaluation of calculated results, analysis time intervals can be
defined (see "Temporal distinction with analysis time intervals" on page 92). Each analysis
time interval needs to lie completely within a calendar day of the analysis period.
Note: Contrary to the analysis period, which incorporates the assignment time interval and
thus requires a projection of the volumes, the analysis time intervals identify the exact volume
which arises in the respective time period. Thus, the projection factors of the individual
demand segments do not have an effect on the volume per analysis time interval. If the
analysis period is completely covered by analysis time intervals, the relationship between the
total volumes for the intervals and the volume related to the analysis period exactly
corresponds to the projection factor.
DSeg 1
DSeg i
Demand segments
Calendar period CP
Day n
Day 1
Analysis period AP in CP
AP
AI
ATI
Illustration 40: The relationship between the different analysis time slots
PTV AG
89
Projection factor AP
Projection factor AH
365
---------- 5 = 260
7
Saturday
52
Sunday
52
DSeg
DSeg
start day start
time
Standard
Standard
Assignment
time series time series can be
from
to
calculated
Ex. 1 Weekly
calendar
Mon-Mon Mon
01:00:00 00:00:00
a.m.
02:00:00
No
Ex. 2 Weekly
calendar
Mon-Mon Mon
05:30:00 00:00:00
02:00:00
Yes
Ex. 3 Weekly
calendar
Mon-Mon Mon
00:00:00 05:30:00
07:30:00
a.m.
Yes
Table 16: Example of the interaction of analysis time intervals and time series
90
PTV AG
Mo
Tu
Calendar period CP
1:00
3:00
6:30
Analysis period AP in CP
7:30
AP
Assignment interval AI in AP
AI
Illustration 41: Assignment not possible because the validity of the demand and the assignment time
interval do not overlap.
Share of the demand
that is assigned
Mo
Tu
Calendar period CP
5:30
Analysis period AP in CP
Assignment interval AI in AP
6:30
7:30
AP
AI
Illustration 42: The demand between 6:30 and 7:30 a.m. is assigned.
PTV AG
91
Mo
Tu
Calendar period CP
5:30
Analysis period AP in CP
Assignment interval AI in AP
6:30
7:30
AP
AI
Illustration 43: The demand between 6:30 and 7:30 a.m. is assigned.
2.2.4
2.2.4.1
If a period which is shorter than the analysis period shall be analyzed for the temporal
differentiation of calculation results, several analysis time intervals can be specified (see User
Manual, Chpt. 4.2.2, page 949). The analysis time intervals must lie within the analysis period.
They have to neither be consecutive nor of the same length. The analysis time period, must
however, be within a day, is therefore not allowed to contain a day changeover. Provided that
attributes can be assigned on a time basis, the portion assigned to each defined analysis time
interval can be identified separately.
In addition, you can show aggregated data across multiple analysis time intervals. To do so,
you can create additional analysis time intervals, assign them existing time intervals, and
specify an aggregation function. Using these time intervals, you can output data for more than
a day.
92
PTV AG
In PrT, evaluations broken down by time slices can only be made for the dynamic assignment
DUE and the dynamic stochastic assignment (see "Dynamic User Equilibrium (DUE)" on
page 389 and "Dynamic stochastic assignment" on page 419). The reason is that only in those
assignments, the traffic demand can be time-varying. Therefore, evaluations for analysis time
intervals within the analysis period can only be made in the course of these procedures. The
link volume of the rush-hour traffic from 7 to 9 am can thus for example be evaluated
separately.
In PuT, evaluations broken down to time slices are only possible for the timetable-based
assignment procedure. In the timetable-based assignment procedure however, there are no
connections that are fixed in time, so that it is not possible to apply assignment results to a
specific analysis time interval.
2.2.4.2
For spatial distinctions, the user initially defines territories (see "Territories" on page 52). These
are network objects, which are only relevant for analysis purposes and possess a polygon
(boundary) as the most important feature. Provided that attributes such as the passenger
kilometers of a line can be spatially localized, the share assigned to each territory can be
identified separately. Thus all passenger kilometers will be calculated, which arise within the
territory polygon. To calculate such an evaluation, the Territory indicators procedure must be
run (see User Manual, Chpt. 4.4.3, page 970). The results can be displayed in the list
Territories > Basis (see User Manual, Chpt. 12.1.10, page 1386) and are also available in the
filters and in the graphic parameters in the form of territory attributes.
In PuT even more detailed evaluations can be carried out (see "Operator model PuT" on
page 521). Here you can even calculate indicators for combinations of territories, objects of the
line hierarchy (transport system, main line, line, line route, time profile, vehicle journey) and as
an option, vehicle combinations. You can thus for example calculate the number of service
kilometers traveled by the vehicle combination tram on line 2 in the urban area. Here, an
additional distinction can be made for most of the indicators on a temporal basis. You would
thus get just the service kilometers between 5 and 6 pm for example. Use the procedure PuT
Operating Indicators to carry out such an evaluation (see User Manual, Chpt. 7.3.1,
page 1219). The results can be displayed in the Territories > PuT detail list (see User
Manual, Chpt. 12.1.10, page 1386).
2.2.5
PTV AG
93
More detailed information on which units are used for capacity and demand in the individual
procedures will be given in the section on input and output attributes of each assignment
procedure (see "User model PrT" on page 211).
2.3
Attributes
In Visum, network objects have many attributes you can save your input or output data to.
Generally, there are two types of attributes:
Direct attributes
Indirect attributes
Direct attributes contain data that refer directly to a network object, e.g. the length or volume of
a link (see "Direct attributes" on page 94).
Indirect attributes refer to the relations between one network object and other network objects.
E.g. the sum of volumes of all outgoing links is an indirect attribute of a node (see "Indirect
attributes" on page 95).
The number of attributes available in Visum is not static, but can be extended by user-defined
attributes (see "User-defined attributes" on page 101).
Time-varying attributes play a special role in dynamic assignments (see "Time-varying
attributes" on page 105).
2.3.1
Direct attributes
Each network object is described by means of Visum attributes (direct attributes). The following
types are differentiated as follows:
Note: The Attribute.xls file in the Doc folder of your Visum installation contains a complete list
of all types of Visum network objects (which in connection with databases are also called
tables) and of all attributes of each network object. There, you find the ID of each attribute, by
which it can be identified clearly, its name and code as well as the description of what each
attribute indicates.
The table 17 shows an example of some input and output attributes of the link.
94
PTV AG
Attribute
Input attribute
Calculated attribute
Number
TSysSet
Capacity PrT
Number of lanes
t0-PrTSys
tCur-PrTSys
Passenger kilometers
Apart from predefined Visum attributes, for each network object type, user-defined attributes
(see "User-defined attributes" on page 101) can be created and edited. They are also direct
attributes of the respective network object type and can be edited, saved, displayed graphically
and in tables like Visum attributes.
In addition, for some network object types, it is possible to overwrite defined attribute values
with other values for a limited time (see "Time-varying attributes" on page 105).
2.3.2
Indirect attributes
Besides the direct attributes of the currently selected network object, you can also access its
indirect attributes. These are direct objects of other network object types that are network
model-related to the selected object. Therefore, for a network object, both the direct attributes
as well as its relations to other network objects can be selected.
Indirect attributes give access to properties of other network objects, which bear a logical
relation to the base object. It is often convenient to filter network objects not only by their own
properties, but also by the properties of their logical neighbors in the network, or to display
these properties next to their own properties in listings or graphics (for example displaying the
aggregated values of the attributes of all stop points, which belong to a stop, in a list).
Relations between network object types are displayed explicitly in the user interface and allow
access to all attributes of the referenced network object types (e.g. Link From node
Outgoing Links). The three existing kinds of relations between the currently selected network
object type and other network object types are indicated as follows.
PTV AG
exactly one relation (1...1). Such a relation, for example, exists between connector and
zone: each connector connects exactly one zone with the connector node. In the example
of table 18, for connectors, the indirect attribute Zone\Number of connectors is output.
For each connector, you can thus see how many other connectors the zone of this
connector has.
95
either one or no relation (0..1). Such a relation, for example, exists between nodes and
main nodes. A node can be allocated to a main node, but does not have to be. Besides,
each node can be allocated to just one main node. As depicted in table 19, with the aid of
indirect attributes you can see for each node to which main node it is allocated by selecting
the name of the main node as indirect attribute (Main node\Name).
Selection of the indirect attribute Main node\Name The indirect attribute is displayed in the list next to
in the attribute selection window
the direct attributes of the node.
Table 19: Example of a 0..1 relation in the Visum network model
several relations (0..n). Such a relation, for example, exists between stop areas and
stop points. Since no 1:1 link exists between the network objects types in this case, you
need to select an aggregate function which pools all related network objects (the aggregate
function Sum for example ensures that all indirect attributes are allocated with the sum of,
for example, all boarding passengers at all stop points that have a relation to the selected
stop area). Below, an example is given for each of the aggregate functions provided in
Visum.
If a 0..n relation has been selected at the Visum interface, the aggregate functions of either all
network objects or merely the active ones are displayed. Aggregate functions are not provided
in case of 1..1 and 0..1 relations, as there is only one relation from the current network object
to another network object in this case (just one link type is for example allocated to each link).
For 0..n relations, the following aggregate functions are provided:
96
PTV AG
PTV AG
97
98
PTV AG
PTV AG
99
100
Histogramand HistogramActive
Contrary to the aggregate function Concatenate, each occurring value is issued only once
along with the frequency of its occurrence. This display offers more clarity especially if the
user wants to see which values occur at all and how many times. The table 26 illustrates
the difference between the Concatenate and the Histogram display. Here, for each line, the
number of stop points of the associated line routes is displayed. For example, 13 line routes
are allocated to line S4. Two of the line routes have 10 stop points, 4 line routes have 20
stop points, and 7 line routes have 21 stop points.
PTV AG
Indirect attributes can also be used as source attributes for operation Intersect and thus allow
the combination of logical and geometric relations (see "Intersect" on page 677).
2.3.3
User-defined attributes
For all network objects - just as in databases or other geographical information systems - you
can define your own attributes in addition to the default input and output attributes in Visum.
User-defined attributes can be edited and stored just like predefined Visum attributes.
The following data can thus be included in the model.
PTV AG
Structural data of traffic zones (such as the number of households or the number of
workplaces), which serve as input data for demand modeling.
101
102
PTV AG
Line name
Costs [CU]
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
PTV AG
103
Note: Use formula attributes if you want the attribute Cost_per_Km to be updated
automatically when costs or link lengths change (see "Formula attributes" on page 104).
Then you need not repeat the calculation procedure in order to update the attribute. Visum
will automatically calculate the current values for you.
Each user-defined attribute has one data type. The following data types can be selected.
Bool (for example for a user-defined attribute "in scenario active", which can only be 0 or 1)
File (for example for a user-defined attribute at count locations which specifies which file
contains further information on the count location)
Formula (for automatic update of calculated attribute values) (see "Formula attributes" on
page 104)
Integer
Precise duration
Number with decimal places
Kilometers
Meters
Long text
Text
Time period
Time (for example 06:32:45)
2.3.3.1
Formula attributes
User-defined attributes of the formula type largely differ from other user-defined attributes.
They are not used to save data (they do not belong to the input attributes), but consist of an
arithmetic expression that contains other attributes. This expression is created when you
create the attribute, but can be changed later on.
The advantage of using formula attributes is that Visum automatically recalculates the formula
when one of the input values changes. Then your values are always up-to-date. Just as the
other attributes, you can also use formula attributes to graphically display data, filter data or to
perform analyses.
Example
For a PrT and PuT assignment, Visum calculates link volumes for PrT and PuT that are saved
to the attributes volume PrT [Pers] and volume PuT [Pers]. When creating a formula attribute
Advantage PrT = Volume PrT [Pers] - Volume PuT [Pers]
, you have direct access to the difference between the two volumes. This difference is
automatically updated if one of the input values changes.
Formula attributes are always numerical. When creating a formula expression, you have the
same options as for the procedure Edit attribute (see User Manual, Chpt. 2.3.8, page 176): A
formula is the sum of (a number of) subexpressions that each consist of an attribute or two
attributes combined with a binary operator. The operators available are the four basic
arithmetic operations, division in percent, raise to higher power, and minimum and maximum.
Each subexpression may be included in the amount. The formula total can additionally be
rounded or truncated.
104
PTV AG
There are no restrictions concerning the attributes you can use in a formula. You can use
formula attributes within other formula attributes to form more complex expressions. This
implies that you can also use brackets.
Example
2.3.4
Time-varying attributes
The procedures DUE (see "Dynamic User Equilibrium (DUE)" on page 389) and dynamic
stochastic assignment (see "Dynamic stochastic assignment" on page 419) allow you to model
time-dependent transport supply. In Visum, time-varying attributes are used for this purpose.
Time-varying attributes only affect these assignment procedures.
Otherwise time-varying attributes override the valid value of an attribute with a deviating value
for a certain amount of time. They can thus model, for example the impact of tidal flow lane
allocation or transient road works.
Time-dependent attributes can be assigned to the following network objects.
Links
Turns
Main turns
Nodes
Main nodes
For these network objects, only specific attributes can be time-varying, and the deviating value
of the attributes is not relevant to all procedures. The table 28 gives an overview of which
attributes can be time-varying in which assignment procedures. For details, please refer to the
description of the dynamic stochastic assignment (see "Dynamic stochastic assignment" on
page 419) and DUE (see "Dynamic User Equilibrium (DUE)" on page 389).
Network object
Time-varying attribute
Links
DUE
X
Toll-PrTSys
X
X
v0 PrT
TSysSet
AddValue 1-3
AddValue-TSys
Turns
Capacity PrT
TSysSet
PTV AG
105
AddValue 1-3
Main turns
Capacity PrT
t0 PrT
TSysSet
AddValue 1-3
Nodes
Capacity PrT
t0 PrT
AddValue 1-3
Main nodes
Capacity PrT
t0 PrT
AddValue 1-3
Table 28: Time-varying attributes and their allocation to assignment procedures
The example in table 29 illustrates the effect of time-varying attributes using the example of the
Dynamic Stochastic assignment. The upper image shows the volumes and the capacity PrT on
the links in time period from 5 am to 7 am. The lower image shows the volumes and the
capacity PrT in the time period from 7 am to 9 am (a constant time series has been used here
to simplify the comparison of both conditions, so that the traffic supply is the same in both of
the time intervals).
The links 11 - 41 and 41 - 40 are charged with the full capacity of 800.
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment
106
PTV AG
With the aid of a time-varying attribute for the capacity PrT on the two links (11-41 and 41-40), both links
are charged with a reduced capacity of 100. Therefore, the volumes of the links are lower.
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment
2.4
Subnetwork generator
With the Subnetwork generator add-on module, a subnetwork together with the associated
partial matrices can be generated from the overall network in such a way that, generally
speaking, comparable assignment results are obtained for the subnetwork.
The subnetwork is generated on the basis of the following rules:
PTV AG
The basis are all active links and all active line routes.
Apart from that, the following network objects are transferred to the subnetwork:
All From nodes and To nodes of the active links.
All junction editor / junction control data for nodes with at least one leg in the
subnetwork
Turns whose From link and To link belong to the subnetwork
All connectors at a node located in the subnetwork
All zones with connectors at a node located in the subnetwork
All PrT paths that belong to path sets
All count locations located on active links
All active POIs and, if applicable within the subnetwork; all references to nodes, links,
POIs, stop points and stop areas are copied
All screenlines
107
In addition, the following network objects are transferred from the entire network to the
subnetwork:
108
Demand segments
Modes
Transport systems
Link types
Main zones
Calendar periods
Valid days
Fare zones
Ticket types
Directions
Operators
Vehicle combinations
Vehicle units
Surfaces
Demand matrices
Time series
Demand time series
Activities, activity pairs, activity chains *
Person groups, structural properties *
Demand strata *
Skim matrices
Procedure parameters
PTV AG
Demand matrices
Apart from the selected partial matrices (see User Manual, Chpt. 2.44, page 726), all other
matrices that exist in the original network are saved to the subnetwork. The values of these
matrices are set to zero. In order to indicate that they are part of the subnetwork, a suffix is
attached to the matrix file names. If the version file contains references to matrices, they
are updated accordingly.
Example
Subnetwork version name: tgen_ver
Matrix file name in the original network: car.mtx
Matrix file name in the subnetwork: car_tgen.mtx
The subnetwork generator considers the paths of an existing assignment and generates new
zones at the networks interfaces at which traffic flows enter or leave the network. These
virtual boundary zones (subnetwork cordon zones) are added to the partial matrices of the
demand segments so that no traffic demand in the subnetwork is lost.
If all line routes of all links are active, the total of the stop point matrix equals the total of the
demand matrix.
For matrices on path level and path leg level the following applies: If the PuTAux transport
system is used in a PuT assignment, the subnetwork generator manages routes that contain
PuTAux as follows:
PTV AG
109
If there is a passive link on a route section that uses PuTAux, a subnetwork cordon zone is
generated at the From node of this link. As soon as the next active link is found, the
subnetwork generator creates another subnetwork cordon zone at the From node of that
link. The volume is transferred as demand data from one subnetwork cordon zone to the
next one.
In contrast, the following applies to the PuT Walk transport system: If there is at least one
passive link within a walk link, subnetwork cordon zones are created at the last stop point
before the walk link and at the next stop point after the walk link and not at the nodes of the
passive link, as for PuTAux.
The example in illustration 46 illustrates the differences. The Numbering of cordon zones
with offset option has been selected in order to clarify the connection with the nodes. The
offset specified is 10.
Walk link via active links
Zone
12
External zone
Node
Stop point
12
13
14
15
16
17
18
12
13
14
15
16
17
18
12 13 14 15 16 17 18
50
50
50
50
12
14
15
18
8
Stop point matrix:
12
14
15
18
12 14 15 18
50
50
Illustration 46: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths
Procedure parameters
All procedure parameters that exist in the original network are transferred to the
subnetwork. In order to indicate that they are part of the subnetwork, a suffix is attached to
the files that store procedure parameters.
110
PTV AG
2.5
2.5.1
Point
Edge
Edge item
Face
Face item
Surface
Surface item
Note: In Visum, you can save polygons together with the network object type using them to a
network file (see User Manual, Chpt. 1.4.6, page 48). However, thereby all polygons are
saved, independent of whether they were used for an object of the type specified or not.
Example
In the following example, the seven tables are displayed and explained for a network that
contains three main nodes with surfaces.
The network includes the three main nodes with the IDs 2, 3 and 4. These main nodes are
allocated via the SurfaceID attribute to the surfaces with the IDs 866, 867 and 868 (table 30).
* Table: Main nodes
$MAINNODE:NO;SURFACEID
2;866
3;867
4;868
Table 30: Table Main nodes
In the Surfaces table, all surfaces contained in the network are stored with their IDs. Since, in
the example, only the three main nodes have a surface, there are exactly three entries for the
main node surfaces in this instance (table 31).
* Table: Surfaces
$SURFACE:ID
866
867
868
Table 31: Table Surfaces
PTV AG
111
Each surface is composed of one or multiple faces. The allocation of surfaces to faces is
carried out in table Surface items. In the example, the surfaces 866 and 868 have exactly one
face, whereas surface 869 has two faces. Thus, there are four faces in total with the IDs 1139,
1141, 1144 and 1145 (table 32).
* Table: Surface items
$SURFACEITEM:SURFACEID;FACEID;ENCLAVE
866;1139;0
868;1141;0
869;1144;0
869;1145;0
Table 32: Table Surface items
In the Faces table, all faces contained in the network are stored with their IDs. In this example,
there are thus four faces (table 33).
* Table: Faces
$FACE:ID
1139
1141
1144
1145
Table 33: Table Faces
In the Face items table, each face is allocated the IDs of the edges which define the face. As
you can see in table 34, the faces with the IDs 1141, 1144 and 1145 are squares each, as they
are defined by four edges. Face 1139 however, is a pentagon with five edges.
* Table: Face items
$FACEITEM:FACEID;INDEX;EDGEID;DIRECTION
1139;1;33136;0
1139;2;33137;0
1139;3;33138;0
1139;4;33139;0
1139;5;33140;0
1141;1;33145;0
1141;2;33146;0
1141;3;33147;0
1141;4 33148;0
1144;1 33160;0
1144;2 33161;0
1144;3;33162;0
1144;4;33163;0
1145;1;33164;0
1145;2;33165;0
1145;3;33166;0
1145;4;33167;0
Table 34: Table Face items
The table Edges contains all edges which are required for the description of the face items.
Each edge is defined by a start point and an end point, which bear the attribute names
FromPointID and ToPointID in the table (table 35).
112
PTV AG
* Table: Edges
$EDGE:ID;FROMPOINTID;TOPOINTID
33136;9449;9450
33137;9450;9451
33138;9451;9452
33139;9452;9453
33140;9453;9449
33145;9458;9459
33146;9459;9460
33147;9460;9461
33148;9461;9458
33160;9473;9474
33161;9474;9475
33162;9475;9476
33163;9476;9473
33164;9477;9478
33165;9478;9479
33166;9479;9480
33167;9480;9477
Table 35: Table Edges
In the Points table, all points are displayed which in turn define the edges. Each one contains
information on the coordinates (XCoord and YCoord). This establishes the spatial reference of
the surface to the network (table 36).
* Table: Points
$POINT:ID;XCOORD;YCOORD
9449;3456991.5413;5430055.0204
9450;3456991.5413;5430004.3885
9451;3457052.3873;5429991.7699
9452;3457070.0872;5430048.9542
9453;3457026.8560;5430057.9988
9458;3458808.0227;5431086.8027
9459;3458821.3171;5431061.4225
9460;3458848.5102;5431078.9469
9461;3458835.5180;5431101.9100
9473;3456956.4483;5430005.5296
9474;3456948.8422;5430060.3735
9475;3456887.1928;5430052.7674
9476;3456903.2057;5429996.7225
9477;3456896.8005;5430097.6033
9478;3456938.0336;5430071.1821
9479;3456961.6525;5430097.6033
9480;3456945.2393;5430125.2254
Table 36: Table Points
No intermediate points were generated in the example. The table is therefore empty (table 37).
* Table: Intermediate points
$EDGEITEM:EDGEID;INDEX;XCOORD;YCOORD
Table 37: Table Intermediate points
PTV AG
113
2.5.2
Multi-part surfaces
A surface can be made up of several faces (multi-part surfaces). Generally, a multi-part surface
is defined by a set of so-called faces. Each face is a polygon with a sign. This is positive, if
coordinates encircle the polygon anti-clockwise and negative, if the coordinate sequence is
clockwise. Positive faces are thus digitalized anticlockwise, negative faces clockwise. This
way, the type of polygon is clearly defined when interactively modifying polygons in the network
display. This orientation of a face is thus a significant object feature. Positive faces add to the
surface, negative surfaces subtract from it (holes).
a n ti- c
c lo c
kwi
lo c k
w is e =
p o s it
iv
se =
neg
a t iv
anti-clockwise
= positive
Visum automatically normalizes the definition of any surface it encounters. Faces never
intersect and a positive face will always (directly) contain only negative faces and vice versa.
114
PTV AG
Specified surface
PTV AG
115
The simple example of the area calculation suffices to understand why a normalized
representation facilitates geometrical operations. The area of normalized surfaces results
directly from the sum of the areas of its faces. The sign depends directly on the orientation.
Without normalization, the areas of all occurring intersections of the faces would have to be
subtracted from the result. This would imply a significant increase in computation time.
Computation time particularly increases because the mere determination of the intersection of
sets with multiple overlaps is a complex algorithmic procedure.
116
PTV AG
2.5.3
The study area is a one-piece surface. The surrounding consists of two surface areas, the
outer, positive outline and a hole. The gap has the same edge points as the study area, but
its own face object, edges, points and intermediate points. This is because during
digitization of the surrounding, the existing edge points of the study area are snapped, but
the option Merge snapped points has not been activated. If one of the two surfaces is
digitized again later on, this does not affect the other surface. The edges of the two
surfaces do not remain congruent, but a gap or an overlapping area (or both) is created.
The study area consists of a one-piece surface that is also used as its negative face. This
is because during digitization of the surrounding, the existing edge points of the study area
are snapped and the option Merge snapped points has been activated. If one of the two
surfaces is digitized again later on, this will affect the other surface in terms of the face that
is used by both. The edges of the two surfaces still remain congruent, even after changes
have been made.
Which type of modeling is best suited depends on the individual case. However, it is always
helpful to combine points of the same coordinates into an object, if the surfaces have the same
borders. If you are working with larger models, the aspect of saving memory space may also
play a role. Since if points (intermediate points, edges, faces) are combined into an object, less
memory space is required.
You can also combine all points with identical coordinates of an existing network later on (see
User Manual, Chpt. 2.10.7, page 236).
PTV AG
117
118
PTV AG
Demand model
One of the main uses of Visum is modeling demand. Demand modeling deals with traffic
conditions. The most common travel forecasts analyze the daily travel behavior of people.
These forecasts provide answers to the questions, when, how often, where and how do people
travel.
Visum offers three demand modeling procedures.
The result of these procedures are matrices, which contain trips between the origin and
destination zones of the network. These matrices are assigned to one or more demand
segments. Assignment takes place on the basis of demand segments (see "User model PrT"
on page 211 and "User model PuT" on page 429).
It is not mandatory to create a separate demand model in Visum, which calculates the matrices
for the assignment. You can also use and assign matrices from external sources. Therefore, a
complete demand description in Visum (that of course allows you to calculate an assignment)
first only consists of the following elements:
There are several demand objects (see "Demand objects" on page 119) that allow you to
display the demand within the Visum data model. Which of these demand objects are applied
in your model, depends on the type of demand modeling in your network.
Subjects
3.1
Demand objects
Demand modeling procedures
Displaying and editing matrices
Matrix correction
Demand objects
A demand model consists of a set of demand objects which contain all relevant demand data,
for example, the origin and destination of demands and the number of them in demand
matrices. The demand object types in Visum are described below.
PTV AG
Matrices
119
Demand segments
Time series
Demand model structure
Person groups
Activities, activity pairs, activity chains
Demand strata
In addition, the EVA and tour-based demand models also contain the demand structural
properties (see "Structural properties" on page 132 and "Tour-based data model" on
page 161).
3.1.1
Matrices
Matrices are one of the most important components of demand models. There are several
matrix types:
Demand matrices are used to show the transport demand between origin and destination
zones.
Skim matrices show the origin-destination zone skims, e.g. the travel time.
Weighting matrices are only used to calculate the Weighting step of EVA-P demand models
(see "EVA model for passenger demand" on page 132).
In OD matrices, the demand is coded (by the number of trips) from origin zone i to destination
zone j. The temporal distribution of travel demand within the analysis period is described by a
start time and a time series that is considered during PuT assignment and dynamic PrT
assignments (see "Time series" on page 121). The demand distribution is ignored in the case
of static PrT assignments.
The Matrix editor integrated in Visum allows you to process existing matrix data and perform
calculations based on the gravity approach (see "Gravity model calculation" on page 174).
In Visum, OD matrices and time series are independent objects which can freely be allocated
to demand segments for assignment. This means that you can also use a matrix for more than
one demand segment.
Note: It is not mandatory to create a separate demand model in Visum, which calculates the
matrices for the assignment. You can also use and assign matrices from external sources.
3.1.2
Demand segments
A demand segment is a demand group or class, which is allocated in one step to a network,
because the demand is homogeneous to the group. Examples for a demand segment could be
pupils or commuters. The journey times from origin zones to destination zones are calculated
per demand segment (see "Demand segments" on page 36).
Demand segments are different from demand strata (see "Demand strata" on page 124).
Demand strata contain demand groups for the steps trip generation, trip distribution and mode
choice of the Standard 4-step model. Another important difference is that each demand
segment is assigned to exactly one mode (for example PrT or PuT).
120
PTV AG
The demand strata of a mode are generally aggregated to create demand segments. These
aggregated demand segments are then assigned to the network. Aggregation is possible since
the variables used to differentiate between the demand strata have no effect on the
assignment. Demand strata, for instance, are often distinguished by employment, e.g.
employees with a car and non-employees with a car. If the study area has no toll roads, the
employee status plays no role for route choice during the assignment. In other words:
Everyone chooses the same route between the origin and destination zone, irrespective of
their income level. So demand strata can be aggregated to a demand segment for assignment.
To calculate an assignment, the system needs to assign each demand segment exactly one
matrix (see "Matrices" on page 120). For dynamic PrT assignments and all PuT assignments,
a demand time series must also be assigned to each demand segment (see "Time series" on
page 121). Visum establishes the link between demand and transport supply.
Notes: A possibly specified time series is ignored in the case of static PrT assignments.
A matrix can also be assigned to several demand segments. The same applies to time series.
3.1.3
Time series
The temporal distribution of trip demand over the evaluation period is described using a start
time and a demand time series. The demand time series is considered for PuT assignment and
dynamic PrT assignment. The demand distribution is ignored in the case of static PrT
assignments (see "Temporal distribution of travel demand" on page 5 and "Time reference of
the demand (time series)" on page 86).
Note: A time series can also be assigned to several demand segments.
There are two types of standard time series:
3.1.4
Time series of matrix numbers, i.e. selection of several matrices that form the time series.
proportional time series of a demand matrix
with distribution of travel demand in time intervals (in percent)
if required modified per pair of zone type relation
PTV AG
Attribute
Description
Code (Key)
Name
Type
Type of calculation model (Standard 4-step, EVA passenger demand or Tourbased model)
Mode codes
121
3.1.5
Person groups
The population living in the planning area is broken down into so-called behaviorhomogenous groups. The traffic behavior of the different groups should be clearly different,
but within the individual groups it should be as homogenous as possible.
This documentation uses examples in which the person groups are normally broken down
according to the criteria employment/education and motorization. The following table shows a
division into groups with homogenous behavior and their codes (Schmiedel 1984).
Employees with car available
E+c
E-c
NE+c
NE-c
Apprentices
Appren
Stud
SPup
PPup
Child
Description
Code (Key)
Name
DemandModelCode
Abbreviation of the demand model the person group belongs to (any string), e.g.
DEFAULT
When using the Standard 4-step model, generally only one single person group is required, i.e.
there is a 1:1 relation between activity chain and demand stratum.
3.1.6
122
Work
Shopping
Education: university
Recreation
PTV AG
Home
Description
Code (Key)
Name
IsHomeActivity
This Boolean attribute is true (= 1) if the activity is the starting point and end point
of an activity chain. This is typically the case for the activity Home.
DemandModelCode
Abbreviation of the demand model the activity belongs to (any string), e.g. EVAP.
Note: Activities are optional and can be defined interactively only for EVA and tour-based
models. In case of Standard 4-step models one activity corresponds to exactly one activity
pair.
An activity pair corresponds to the trip between two successive activities in the daily routine of
a person.
The demand object activity pair is described by the following attributes:
Attribute
Description
Code (Key)
Name
DemandModelCode
Abbreviation of the demand model the person group belongs to (any string), for
example DEFAULT.
The following attributes describing activity pairs are only relevant for EVA models.
Attribute
Description
OrigActivityCode
Code of the activity where the trip starts, for example H (home)
DestActivityCode
Code of the activity where the trip ends, for example W (work)
OD type
An activity chain describes a sequence of typified activity pairs. For example, the chain home
work shopping home (HWOH). Such a sequence of activity pairs implies trips, in this
example here three different trips (HW, WO, OH).
The following attributes describe the demand object activity chain.
PTV AG
123
Attribute
Description
Code (Key)
Name
ActivityCodes
DemandModelCode
Abbreviation of the demand model the person group belongs to (any string), for
example DEFAULT.
In the tour-based demand model, the average mobility program of persons is described by
activity chains. The Standard 4-step model and the EVA model allow single-element activity
chains only. So an activity chain corresponds directly, i.e. 1:1, to the activity pair.
3.1.7
Demand strata
The demand stratum constitutes the basic demand object for calculating trip generation, trip
distribution and mode choice. It links an activity chain with one or several person groups (in the
tour-based model with exactly one person group). The pointers to activity chains and person
groups in the Standard 4-step model are optional.
The correlations between demand objects can be depicted graphically as follows (see
"Correlations between different demand objects" on page 124).
Activity
e.g. Work
1
OrigActivity n
n DestActivity
Activity Pair
e.g. HW
n
m
Standard-4-Step Model
and EVA Model:
1 : 1 (=Activity Pair)
Activity Chain
e.g. HW-WH
Person group or
Household group
Person Group
e.g. E+c
n
n
m
Demand Stratum
e.g. HW-WH x E+c
124
Attribute
Description
Code (Key)
ActChainCode
DemandGroupCodes
Name
PTV AG
Attribute
Description
DemandModelCode
DistribMatrixNumber
DemandTimeSeriesNumber
The following attributes describing demand strata are only relevant for EVA models.
Attribute
Description
3.2
Balancing
Quantity as potential
PTV AG
125
There are also the following functions available to calculate the transportation demand:
3.2.1
126
PTV AG
production
rates
zone
attributes
(inhabitants,
jobs)
Trip generation
skim
matrix
utility
function
production
& attraction
(per zone)
Trip distribution
skim matrix
per mode
utility
function
demand
matrix
Mode choice
Per
demand
segment
demand
matrix
Assignment
demand
matrix
demand
matrix
Assignment
demand
matrix
Assignment
PTV AG
127
In the normal case carry out each of the operations trip generation, trip distribution and mode
choice for all demand strata of the model. For special purposes, however, they can also be
carried out for individual demand strata if the required input attributes are known.
If necessary, operations on matrices may be fitted in between the individual stages, for
example in order to prepare skim matrices (e.g. setting the values on the matrix diagonal) or to
add externally predetermined demand data (e.g. through-traffic) (see "Displaying and editing
matrices" on page 184).
3.2.1.1
Trip generation
In that stage for each zone and each demand stratum the origin and destination volumes are
calculated. These parameters are also called productions and attractions. The productions
either correspond to the actual origin traffic of the zone i.e. the number of trips starting there,
or the attractiveness of the zone for the demand stratum, meaning they have an influence on
the probability of trips starting in that zone with the next Trip distribution procedure. Which of
the two cases applies can be determined by a procedure parameter of Trip distribution. The
same holds for destination traffic.
The productions of a demand stratum in a zone depend on its structural or demographical
indicators describing the intensity of the production activity. For the production activity Home
the number of inhabitants of a zone, if necessary, disaggregated into age, income and/or car
availability can be used. For the production activity Work the number of jobs may be
appropriate, perhaps broken down into different sectors. For such skims user-defined zone
attributes are the best. First, production Qi of zone i is calculated with the help of a formula,
Qi = g SGg (i )
g
whereby SGg is summed up across all structural properties. SGg(i) corresponds to the value of
SGg in zone i. The coefficient g is a production rate that shows the number of trips per
128
PTV AG
structural property unit. They specify the production rates per demand stratum and zone
attribute used. The same calculation is performed for the attraction Zj.
In most applications the total production of a demand stratum (added up over all zones)
corresponds to the total attraction.
Qi = Z j
i
If equality has not already been the outcome of the attributes and production rates used, it can
be set by means of a procedure parameter whether all productions and attractions have to be
scaled so that their totals are equal. As reference values you can predetermine total
productions, total attractions or the minimum, maximum or mean value of both parameters.
You can limit calculation to the active zones. This might be useful in cases where the network
model covers both the actual planning area and its surrounding sub network cordon zones. If
you only want to calculate planning area-internal trips by means of the demand model, first of
all define a filter for the zones of the planning area only. Proceed in a similar way if the
production rates are not uniform for all zones. Break the zones down into groups of
homogeneous production rates and insert the operation trip generation for each of the groups
into the process. Prior to each such operation set a filter for the zones of that group (operation
Read filter (see User Manual, Chpt. 2.7.5.2, page 208)) and calculate trip generation only for
the respective active zones.
For each zone the results of trip generation are stored per demand stratum in the zone
attributes productions and attractions.
3.2.1.2
Trip distribution
The productions and attractions calculated in the operation trip generation only determine the
constraints of the total demand matrix of a demand stratum. The elements of the matrix
themselves are calculated in the operation trip distribution. On the one hand, the allocation of
a certain destination zone to a given origin zone is based on its attractiveness for the demand
stratum (measured by its destination demand = attractions), on the other hand the impedance
of the trip from origin to destination zone is vital (measured by the skim matrices for journey
time, fares and other elements of generalized costs).
These input data being available, a gravity model is formulated and solved (see "Gravity model
calculation" on page 174).
Notes:
Origin and destination traffic of the individual zones have to be available per demand
stratum as zone attributes productions and attractions.
To each demand stratum for which Trip distribution is to be calculated a demand matrix
has to be allocated into which the results are stored.
The parameters for the gravity model can be estimated beforehand (see "Estimate
gravitation parameters (KALIBRI)" on page 173).
PTV AG
129
3.2.1.3
Mode choice
The operation Mode choice breaks down the total demand (total demand matrix) into the
individual transport modes per demand stratum (for example PrT, PuT) based on modespecific impedance skims (for journey time, costs, etc.).
First of all for each mode m the utility is calculated as a linear combination of the impedance
parameters.
U ijm = g cijmg
g
Whereby
The impedance of the cost type g for the trip from zone i to zone j by mode m.
cijmg
The respective shares of the trips of each relation result from the utilities of the different modes.
Hereby, you can choose between several distribution functions (see "Gravity model
calculation" on page 174). As an example see below the calculation for the Logit model.
p ijm =
c U ijm
c U ijk
k
Tijm = p ijm Tij
whereby Tij is the total number of trips of the demand stratum in the relation i-j, Tijm is the
number of trips made by mode m and c is a procedure parameter.
There are two types of demand strata.
Those referring directly to a demand matrix allocated to one single demand segment or
several demand segments
Those whose demand matrix is not related to any demand segment
No mode choice will be calculated for demand strata referring directly to a matrix with demand
segment(s).
For demand strata whose demand matrix is not related to any demand segment it is
determined per mode to which demand matrix the demand allocated to that mode has to be
added in mode choice.
3.2.1.4
For nested mode choice, the total demand (total demand matrix) per demand stratum is
distributed to the transport modes defined in the network (for example car PrT, bus PuT), using
mode-specific skims of several stages (illustration 51).
130
PTV AG
For the Logit model (mode choice), the decision model determines the utility of a leaf node as
usual through a linear combination of skim matrices of the respective mode. For a nest node,
the utility consists of two components:
Nest utility that does not depend on the individual sub-node, e.g. fare.
Summary of individual utility of all sub-nodes, e.g. travel time.
This leads to
As a result, the procedure calculates a demand matrix for each leaf node and - optionally - also
for each nest node.
For each leaf node or nest node, the calculated result can be saved to an existing skim matrix
for further analyses (Ortzar 2001, pages 228-235).
3.2.1.5
Time-of-day choice
By trip distribution or mode choice, demand matrices can be calculated which are used by
demand segments for assignments (see "Trip distribution" on page 129 and "Mode choice" on
page 130). In addition to the demand matrix further entries may be required for an assignment.
A demand segment can refer to a time series for an analysis time interval dependent
assignment.
With operation Time-of-Day Choice, a demand matrix of a demand segment can be spread
over the time intervals of a standard time series. This standard time series can then be used
as demand time series in PuT assignments or in the dynamic PrT assignments.
PTV AG
131
3.2.2
If trip generation and trip distribution are calculated independently, i.e. one after the other
and above all separately for each activity pair as in the Standard 4-step model, it often
happens that differences occur between the origin and destination traffic of the zones. The
EVA model links generation and distribution by an explicit constraints step to make up for
the differences.
In the EVA model trip distribution and mode choice are performed simultaneously, i.e. by
applying a one-stage discrete choice model to three-dimensional utility matrices indexed
according to origin zone, destination zone and mode.
3.2.2.1
The data model for EVA also comprises the relevant demand object types (see "Demand
objects" on page 119) for other models such as the additional demand object types structural
property. Compared to the standard-4-stage model, these demand objects have some
additional attributes in the EVA model. These attributes have an effect on EVA trip generation
(see "EVA trip generation" on page 135).
Meaning
Activity
IsHomeActivity
bool (0,1)
Activity pairs
OD type
{1, 2, 3}
Structural properties
Structural properties are used to measure the zone attractiveness as origin or destination of a
journey, they e.g. include sales floor areas or the number of school places. Structural
properties are very simple demand objects, their only attributes are a code and a name.
Instead, you could also use user-defined zone attributes. However, defined as structural
properties, they better reflect their role in the demand model.
To each structural property SP defined in the demand model the numerical zone attribute
ValueStructuralProp(SP) in which the values of the structural property per zone can be filed
is created automatically.
132
PTV AG
Demand strata
Demand strata, too, have several additional properties, particularly in connection with their
constraints. Moreover, demand strata refer to an activity pair having an origin-destination type.
Since that type determines the treatment of the demand strata in the different operations and
therefore is referred to frequently, it is called the origin-destination type of the demand stratum
itself below.
PTV AG
Attribute
Origin Structural
Property Codes
Destination Structural
Property Codes
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
133
Attribute
Zones
Due to the definition of the objects of the demand model several zone attributes are created.
134
Attribute
Subattribute
Balance factor
Productions
Demand stratum
Balance factor
Attractions
Demand stratum
Demand stratum
Demand stratum
Demand stratum
PTV AG
Attribute
Subattribute
Demand stratum
Number of persons
Person group
Structural property
value
Structural
property
Mobility rate
Demand stratum
Person group
Production rate
Demand stratum
Structural
property
Attraction rate
Demand stratum
Structural
property
Demand stratum
Person group
Demand stratum
Structural
property
Demand stratum
Structural
property
3.2.2.2
In the EVA model and Standard 4-step model, productions and attractions are calculated
similarly, namely based on demographic (number of inhabitants) and structural (jobs, size of
retail sales floor, ) parameters as well as on mobility rates (taken from statistical surveys on
traffic behavior). It is performed separately for each demand stratum, which means for each
activity pair and its major person groups.
In EVA trip generation productions and attractions normally refer to a closed time interval with
regard to traffic (generally the average working day). The following model stages, EVA
Weighting and EVA Trip distribution and Mode choice, too, refer to the overall period. The
demand matrices available at the end of the model chain only can be combined with an
empirically determined or standardized daily time series (illustration 52) to get the shares of
demand for the individual times of the day. The daily time series depend on the demand
stratum.
PTV AG
135
Illustration 52: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden)
The following table shows the allocation of activities, activity pairs, structural properties and
person groups on demand strata. Thereby the abbreviations used stand for the following: H:
Home; W: Work; C: Child care facility, S: School; F: Shift; P: Shopping; R: Recreation; O:
Others.
From/To
H
W
WH
CH
SH
FH
PH
RH
OH
HW
HC
HS
HF
HP
HR
HO
WO
OW
OO
Table 39: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs
Demand stratum
136
HW
Employees
HC
Young children
HS
HF
Employees
HP
Inhabitants
HR
Inhabitants
HO
Inhabitants
WO
Jobs
PTV AG
Demand stratum
WH
Jobs
CH
Jobs / capacity
SH
Jobs / capacity
FH
Jobs
PH
RH
Jobs / capacity
OH
Other jobs
OW
Other jobs
OO
Other jobs
DStr
HW
Jobs
HC
Jobs / capacity
HS
Jobs / capacity
HF
Jobs
HP
HR
Jobs / capacity
HO
Other jobs
WO
Other jobs
WH
Employees
CH
Young children
SH
FH
Employees
PH
Inhabitants
RH
Inhabitants
OH
Inhabitants
OW
Jobs
OO
Other jobs
Table 40: Examples of relevant structural properties and person groups of the demand strata
Thus, for the demand strata HW and WH only the Employees person group (which could be
broken down into further subgroups) is relevant, whereas for the demand strata HO and OH
generally all person groups are relevant. The number of persons of all person groups in each
zone make up an important part of input attributes for the trip generation of a certain demand
stratum. Further structural properties measure the intensity of the activities at the origin or
destination. An example of the allocation of certain structural properties to individual demand
strata is illustrated by table 40.
PTV AG
137
The person groups specified here can be broken down into further subgroups according to
other features (car availability, age) and used for trip generation.
For each demand stratum and each relevant person group mobility rates have to be defined.
The mobility rate of a person group is defined as the average number of trips per day and
person.
MR pc =
In most cases, the MRpc values are known from national surveys on traffic behavior and are
assumed to be constant for all zones of the study area. If the individual zones feature different
specific traffic demands, for example distinguishing between urban and rural areas, they can
be used, too. Then MRepc specifies the particular demand of the person group or reference
person group p in zone e (in a certain demand stratum c).
Analogously production rates defined as the number of trips per day and structural property
are determined for the major structural properties like number of jobs, sales floor, etc.. To do
so empirical studies or available historical values can be referred to. Here, too, a differentiation
according to zones is possible. The structural potential of the zone results from the value of the
structural property and the related production rate.
A certain number of trips of the total production of a zone remains within the study area only,
the rest targets destinations outside. The same holds for destination traffic. Since the EVA
Model usually serves the calculation of study area-internal traffic (incoming and outgoing traffic
as well as through-traffic are often added by other sources), the share of trips of the total origin
(or destination) traffic made within the study area can be determined for all origin (or
destination) zones.
Example: The origin traffic of the demand stratum of Home-Work (HW) results from the number
of persons of the person group of Employees (EP) and the mobility rate MREP,HW. In a zone R
on the edge of a study area, however, part of the employees will commute to destination zones
outside the study area. It is not available for a later trip distribution and mode choice. In that
case, the study area factor UR,EP,HW is below 1, conveying that only that share of trips remains
within the study area. For a zone Z in the center, however, all trips of the demand stratum lie
within the study area. Therefore the following applies: UZ,EP,HW = 1. Study area factors do not
only depend on the zone but also on the demand stratum and the person group. It is more
probable that employees with car (E+c) commute over great distances and therefore to
destinations outside the study area than those without car (E-c). If you differentiate these two
person groups in the model, then would typically be UR,E-c,HW > UR,E+c,HW. And in analogy
hereto would be UR,Child,HC > UR,E+c,HW, because child care facilities are rather found in the
proximity of homes than jobs.
As the mobility rate of a person group the production rate of a structural property, too, can have
partial impacts in the study area only. So, for example, the structural potential of the demand
stratum HW is determined by the number of jobs (structural property J) and the related
production rate. On the edge of the study area part of the jobs are taken by employees living
outside the study area. Therefore, these jobs are not available as potential destinations of HW
trips of the study area. Therefore, in that case, too, the total structural potential is multiplied by
a study area factor VR,J,HWA < 1.
138
PTV AG
You can limit calculation to the active zones. This allows you to e.g. exclude cordon zones from
the calculation.
In the trip generation stage (table 41, table 42 and table 43) from the structural data and values
mentioned for all demand strata c, the productions Qic and attractions Zjc or the upper limits
The calculation specifications can be taken from table 41, table 42 and table 43. For the types
1 and 2 calculation starts with the home trips (of number of persons, mobility rate, study area
factor) which independently from the travel direction always occur in the origin zone. For type
1 the number of trips corresponds exactly to the production, for type 2 to the attraction of the
respective zone. For type 1 the total production (of all zones) is distributed onto the destination
zones, in proportion to their potentials (taken from structural properties, production rates and
study area factors). Type 2 is treated equally. The total attraction is distributed proportionally to
the potentials onto the origin zones. For type 3 total volume is equally calculated on the basis
of the total home trips. However, the sizes of the road users origin zones are relevant, which
do not have to correspond with origin or destination of the trip. Proportionally to the potential
the total volume is then distributed onto the origin zones on the one hand and onto the
destination zones on the other hand.
The productions and/or attractions so calculated can have various meanings.
Hard constraints
Traffic demand solely results from the spatial structure and has to be fully exhausted by the
trips calculated in the model.
Example: if the number of employed inhabitants and jobs per zone is known, hard
constraints will be applicable to the demand stratum Home Work (HW), since every
employed person necessarily has to commute to work and each job has to be destination
of commutation.
Weak constraints
Traffic demand does not only depend on the spatial structure but also on the convenience
of the location and the resulting competitive conditions. In these cases traffic demands
resulting from trip generation are like upper limits. With Trip distribution and Mode choice it
turns out to which extent the limits will be exhausted by the actually determined origin and/
or destination traffic.
The structural potential of the destination zone for the demand stratum Home Shopping
(HP) is usually calculated based on the structural property of sales floor and a production
rate for example. It is conceivable that there may be overabundance of sales floor so that
the shopping facilities are not used to their full potential. Therefore, the attraction calculated
by trip generation from the potential only constitutes an upper limit for real destination
traffic. Therefore, the constraint is hard on the destination side, whereas weak on the origin
side, because each road user has to shop (somewhere).
PTV AG
139
Elastic constraints
Open constraints
The potential of the structural properties merely represents the attractiveness of the zone
as an origin or destination of a demand stratum. Production or attraction, however, are not
linked to any constraint.
The attractiveness of some destinations in recreational traffic can even be measured by
means of their attributes if capacity impacts do not play a role. For example, the structural
potential of a nearby recreational area can be determined by its forest. During trip
distribution this attractiveness is to impact as potential of the destination zone, but no
constraints are linked herewith because there is neither a minimum number of persons
seeking recreation nor do visitors go to other places, because the "capacity" of the forest is
fully exhausted.
In table 41, table 42 and table 43 the calculation formulas are listed up separately for the cases
for which they differ.
Step 1
Home trips H
Step 2
Production Q, Qmax
Q ic = H ic
Step 3
Total volume V
Vc =
fc =
Q ic
i =1
Vc
140
PTV AG
Step 4
Attraction Z, Zmax
ER jsc SG js v jsc
sS
max
b ) Z jc Z max
jc = ER jsc SG js v jsc
sS
jc = ER max
jc Z jc Z jc Z jc
c )Z
jsc SG js v jsc ; Z jc Z
sS
d ) Z pot
jc = ER jsc SG js v jsc
sS
a ) Z jc = f c
Step 1
Home trips H
Step 2
Attraction Z, Zmax
Z jc = H jc
Step 3
Total volume V
Vc =
fc =
Z jc
j =1
Vc
Production Q, Qmax
c )Q
is isc ic Qic Qic Qic Q
ic
ic
sS
pot
d )Q
= ERisc SGis visc
ic
sS
a ) Q = fc
ic
PTV AG
141
Step 1
Home trips H
Step 2
Total volume V
Vc =
Step 3
H ec
e =1
Production Q, Qmax
ER jsc SG js v jsc
Z jc =
sS
Vc
sS
142
e
i
j
s
p
c
m
MRepc
ERisc
BPep
SG
uepc
Structural property
visc
Hepc
Hec
Qic
Zjc
PTV AG
Qicmax
Zjcmax
Q ,Qic
ic
Z jc , Z jc
Qicpot
Zjcpot
Vc
fc
V =
Qi
i
Zj
j
for the
Qic*,
Zjc
When analyzing the passenger demand flows it turns out that certain activity chains dominate
in the course of a day. So, for example, the chain of H W - P H occurs more often than the
chain of H P W H. With this, imbalances in the respective demand stratum pairs arise (for
example HW compared to WH) that are expressed in mobility or production rates.
Consequently, when calculating the total production of a certain zone i across all demand
strata, this sum does generally not correspond to the total attraction. This, however, should be
the case for a period considered closed with regard to traffic. Hence, in the EVA model, the
production or attraction of a selected ca demand stratum of the type 3 (mostly Others Others,
OO) is modified, so that the total production equals the total attraction across all demand
strata. This procedure is called balancing (see "EVA trip distribution and mode choice" on
page 152).
Balancing can either be performed after trip generation or trip distribution and mode choice. It
takes place after trip generation if the following conditions are fulfilled.
The total volume in ca is higher than the difference between production and attraction that
needs to be balanced.
All modes are interchangeable.
Q*i =
Qic Z *i = Z ic
c ca ;
c ca
PTV AG
143
~
~
3. Correction of traffic volume in ca, whereby Qica and Zica are "preliminary" values taken
from the formulas in table 41, table 42 and table 43.
*
*
1
1 ------Q ic = Q
Q l + Z i
ic a
V c l
a
a
1
*
*
Z ic = Z ica 1 ------- Z l + Q i
Vc
a
l
a
If there are non-interchangeable modes, you need to perform the balancing procedure for each
of them individually. Then you perform a single balancing procedure for the sum of all
interchangeable modes. This, however, is only possible during distribution and mode choice.
The following example will illustrate the method. For simplification it is limited to five demand
strata covering all origin-destination types.
Activity
No.
Code
OD type
Person group
Origin
Destination
Origin zone
HW
Home
Work
Employees
HO
Home
Others
Inhabitants
WH
Work
Home
Employees
OH
Others
Home
Inhabitants
OO
Others
Others
Inhabitants
Origin zone
Destination zone
Code
HW
OD type
1
Like home
Jobs
HO
Like home
WH
Jobs
Like home
OH
Like home
OO
The model covers 18 zones, 10 of which belong to the actual study area (type 1) and 8 zones
form a cordon around them (type 2). The zones of type 1 feature study area factors of 1.0,
those of type 2 of 0.9. The relevant zone attributes are set as follows.
Zone
144
Type
Inhabitants
Employees
Jobs
Jobs tertiary
7,000
3,000
2,000
1,100
10,500
5,500
7,000
4,500
7,000
3,000
2,000
1,300
5,000
2,000
1,700
1,000
PTV AG
Zone
Type
Inhabitants
3,000
Employees
Jobs
2,000
900
1,600
1,000
500
200
2,000
1,200
1,200
Jobs tertiary
2,500
1,600
5,000
2,000
1,000
600
7,000
3,100
2,500
1,400
10
5,000
2,000
1,500
1,000
11
3,500
1,200
1,000
600
12
3,000
1,100
1,000
600
13
2,500
1,000
1,000
600
14
1,500
700
500
100
15
1,500
600
500
100
16
2,000
900
1,000
600
17
2,000
800
500
300
18
2,000
800
500
300
Depending on demand stratum and zone type the following mobility rates are applicable (trips
per person in relevant person group).
Zone type
HW
HO
WH
OH
OO
0.7800
0.9000
0.6200
0.9000
0.6000
0.8100
0.9000
0.6400
0.9000
0.6000
The production rates of the structural properties equally depend on demand stratum and zone
type.
Demand stratum
Structural property
HW
HO
OO
PTV AG
Zone type 2
1.00
1.00
Inhabitants
0.50
0.50
0.50
0.50
WH
OH
Zone type 1
1.00
1.00
Inhabitants
0.50
0.50
0.50
0.50
Inhabitants
0.50
0.50
0.50
0.50
145
All demand strata feature hard constraints. This results in the productions and attractions of the
demand strata displayed in the following table, from the formulas in table 41, table 42 and
table 43. For clarification the respective step of the calculation process is indicated on top of
each column.
H = Home trips
Q = Production
Z = Attraction
QP = Structural potential origin
ZP = Structural potential destination
Demand stratum
HW
Origin
Like home
Jobs
Destination
Zone
Zone Type
ZP
2,340
2,340
2,000
1,578
4,290
4,290
7,000
5,523
2,340
2,340
2,000
1,578
1,560
1,560
1,700
1,341
936
936
2,500
1,972
702
702
1,600
1,262
156
156
2,000
1,578
1,560
1,560
1,000
789
2,418
2,418
2,500
1,972
10
1,560
1,560
1,500
1,183
11
875
875
900
710
12
802
802
900
710
13
729
729
900
710
14
510
510
450
355
15
437
437
450
355
16
656
656
900
710
17
583
583
450
355
18
Total
146
Home
Employee
s
583
583
450
355
23,038
23,038
29,200
23,038
PTV AG
Demand stratum
HO
Person groups or
structural property
Calculation step
Home
Origin
Inhab.
Like
home
Destinati
on
Jobs in tertiary sector and inhabitants
3.1
3.2
Zone
Zone Type
ZP Inh.
ZP Jobs
tert
ZP Total
6,300
6,300
3,500
550
4,050
5,796
9,450
9,450
5,250
2,250
7,500
10,733
6,300
6,300
3,500
650
4,150
5,939
4,500
4,500
2,500
500
3,000
4,293
2,700
2,700
1,500
800
2,300
3,292
1,800
1,800
1,000
500
1,500
2,147
450
450
250
600
850
1,216
4,500
4,500
2,500
300
2,800
4,007
6,300
6,300
3,500
700
4,200
6,011
10
4,500
4,500
2,500
500
3,000
4,293
11
2,835
2,835
1,575
270
1,845
2,640
12
2,430
2,430
1,350
270
1,620
2,318
13
2,025
2,025
1,125
270
1,395
1,996
14
1,215
1,251
675
45
720
1,030
15
1,215
1,251
675
45
720
1,030
16
1,620
1,620
900
270
1,170
1,674
17
1,620
1,620
900
135
1,035
1,481
18
Total
1,620
1,620
900
135
1,035
1,481
61,380
61,380
34,100
8,790
42,890
61,380
Demand stratum
WH
Home
PTV AG
Destination
Origin
Like home
Jobs
Zone
Zone Type
QP
1,860
1,860
2,000
1,253
3,410
3,410
7,000
4,384
1,860
1,860
2,000
1,253
1,240
1,240
1,700
1,065
147
744
744
2,500
1,566
558
558
1,600
1,002
124
124
2,000
1,253
1240
1,240
1,000
626
1,922
1,922
2,500
1,566
10
1,240
1,240
1,500
939
11
691
691
900
564
12
634
634
900
564
13
576
576
900
564
14
403
403
450
282
15
346
346
450
282
16
518
518
900
564
17
461
461
450
282
18
461
461
450
282
18,288
18,288
29,200
18,288
Total
Demand stratum
OH
Person groups or
structural property
Calculation step
148
Home
Destinati
on
Origin
Inhab.
Like
home
3.1
3.2
QP Inh.
QP Jobs
tert
QP Total
Zone
Zone Type
6,300
6,300
3,500
550
4,050
5,796
9,450
9,450
5,250
2,250
7,500
10,733
6,300
6,300
3,500
650
4,150
5,939
4,500
4,500
2,500
500
3,000
4,293
2,700
2,700
1,500
800
2,300
3,292
1,800
1,800
1,000
500
1,500
2,147
450
450
250
600
850
1,216
4,500
4,500
2,500
300
2,800
4,007
6,300
6,300
3,500
700
4,200
6,011
10
4,500
4,500
2,500
500
3,000
4,293
11
2,835
2,835
1,575
270
1,845
2,640
12
2,430
2,430
1,350
270
1,620
2,318
13
2,025
2,025
1,125
270
1,395
1,996
14
1,215
1,215
675
45
720
1,030
PTV AG
15
1,215
1,215
675
45
720
1,030
16
1,620
1,620
900
270
1,170
1,674
17
1,620
1,620
900
135
1,035
1,481
18
1,620
1,620
900
135
1,035
1,481
61,380
61,380
34,100
8,790
42,890
61,380
Total
Demand stratum
OO
Home
Origin
Calculation step
2.1
2.2
2.3
Zone
Zone Type
QP Inh.
QP Jobs
tert
QP Total
4,200
3,500
550
4,050
3,864
6,300
5,250
2,250
7,500
7,156
4,200
3,500
650
4,150
3,959
3,000
2,500
500
3,000
2,862
1,800
1,500
800
2,300
2,194
1,200
1,000
500
1,500
1,431
300
250
600
850
811
3,000
2,500
300
2,800
2,671
4,200
3,500
700
4,200
4,007
10
3,000
2,500
500
3,000
2,862
11
1,890
1,575
270
1,845
1,760
12
1,620
1,350
270
1,620
1,546
13
1,350
1,125
270
1,395
1,331
14
810
675
45
720
687
15
810
675
45
720
687
16
1,080
900
270
1,170
1,116
17
1,080
900
135
1,035
987
18
Total
1,080
900
135
1,035
987
40,920
34,100
8,790
42,890
40,920
Demand stratum
OO
Destination
PTV AG
3.2
3.3
149
Zone
Zone Type
ZP Inh.
ZP Jobs tert
ZP Total
3,500
550
4,050
3,864
5,250
2,250
7,500
7,156
3,500
650
4,150
3,959
2,500
500
3,000
2,862
1,500
800
2,300
2,194
1,000
500
1,500
1,431
250
600
850
811
2,500
300
2,800
2,671
3,500
700
4,200
4,007
10
2,500
500
3,000
2,862
11
1,575
270
1,845
1,760
12
1,350
270
1,620
1,546
13
1,125
270
1,395
1,331
14
675
45
720
687
15
675
45
720
687
16
900
270
1,170
1,116
17
900
135
1,035
987
18
Total
900
135
1,035
987
34,100
8,790
42,890
40,920
Since all demand strata feature hard constraints, balancing can be performed immediately
after trip generation. First of all the total origin and destination traffic of each zone and of the
demand strata HW, HO, WH, OW is calculated and the resulting differences are compensated
in the OO demand stratum.
Note: Note that neither total origin and nor total destination traffic of this demand stratum
change.
Total HW+HO+WH+OH
150
Differences
Zone
16,800
14,422
2,378
26,600
31,373
4,773
16,800
14,709
2,091
11,800
10,993
807
7,080
10,121
3,041
4,860
6,558
1,698
1,180
5,263
4,083
11,800
9,429
2,371
PTV AG
16,940
15,559
1,381
10
11,800
10,710
1,090
11
7,236
6,555
681
12
6,296
5,911
385
13
5,355
5,267
88
14
3,344
2,698
646
15
3,213
2,698
515
16
4,415
4,623
208
17
4,284
3,599
685
18
4,284
3,599
685
Total
164,086
164,086
13,804
13,804
OO before balancing
Zone
OO after balancing
Z
3,864
3,864
2,561
4,938
7,156
7,156
9,515
4,742
3,959
3,959
2,624
4,715
2,862
2,862
1,897
2,704
2,194
2,194
4,495
1,454
1,431
1,431
2,646
948
811
811
4,621
537
2,671
2,671
1,770
4,141
4,007
4,007
2,655
4,036
10
2,862
2,862
1,897
2,987
11
1,760
1,760
1,166
1,848
12
1,546
1,546
1,024
1,409
13
1,331
1,331
882
970
14
687
687
455
1,101
15
687
687
455
971
16
1116
1116
948
740
17
987
987
654
1,339
18
987
987
654
1,339
Total
40,920
40,920
4,0920
40,920
The results of operation EVA trip generation are stored in zone attributes.
PTV AG
Attribute
Subattribute
HomeTrips
Demand stratum
151
Attribute
Subattribute
ProductionsTarget
Demand stratum
AttractionsTarget
Demand stratum
Productions
Demand stratum
Attractions
Demand stratum
3.2.2.3
In gravity models, trip distribution or destination choice is made according to the bilinear
approach (for example Kirchhoff 1970), using various evaluation or utility functions Wij.
Tij = Wij fq i fz j
Wij fqi fz j
( i = 1,..., m; j = 1,..., n)
Tij = Qi
j =1
j =1
m
m
Wij fqi fz j = Tij = Z j
i= 1
i =1
Hereby Tij is the number of trips from i to j, Wij is the cost function for the trip from i to j, Qi is
the production of zone i and Zj is the attraction of zone j. The factors fqi, fzj are calculated so
that productions and attractions are kept as marginal sums.
The EVA model generalizes this approach of a simultaneous trip distribution and mode choice
to a trilinear model.
Tijk = Wijk fqi fz j fa k
Wijk
fqi fz j fa k =
Tijk = Qi
j =1 k = 1
j =1 k =1
m p
m p
Wijk fqi fz j fa k = Tijk = Z j
i= 1 k = 1
i =1 k =1
m n
m n
Wijk fqi fz j fa k = Tijk = VK k
i= 1 j = 1
i =1 j =1
152
PTV AG
Here, index k is the mode (means of transport) and Wijk assesses the costs for the trip from i to
j by modes k. For each demand stratum c there is a separate equation system to be solved
independently. For more clarity index c has been dropped for all variables in the problem
formulations above.
For the trilinear case, besides origin and destination traffic, the total number VKk of trips with
mode k is required. There are two possibilities.
If EVA trip distribution and mode choice for the analysis case is performed, which means
without having run a pre-calculation for the same study area, specify the modal split as
input data.
If, however, a forecast case is calculated, the modal split of the analysis case can be reused. You thus assume that the modal split may change on single relations, but modal split
of the whole model (including all relations), however, remains unchanged.
The problem formulation is applicable in case of hard constraints. For weak, elastic or open
constraints equations will be replaced by inequations in the side conditions or a side condition
will be dropped completely. This will be dealt with when describing the problem solutions.
The models can be justified by the probability theory using Bayes axiom or the information
gain minimization. Both ways lead to the same result.
Minimizing the gain of information has the target that the deviations from a priori assessments
of trip relations which would lead to the actually desired trips road users have to experience are
as minor as possible, but which have become necessary due to the constraints of the system.
The demand matrix T can be interpreted as the solution to the convex optimization task
pijk
Minimum
I = pijk ld
wijk
ijk
Tijk
;
V
Wijk
Wrsl
rsl
taking account of the constraints. The solution is the trilinear equation system previously
determined.
with pijk =
wijk =
The parameter I represents the information gained through the replacement of distribution wijk
(solely determined by the weighting matrix) by distribution pijk (additionally derived from
marginal totals).
PTV AG
153
aA
f a ( c aijk )
Here Mijk stands for the availability of mode k on OD pairs (i,j) and Cijk stands for the capacity
utilization of mode k on (i,j). a, a and a are the predefined assessment types: journey time,
competing walk time and external weighting matrix. A is the number of user-defined
assessment types.
Mijk and Cijk are defined independently from the demand stratum as follows:
OD type
Type 1
Mijk = mk(i) for all j, i.e. value of zone attribute mk set for source zone i
Cijk = ck(j) for all i, i.e. value of zone attribute ck set for destination zone j
Type 2
Mijk = mk(j) for all i, i.e. value of zone attribute mk set for destination zone j
Cijk = ck(i) for all j, i.e. value of zone attribute ck set for source zone i
Type 3
n mk ( n ) hn P nik P jnk
M ijk = --------------------------------------------------------------- hn
n
aA
f a ( c aijk )
For demand strata of the origin-destination type 3 (which are calculated accounting for the
home zone), the assessment type External weighting matrix is used to produce a specific
weighting between zones and modes. This weighting has an immediate impact on the total
product, since it is not part of the scaling using home zones, as in the formula for Mijk. In all
other cases, this assessment type has the same effect as a user-defined one.
You can use different function types as fa evaluation functions. All distribution functions of the
gravity model (cf. chap. 5.1.4.17) can be taken, but additionally the EVA1, EVA2, Schiller and
Box-Tukey functions (see "Gravity model calculation" on page 174), too.
EVA1
EVA2
154
a
f (x ) = ( 1 + x ) ( x ) whereby ( x ) = 1 + exp( b cx )
b
x
f (x ) = 1 +
c
PTV AG
Schiller
f (x ) =
1
x
1+
b
Logit
f (x ) = e (c x )
Kirchhoff
f (x ) = x c
Box-Cox
xb 1
c
f ( x ) = e
Box-Tukey
( x + 1 )b 1 / b ,
) whereby
(
c
x
=
f (x ) = e
Combined
f (x ) = a x b e (c x )
TModel
f (x ) =
None
ln( x + 1 ),
b >0
b =0
1
b
x + c xa
f(x) = x
In practice particularly the functions EVA1 and EVA2 have proved to be suitable. The EVA1
functions are monotonously falling with f(w) 1 for w 0. In illustration 53 some of them have
been illustrated. Their parameters can be interpreted geometrically.
Parameter marking the horizontal asymptote of function (w), thus influencing the degree of
approximation of the function f(w) to the w asymptote.
Parameter influencing the degree of approximation to the horizontal F(w)=1 in the proximity
of low assessment
c
b/c
f ( w )=
1
G exp( F G w )
Ew
+ ln( 1 + w )
.
1 + exp( F G w )
1 + exp( F G w ) 1 + w
f ( w + h ) f ( w ) h df ( w )
w
=
is defined as the
f (w)
w
dw
f (w)
limit of the quotient of the relative variation of the function f and the relative variation of the
impedance w.
It is obvious that the elasticity functions first take values near zero for low impedances, then for
a limited range in which the impedance sensitivity is at its highest take various values, but all
far from zero and for high impedances approximate the limit of -E.
PTV AG
155
Thus, this curve very much differs from the constant or linear elasticity functions of simple
power and exponential functions. Therefore, this type of function allows the adaptation to
various basic weighting situations (person groups, trip purposes, means of transport etc.). In
the range of low assessment or utility the weighting probability should be almost one, drop
further in the clearly noticeable range of assessment and utility which is relevant for the
respective type of traffic or purpose before asymptotically approximating zero. For example,
the assessment in the proximity of or in smaller towns plays a minor or no role at all for the road
users when choosing the destination or the means of transport (here mainly the random model
with WP = 1 is applicable).
1,1
1
0,9
0,8
0,7
f(w) 0,6
0,5
0,4
0,3
0,2
0,1
0
0 10 20 30 40 50 60 70 80 90 100 110120
0 10 20 30 40 50 60 70 80 90 100110 120
0
-5
-10
eps(w) -15
-20
-25
-30
Illustration 53: EVA1 function in dependence of impedance w
156
Exponents whose product determines the asymptotic behavior for high impedance values.
For b > 1 the curve is similar to that of the EVA function (1).
PTV AG
c ...
f ( c ) = 1 / 2 applies.
The illustration 54 shows the influence of a and b on the progression of the function. The two
other parameters are both kept constant.
EVA2 Function (a variable)
1,0
0,9
Utility f(x)
0,8
0,7
a=0
0,6
a=1
a=2
0,5
a=3
0,4
0,3
0,2
0,1
100
95
90
85
80
75
70
65
60
55
50
45
40
35
30
25
20
15
10
0,0
Assessment x
Utility f(x)
0,7
b=1
0,6
b=3
0,5
b=5
0,4
b=7
0,3
0,2
0,1
Assessment x
100
95
90
85
80
75
70
65
60
55
50
45
40
35
30
25
20
15
10
0,0
The Schiller function is a special case of the EVA2 function, however, with one parameter less.
As the first applications in practice have shown, the function can also be adapted sufficiently
well enough to observed data. Due to the lower number of parameters the calibration effort is
by far lower than for EVA2.
PTV AG
157
during iteration step p (p=1,2,), the system calculates approximations for fqi, fzj and fak as
follows.
fqi ( p + 1) =
n
Qi
K
fz j ( p + 1) =
m K
(j = 1,,n)
i =1k =1
VK k
fak ( p + 1) =
m n
Wijk fqi ( p + 1) fz j ( p + 1)
(k = 1,,K).
i =1 j =1
For convergence of the method (towards the solution of the trilinear problem), the condition for
unique solvability of the optimization problem is necessary and sufficient, i.e. existence of a
matrix Tijk that matches the constraints and for which Tijk = 0 is true for all pairs (i,j) with Wij =
0. This condition is fulfilled when Wij > 0 is true for all (i,j), since then the matrix with elements
Qi Z j fak
(the matrix that corresponds to the random model) can be chosen as a
V
feasible solution. For this special case A. W. Evans provided a convergence proof that also
allows for a (however rough) estimation of the convergence rate (Evans 1970). The practical
experience has shown that the method quickly converges in most application cases.
Tijk =
158
(i = 1,...,m;
j = 1,...,n; k = 1,..., K )
PTV AG
q ( p ) z j ( p ) ak ( p )
V
Tijk ( p + 1) = Tijk ( p ) i
qqi ( p ) zz j ( p ) aak ( p ) m n K
Trst ( p )
r =1 s =1t =1
(p = 1, 2,)
with
Qi
qi ( p ) =
n K
Tist ( p )
s =1t =1
n K
Tist ( p ) [zs ( p ) + at ( p )]
qqi ( p ) = s =1t =1
n K
2 Tist ( p )
s =1t =1
z j ( p) =
Zj
m K
Trjt ( p )
r =1t =1
m K
Trjt ( p ) [qr ( p ) + at ( p )]
zz j ( p ) = r =1t =1
m K
Trjt ( p )
r =1t =1
VK k
ak ( p ) =
m n
Trsk ( p )
r =1 s =1
m n
Trsk ( p ) [qr ( p ) + zs ( p )]
aak ( p ) = r =1 s =1
m n
Trsk ( p )
r =1 s =1
Strictly speaking the method presented solves the problem with hard constraints only. If some
constraints are weak or elastic, there will be an optimization problem with inequations as side
conditions instead of equations. At the example of weak constraints it is illustrated how the
problem and correspondingly its solution alters (according to Schiller 2004). It is assumed that
a demand stratum shows weak constraints on the destination side, which means attraction
calculated by trip generation constitutes an upper limit. Thus, the trilinear problem changes into
PTV AG
159
Tijk
= Qi
j k
Tijk
i k
Tijk
Z max
j
= VK k
i j
The procedure for multi-problem solving is mostly identical with the constraint equation
method, except that zj(p) and zzj(p) are calculated differently.
Z max
1
j
z j ( p ) = min
;
; fz j (0 ) = 1
fz
p
1
Z
p
(
)
(
)
ijk ( p ) (qi ( p ) + ak ( p ))
1
zz j ( p ) = min
; i k
fz
p
1
2
Z
p
(
)
(
)
j
j
If some demand strata do not feature hard constraints, not only has the method to be adapted
but also balancing has to be made up.
Note: Differences in marginal sums can only be balanced after trip generation if all demand
strata feature hard constraints.
In that case first of all the trilinear problem is solved for all demand strata except for the
balancing one. This results in the total productions and attractions of the zones covering these
demand strata and all modes. According to the formula for calculating productions and
attractions (see "EVA trip generation" on page 135), the productions and attractions of the
balancing demand stratum are modified. Finally Visum runs trip distribution and mode choice
for this last demand stratum, too.
The proceeding assumes that differences have to be balanced within the framework of the total
volume. This is only true if all modes are exchangeable, which means if they can be used
alternatively in a closed trip chain. If at least one mode cannot be exchanged, a second phase
begins after the total balancing in which calculations are performed for each non-exchangeable
mode separately and for all exchangeable modes jointly. Hereby, the productions and
attractions of the respective modes are calculated over the non-balancing demand strata,
their differences are compensated by an adaptation of the demand of the balancing demand
stratum, and based on that modified demand Trip distribution and Mode choice are calculated
for the last time. For non-exchangeable modes this last step corresponds to a simple mode
choice.
The implementation of the EVA model for trip distribution and mode choice has been
established in two separate operations. EVA Weighting uses skim matrices to calculate the
weighting matrices Wijk (one weighting matrix each per demand stratum). During EVA trip
distribution and Mode choice, the equation systems for determining the demand matrices are
set up according to the constraints of the demand strata and solved by applying one of the
above-described methods. The result of the operation is one demand matrix per demand
160
PTV AG
stratum and mode. You can also display the balance factors for productions and attractions fqi
and fzj, that result from the equation system. The balance factor for mode choice fak is
calculated for analysis, but not for forecast scenarios.
The EVA weighting procedure can be applied to all active OD pairs or only to those OD pairs
whose origin or destination zone are active. This allows you to perform an analysis based on
filtering by several OD pairs with different parameters. This option is not available for combined
distribution and mode choice, as for successful balancing, all traffic types need to be
accounted for in one step.
3.2.3
3.2.3.1
The tour-based model is based on the assumption that external activities cause mobility. In the
following examples previously defined activities are already being used (see "Activities, activity
pairs, activity chains" on page 122).
An activity chain describes a sequence of typical activities during a person's day. An example
would be: Home Work Shopping Home (HWOH). Such a sequence of activity pairs
implies trips, in this example here three different trips: HW, WO, OH. The average mobility
program of persons is described by activity chains for the tour-based model.
You can find the demand object activity chain attributes in the general description of the
demand objects (see "Activities, activity pairs, activity chains" on page 122).
Some changes in the demand objects, which are especially necessary for the tour-based
model, are described below.
Note: In a Visum-tour-based demand model, a demand stratum is specified by exactly one
person group (e.g. E+c) and one activity chain (e.g. HWOH). In the other demand models,
several person groups can be assigned to one demand stratum.
PTV AG
161
Activity
Structural property
Work ('W')
Jobs
Shopping ('O')
Recreation ('R')
Recreational facilities
School ('S')
School places
University ('U')
University places
You can specify whether a possible destination-binding can be considered for trip distribution,
per activity. If desired, a constraint for the destination side (for example hard, weak, elastic,
open) can be defined analog to the EVA demand model using two real-valued factors
ConstraintMinFactorDest and ConstraintMaxFactorDest. Depending on the constraint on
origin and destination side, the doubly-constrained trip distribution is calculated for each
activity transfer.
This results in the following new attributes:
Type of demand Attribute and range of values
object
Meaning
Activity
StructuralPropertiesCodes
Range: set of structural properties
Activity
ConstraintDest
Range: bool {0, 1}
Activity
ConstraintMinFactorDest /
ConstraintMaxFactorDest
Range: floating point number 0
162
Type of demand
object
Subattribute
Meaning
Activity pairs
TimeSeriesNo
Range: set of standard time
series (see "Time series" on
page 121)
Person group
Reference to a standard
time series, which has to be
proportional
PTV AG
3.2.3.2
Trip generation uses a list of group-specific activity chains, which for example, can be
determined from the sample of the KONTIV 89 (EMNID 1991) by applying a PTV company
optimization procedure for activity chains. For each activity chain probabilities of your daily
practice have to be specified for each person group. The following table (to calculate the
probabilities, these values must be divided by 100) contains examples of activity chain
percentages for each person group.
E+c
E-c
NE+c
NE-c
Appren
Stud
SPup
PPup
Child
HWH
74.25
62.60
8.18
2.82
33.48
11.08
1.92
0.30
0.00
HSH
0.00
0.00
0.00
0.00
47.57
0.00
0.00
0.00
0.00
HPH
17.42
25.94
60.60
62.93
12.37
23.91
12.99
9.08
0.00
HRH
27.03
25.32
52.50
39.74
38.08
37.33
40.12
38.67
0.00
HPH
0.00
0.00
0.00
0.00
0.00
0.00
0.00
74.99
0.00
HSH
0.00
0.00
0.00
0.00
0.00
45.19
0.00
0.00
0.00
HOH
0.90
1.82
0.96
0.47
0.00
0.00
80.48
0.00
0.00
HWWH
3.12
0.85
0.13
0.06
0.52
0.16
0.11
0.00
0.00
HWOH
4.67
7.05
0.96
0.33
1.79
0.80
0.37
0.00
0.00
HWRH
1.64
1.46
0.18
0.02
0.86
1.56
0.09
0.00
0.00
HWOH
0.08
0.04
0.00
0.00
0.00
0.00
0.00
0.00
0.00
HSWH
0.00
0.00
0.00
0.00
0.16
0.00
0.00
0.00
0.00
HSSH
0.00
0.00
0.00
0.00
0.11
0.00
0.00
0.00
0.00
HSPH
0.00
0.00
0.00
0.00
0.97
0.00
0.00
0.00
0.00
HSRPH
0.00
0.00
0.00
0.00
0.00
0.23
0.00
0.00
0.00
HSRRH
0.00
0.00
0.00
0.00
0.00
0.55
0.00
0.00
0.00
HSRSH
0.00
0.00
0.00
0.00
0.00
0.76
0.00
0.00
0.00
HSSOH
0.00
0.00
0.00
0.00
0.00
0.17
0.00
0.00
0.00
HSSSH
0.00
0.00
0.00
0.00
0.00
0.12
0.00
0.00
0.00
HOWWH
0.01
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
HOWPH
0.01
0.04
0.00
0.00
0.00
0.00
0.00
0.00
0.00
HOWRH
0.01
0.00
0.00
0.00
0.00
0.00
0.03
0.00
0.00
HOWOH
0.00
0.00
0.00
0.00
0.00
0.00
0.12
0.00
0.00
HOPPH
0.00
0.00
0.00
0.00
0.00
0.00
0.25
0.00
0.00
HOPRH
0.00
0.00
0.00
0.03
0.00
0.00
0.14
0.00
0.00
HOPOH
0.00
0.00
0.00
0.00
0.00
0.00
0.04
0.00
0.00
HPRRH
0.00
0.00
0.00
0.01
0.00
0.00
0.17
0.00
0.00
HOROH
0.00
0.00
0.00
0.00
0.00
0.00
0.11
0.00
0.00
HOOOH
0.00
0.00
0.00
0.00
0.00
0.00
0.03
0.00
0.00
Table 44: List of the activity chains: mobility rates per person group in %
PTV AG
163
The sum of the probabilities of a person group is often greater than 1.0 (or 100 %), because a
person can complete more than one activity chains one after the other in a day (for example,
person group E+c first HWH, then HRH).
The list displayed above, describes an average mobility for persons depending on the group
they belong to. In the tour-based model, trip generation (i.e. determining the absolute number
of activity chains and thus the trips starting from any of the individual zones) is calculated by
multiplying the inhabitants of each person group with the probabilities of all activity chains. Trip
generation can be limited to the active zones.
Thus, in the tour-based model, trip generation (the number of trips created with each activity in
the activity chain) is determined together with the number of inhabitants and distribution of
person groups. The result is saved in the zone attribute Home trips for each demand strata.
3.2.3.3
Using tour-based calculation, you can save output matrices with different aggregation levels.
The demand matrices are calculated from possible combinations of person group, mode,
production and attraction activity, and time interval.
The utility matrix, which shows the separation from the origin zone (spatially and trafficwise)
The utility is inversely proportional to impedance values, such as run times or distances, so
that the greater the run time or distance to a destination zone, the less its utility.
The utility matrix may also include the log sum of mode-specific use. In this way, specific
skims (e.g. PrT journey time or PuT number of transfers) are included in the total utility with
their share in the respective mode.
This is how a multitude of trip chains is created through each activity chain. The result of trip
distribution is not only a total traffic matrix, but also a set of all route chains.
164
PTV AG
With the destination choice model, the tour-based model needs a target potential Zj for each
activity. The target potential specifies the quantitative attractiveness of a zone. This target
potential for each zone j, corresponds to the value of the structural property (see "Tour-based
data model" on page 161) that belongs to the activity.
The utility function f(uij) is pivotal in the destination choice model. It specifies the probability Pij
with which one of the zones j is selected as destination zone (from all destination alternatives)
of origin zone i.
F ij = Q i P ij
Z j f ( u ij )
P ij = -----------------------------------------B
k = 1 Z k f uik
whereby
Fij
Qi
Productions in zone i
Pij
Zj
Index of zones (with k = the smallest zone number and B = the number of zones)
whereby uij describes the utility relation ij and the utility function f(uj)) (e.g. of the type Logit) can
consequently be defined as f ( u ij ) = e
cu ij
model can also be used as utility functions in the tour-based model (see "EVA trip distribution
and mode choice" on page 152).
In this case, the choice of parameter c for every activity is pivotal for destination choice. c
stands for the influence of utility on the destinations of the respective activity. If c = 0, then the
utility uij has no influence on the choice of destination. The larger c is, the larger is the impact
of utility uij on the choice of the destination (see "Gravity model calculation" on page 174).
You define function parameters for each person group.
To give you a better idea of what the three main model elements of destination choice, namely
destination potential, utility function and utility matrix, stand for, we will continue with the
example we used for trip generation (see "Example of trip generation with the tour-based
model" on page 164).
cu ij
PTV AG
165
To make it easier, let us assume that zone 2 is the only zone with jobs, which therefore has a
positive destination potential for the activity work. Expressed in numbers this would be
approximately Z1 = 0, Z2 = 100, Z3 = 0. The tour-based trip distribution formulas produce the
following results P11 = 0, P12 = 1 and P13 = 0, and therefore F11 = 0, F12 = 93.4 and F13 = 0.
Zone 2 is therefore the destination of all trips of zone 1.
Note: The definition of the utility function in this case does not influence the calculation.
After the activity work, based on zone 2, the probability for the choice of shopping destinations
is calculated for the subsequent trips WO. It is assumed, that the destination potentials for the
activity "Shopping" are defined as follows: Z1 = 0, Z2 = 50, Z3 = 50. Based on travel times and
distances, the utility defined for changeover WO, with the relation 2-2, is twice as high as the
changeover with the relation 2-3, thus approximately u22 = 2 and u23 = 1. The tour-based trip
distribution formulas produce the following results P21 = 0, P22 0.6 and P23 0.4, and
therefore F21 = 0, F22 56.0 and F23 37.4. 40 % of the trips thus lead to zone 3 and 60 % to
zone 2 (i.e. trips within the cell).
Here, multiplication of the destination probability of the work and shopping destinations takes
place in the system.
For the last activity pair of the chain, namely PH, destination choice is no longer necessary,
because zone 1 as a residential district and origin of the first trip of the chain, is also the
destination of the last trip of the chain.
This results in the following transition matrices.
Zone
93.4
93.4
Total
93.4
93.4
93.4
166
Zone
93.4
93.4
Total
56.0
37.4
93.4
56.0
37.4
PTV AG
Zone
93.4
93.4
Total
93.4
56.0
56.0
37.4
37.4
280.2
280.2
Total
93.4
149.4
37.4
93.4
93.4
149.4
56.0
56.0
37.4
37.4
37.4
Notes: The following behavioral aspects should be taken into consideration when you define
the utility parameters.
Traffic behavior analyses show, that persons with a car cover greater distances than
persons without a car. Accordingly, the absolute value of parameter c of the Logit function
for groups E+c and NE+c have to be smaller than for groups E-c or NE-c.
This also complies with the empirical perception, to give activity Work a c parameter with
a low absolute value, rather than for example activity Shopping.
The tour-based model allows specific utility matrices to be imported for each activity.
Combinations of distances and journey times can be used as a basic parameter in utility
matrices.
PTV AG
167
Note: The absolute value of a destination potential is first of all irrelevant, because it only
flows into the destination choice model comparatively to the sum of destination potentials of
all zones. Destination potential " jobs = 1,000" for a zone does not necessarily mean that the
tour-based model produces 1,000 trips for destination activity work. In fact, the destination
traffic depends on the product of destination potential and utility function value in relation to
the other zones.
If, however, the absolute value of the destination potential of an activity is very important, as for
example for the number of jobs, this can flow into the calculation via the Destination-sided
attraction option. If there are approx. 6,000 jobs in the study area, 1,000 jobs mean there is a
relative destination potential of 1,000/6,000 = 1/6 for the activity work. If a demand stratum has
a total of 3,000 home trips, the absolute zone destination potential standardized to the total of
home trips for this demand stratum is 3 1/6 = 500. This absolute value for the demand stratum
is used as a constraint in the doubly coupled gravity model (see "Gravity model calculation" on
page 174).
You can save your trip distribution results in an aggregated form to total demand matrices per
person group as well as per combination of time interval, mode, origin and destination activity.
The socioeconomic position and the mode availability of the person making the decision
(by differentiating according to person groups)
Different attributes of all modes (through the utility model)
Freedom of choice restrictions within trip chains (by definition of exchangeable and nonexchangeable modes)
This decision problem is illustrated in a discrete distribution model, which specifies the
probability for mode choice in every available route link.
To do so, the subjective use has to be calculated in dependency of the mode skims (in-vehicle
time, access and egress times, fare, etc.). If required, you can define several utilities per
destination activity.
This model has the following functional form.
f ( u ijm )
P ijm = -----------------------------M
k = 1 f ( uijk )
whereby
168
i, j
m
Pmij
umij
PTV AG
f ( u ijm ) can e.g. be a Logit utility function and thus be defined as f ( u ijm ) = e cu ij . As an
alternative, all available types of evaluation functions can be used from the EVA demand
method as a utility function for the tour-based mode choice (see "EVA trip distribution and
mode choice" on page 152).
As a base parameter for the utility matrices any distance combinations and mode specific
skims can be used, such as travel times, access and egress times, and fares. You can also use
the LogSums of mode-specific use as an input parameter.
Last but not least, we would like to explain the importance of the route chain concept for mode
choice.
In Visum the modes are divided into the following groups:
The tour-based model calculates a discrete distribution model (for example Logit) when first
calculating the trip of each route link (for a person group) and chooses one from all modes. If
the first mode is a non-exchangeable mode, the entire trip chain is maintained independent of
the attributes of this mode of the successive trip. If an exchangeable mode was selected for the
first trip, mode choice is carried out for the remaining chain trips, however, only within the
exchangeable modes.
modes X and W in short is also designated with A. A Logit utility function f ( u ijm ) = e cuij (with
parameter c = 0.4) is used again to represent the changeovers from and to the individual
activities. The utility matrices um for each mode m are provided by
Zone
PTV AG
uC
uX
Zone
169
uW
Zone
After analyzing the formula above, the following probability matrices apply.
PC
Zone
0.472
0.526
0.526
0.526
0.472
0.472
0.526
0.472
0.472
Zone
PX
0.316
0.237
0.237
0.237
0.316
0.316
0.237
0.316
0.316
Zone
PW
0.212
0.237
0.237
0.237
0.212
0.212
0.237
0.212
0.212
PA = PX + PW
Zone
0.528
0.474
0.474
0.474
0.528
0.528
0.474
0.528
0.528
Interesting are also the probabilities for modes X and W within the exchangeable modes.
PAX = PX / PA
Zone
170
0.598
0.5
0.5
0.5
0.598
0.598
PTV AG
Zone
0.5
0.598
0.598
PAW = PW / PA
Zone
1
0.402
0.5
0.5
0.5
0.402
0.402
0.5
0.402
0.402
The matrix of the first non-exchangeable mode Car for all activity transfers is calculated. The
matrix for the first activity transfer is the product of PC with the total demand matrix F1 of the
first transfer.
Total demand matrix F1 for the first activity transfer (Destination activity W)
Zone
93.4
93.4
Total
93.4
93.4
93.4
Matrix FP1 for mode C and the first activity transfer (destination activity A)
Zone
49.12
49.12
Total
49.12
49.12
49.12
With the next activity changeover, these 49.12 trips will be distributed across zones 2 and 3
according to the distribution probabilities (P22 = 0.6 or P23 = 0.4).
Matrix FC2 for mode C and the second activity transfer (Destination activity O)
Zone
49.12
49.12
Total
29.47
19.65
49.12
10
29.47
19.65
Finally, the trips have to end back at the last activity transfer in their origin zone 1.
PTV AG
171
Matrix FC3 for mode C and the third activity transfer (Destination activity H)
Zone
49.12
49.12
Total
49.12
29.47
29.47
19.65
19.65
Summed up, the following Car total demand matrix applies: FCT
Zone
147.36
147.36
Total
49.12
88.59
19.65
49.12
49.12
88.59
29.47
29.47
19.65
19.65
19.65
To determine the total demand matrix for non-exchangeable modes, this Car matrix is
subtracted from the total demand matrix FT (from trip distribution).
FT
Zone
280.2
280.2
Total
93.4
149.4
37.4
93.4
93.4
149.4
56.0
56.0
37.4
37.4
37.4
The difference first results in the total demand matrix for all non-exchangeable modes.
FA
Zone
132.84
132.84
Total
44.28
70.81
17.75
44.28
44.28
70.81
26.53
26.53
17.75
17.75
17.75
For this matrix mode choice now takes place within the exchangeable modes PuT and Walk,
to obtain the total demand matrices for modes PuT and Walk. The matrix is multiplied with the
probabilities PAX and PAW.
172
PTV AG
Zone
70.75
70.75
Total
22.14
38.00
10.61
22.14
22.14
39.74
13.27
15.86
10.61
8.87
8.87
Zone
62.09
62.09
Total
22.14
32.81
7.14
22.14
22.14
31.07
13.26
10.67
7.14
8.88
8.88
Make sure that the Car total demand matrix has identical row and column sums for each zone,
whereas this is not mandatory for the PuT and Walk matrices.
The mode choice results are saved in an aggregated form to demand matrices per person
group and mode. In addition, you can limit the usage of time interval and origin and destination
activity data for matrices with disaggregated data.
3.2.4
( )
f U ij = a U ij b e
c U ij
whereby
Uij
Value of the utility (for example distance or travel time) between zone i and zone j
a,b,c
Parameters to be estimated
2.
( )
f U ij = a e
cU ij
whereby
Uij
Value of the utility (for example distance or travel time) between zone i and zone j
a,c
Parameters to be estimated
The KALIBRI function adjusts these utility functions to a given trip length distribution.
PTV AG
173
Then the Trip distribution function calculates the traffic flow Fij (from zone i to zone j) with the
aid of the gravity model and known data, namely the source traffic Qi (of zone i), destination
traffic Zj (of zone j) and the parameters a, b, c (or a, c) specified here (see "Gravity model
calculation" on page 174).
The KALIBRI function provides two options that allow you to estimate the parameters for the
gravity model.
( )
(2)
( )
(3)
ln f U ij = ln a + b ln U ij + c U ij
or
ln f U ij = ln a + c U ij
Within each KALIBRI iteration a temporary demand matrix is calculated (for example via Multi
procedure with option doubly-constrained gravity model). The resulting values of the utility
function are smoothed by linear regression until the maximum number of KALIBRI iterations is
reached or the values do not change anymore. The smoothed values then describe a function
of type (2) or type (3).
3.2.5
F ij = k ij Q i Z j f ( U ij ) whereby
Logit
174
f ( U ij ) = e
cU ij
PTV AG
Kirchhoff
f ( U ij ) = U ij
Box-Cox
f ( U ij ) = e
Combined
U ij 1
c -----------------b
f ( U ij ) = a U ij e
TModel
cU ij
1
f ( U ij ) = ---------------------------b
a
U ij + cU ij
The distribution formula is referred to an attraction or utility function, with the following
parameters.
Uij
Value for the utility between zones, for example distance or travel time from zone i to zone j
Qi
Origin zone i
Zj
Destination zone j
kij
Number of zones
Determining the scaling factor kij and formulating the utility function f(Uij) are essential for
various modifications and extensions.
The scaling factor kij must be chosen so that the boundary conditions of the distribution models
n
j = 1 Fij
= Qi
(4.1)
= Zj
(4.2)
and
n
i = 1 Fij
F ij = k i Q i Z j f ( U ij )
with the following secondary conditions for zone i.
n
j = 1 Fij
PTV AG
= Qi
175
From the n secondary conditions, all ki can thus be determined by substitution in the
distribution function:
n
Qi =
j = 1
F ij =
j = 1
k i Q i Z j f ( U ij ) = k i Q i
j=1
Z j f ( U ij )
This results in
1
k i = ------------------------------------------ for Qi 0
n
Q i Z j f ( U ij )
F ij = ------------------------------------------ for all i, j
n
Q i Z j f ( U ij )
1
F ij = ------------------------------------------- for all i, j with k j = ------------------------------------------n
The adjustment of the model to reality (calibration) by variation of the free parameters is very
important.
Since the input parameters Qi and Zj have been specified, the only free parameters that remain
besides the scaling factors ( k and k ) are the parameters of the utility function f(Uij .
i
Since for doubly constrained calculation both directions of the distribution, (4.1) and (4.2) must
be met at the same time, the following must also apply for the scaling factors k and k as well
i
constrained calculation can only be achieved with much more complex iteration models.
As an iteration model the Matrix Editor uses the so-called Multi procedure according to Lohse
(Schnabel 1980) (see "The multi-procedure according to Lohse (Schnabel 1980)" on
page 189).
The general form of the utility function f(Uij) is
b
f ( U ij ) = a U ij e
cU ij
176
PTV AG
f(Uij)
0,8
0,7
c = -0,01
0,6
c = -0,1
0,5
0,4
c = -0,3
c = -0,5
0,3
c = -1
0,2
0,1
0
Uij
0
10
12
14
16
18
20
f(Uij)
1,2
b = 0,3
b = 0,5
0,8
b = 0,7
0,6
0,4
0,2
0
Uij
0
10
15
20
25
30
35
40
Notes: Choose a suitable specification for the utility functions, which means suitable
parameters. Among other things, the specification depends on the trip purpose and the mode
used. A trip to work is for example, on average longer than a trip for shopping. This means
that the utility function for the trips to work, depending on the town's size, is only slightly
dependent on the use (distance or travel time) or not at all. Shopping trips on the other hand,
are much more dependent on the use.
The use of a trip distribution model can therefore call for a separation of the travel demand
based on the trip purpose. This depends essentially on the requirements in terms of accuracy
and the demands on the matrix to be calculated. Benchmark figures for the percentage split
based on the trip purpose can be obtained for example from the KONTIV 89 (EMNID 1991)
or local surveys.
The following four examples show gravity models that are differently constrained and with and
without balancing.
PTV AG
177
With the distribution method that includes coupling for EITHER attraction or production, the
source or destination traffic is adjusted to the marginal totals in the code file. The location factor
then only affects the "complementary" destination or origin demand. However, the following
applies
n
j = 1 Zj
i = 1 Q i k i
or
i = 1 Q i
j = 1 Zj kj
j = 1 Zj + i = 1 Qi ki
i = 1 Qi = j = 1 Z'j ----------------------------------------------------------2
Zone numbers
1
2.66
*
*
1.00
0.33
0.33
1.00
2
1.75
2.08
0.50
2.33
0.50
1.41
0.25
2.08
0.50
3
1.99
4
1.50
0.33
0.25
1.00
0.50
0.33
0.50
0.33
0.25
* 7.90
*Zone
1
2
3
4
Production
10.0000
20.0000
30.0000
40.0000
Attraction
50.0000
10.0000
20.0000
20.0000
Factor
0.50000000
1.00000000
1.00000000
1.00000000
External
0
0
0
1
178
PTV AG
Result matrix
Zone numbers
1
36.76
*
*
2
15.91
10.00
3.11
1.45
20.01
6.76
2.81
30.00
9.97
3.76
40.00
16.92
7.89
3
30.79
4
16.55
2.80
2.64
4.82
5.62
7.98
8.29
15.19
0.00
100.01
Input data for calculating balancing and scaling according to average value
*Zone
1
2
3
4
Production
10.0000
20.0000
30.0000
40.0000
Attraction
50.0000
10.0000
20.0000
20.0000
Factor
0.50000000
1.00000000
0.30000000
1.00000000
External
0
0
0
1
Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix
Zone numbers
1
32.99
2
13.19
8.04
2.22
0.94
16.10
4.62
1.74
24.16
6.95
2.38
32.19
19.20
8.13
*
*
80.49
3
7.92
4
26.39
0.56
4.32
0.93
8.81
1.57
13.26
4.86
0.00
Zone numbers
*
*
PTV AG
1
2
166.183 107.560
165.571
0.001
22.700
107.414
22.700
0.001
90.008
35.926
16.284
134.633
50.387
31.017
155.524
57.169
37.558
3
88.972
4
134.710
5
155.725
35.183
50.387
57.300
15.991
31.017
37.705
0.001
15.153
22.644
15.153
0.001
38.075
22.644
38.152
0.001
653.150
179
Input data
*Zone
1
2
3
4
5
Production
18990.0
4960.0
7110.0
16080.0
2300.0
Attraction
18990.0
4960.0
7110.0
16080.0
2300.0
Location factor and zone property external are not specified. Default values are used.
The parameters are set as follows:
Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to the production total
Max. number of iterations = 10, Quality factor = 3
Result matrix
Zone numbers
*
*
*
*
*
*
*
1
2
18990.000 4959.951
1
18990.000
18990.000
0.000
2
4959.999
0.000 4959.897
3
7110.000
0.000
0.054
4
16080.000
0.000
0.000
5
2300.000
0.000
0.000
49439.999
3
4
7109.758 16080.290
5
2300.000
0.000
0.000
0.000
0.102
0.000
0.000
7109.426
0.520
0.000
0.230 16079.770
0.000
0.000
0.000
2300.000
* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50
3
0.33
1.00
0.33
0.33
4
0.25
0.50
0.50
0.25
*Zone
1
2
3
4
Production
10
20
30
40
Attraction
50
10
20
20
180
1
0,37
2
0,43
3
0,41
4
0,39
PTV AG
2
3
4
0,41
0,41
0,37
0,43
0,39
0,43
0,37
0,41
0,41
0,43
0,43
0,39
Q 1 Z 1 f ( U 11 )
and so F 11 = -----------------------------------------n
i = 1 Qi f ( Ui 1 )
10 50 0.37
F 11 = ----------------------------------------------------------------------------------------------------------------10 0.37 + 20 0.41 + 30 0.41 + 40 0.37
F11 = 4.71
The matrix is produced after the other 15 equations have been calculated.
Result matrix
Zone numbers
1
50.00
*
*
99.98
2
10.00
9.68
4.71
1.03
20.47
10.58
2.06
31.09
15.87
2.80
38.74
18.84
4.11
3
19.99
4
19.99
2.04
1.90
3.64
4.19
6.13
6.29
8.18
7.61
The desired values for destination demand were very well approximated, while the values for
origin demand were not reached so well. This circumstance is characteristic for such
distribution formulas. Either the origin or the destination sums are reached close enough. If
both boundary sums are to be aligned as closely as possible, it is necessary to use a boundary
compensation model. The function offers doubly constrained projection (Multi-Procedure) (see
"Projection" on page 188).
* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50
3
0.33
1.00
0.33
0.33
4
0.25
0.50
0.50
0.25
Input data
* ZoneNo
1
2
3
4
Productions
10
50
20
10
30
20
40
20
Attractions
PTV AG
Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
181
Zone numbers
1
3.2.6
1
50.00
*
*
2
10.01
10.01
4.87
1.06
20.00
10.34
2.01
30.00
15.32
2.70
40.00
19.47
4.24
3
20.00
4
20.00
2.11
1.97
3.55
4.10
5.91
6.07
8.43
7.86
100.01
Iteration
Iteration allows the repetition of the different steps of a procedure and therefore can be used to
re-incorporate skims calculated during the assignment into previous stages.
3.2.6.1
Go to procedure
Use the Go to procedure to carry out a convergence check. You can choose between the
following checks
1. It is checked whether, during the last iteration, attribute or matrix data has changed by less
than the user-defined threshold value. To find the values that have changed, the following
formula is used:
The following figure shows how the tolerance value is applied. For smaller attribute values, it
allows for acceptance of larger relative deviations than for larger attribute values. In
illustration 55, the green curve represents the relative deviation, whereby the tolerance value
was considered part of the attribute value.
182
PTV AG
2. It is checked whether a user-defined attribute lies under a specific value. This is useful
when you first add a script that recalculates the respective value.
If the convergence condition has been fulfilled, Visum continues with the next step of the
procedure. If not, Visum returns to the point specified as Go to target (procedure or group) and
iterates the procedure from there (procedure) or from the next step (group). Independent of
this, the convergence check is canceled as soon as a maximum number of iterations is
reached.
3.2.6.2
Using MSA (method of successive averages), you can calculate the mean value of two
matrices (demand or skim matrices).
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use an averaged matrix of all iterations
instead of a matrix of the current iteration as a GoTo criterion.
The operation calculates
i
1
A = ----------- B + ----------- C
i+1
i+1
whereby
A
B
C
i
Result matrix
Matrix of current iteration
Matrix average of all previous iterations
iteration counter
Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.
PTV AG
183
3.2.6.3
As for matrices the average values of attributes can be determined by means of MSA (Method
of Successive Averages), too.
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use the average values of attributes of all
iterations instead of the attribute values of the current iteration as a GoTo criterion.
The operation calculates
i
1
A = ----------- B + ----------- C
i+1
i+1
whereby
A
B
C
i
Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.
During an operation you can exchange the two weightings.
3.3
Visum offers both simple and more complex operations for editing and calculating matrices.
Most operations can be performed directly in the Matrix editor (see User Manual, Chpt. 3.3,
page 823), others are available as procedures (see User Manual, Chpt. 4, page 937).
Functions for copying / replacing matrix values
184
Matrix editor
window
Procedure
x*
x*
PTV AG
Matrix editor
window
Procedure
Transpose
Set diagonal
x*
x*
Matrix editor
window
Procedure
Round
x*
x**
x**
Symmetrize matrix (calculate average values pairwise from top and bottom
triangle)
Calculate matrix using marginal totals, i.e. trip distribution (see "Gravity
model calculation" on page 174)
Generate main zone matrix, using zone matrix (aggregate) - and
generate zone matrix, using main zone matrix (disaggregate)
x
x
* Not a procedure of its own, but possible via Combination of matrices and vectors
** Possible in procedures via add-in CalculateMatrix
Functions for structural changes to matrices
Extend matrix (include new OD pairs in matrix for arithmetic operations)
Aggregate (summarize rows/columns of a matrix)
Split/Extend (rows/columns of a matrix into/to several ones)
Form partial matrix (non-symmetric aggregation)
3.3.1
PTV AG
185
3.3.2
3.3.3
3.3.4
186
PTV AG
The Reflect lower triangle function offers the option of copying the matrix section below the
diagonal into the upper triangle (see User Manual, Chpt. 3.4.8, page 872). The Reflect upper
triangle function offers the option of copying the matrix section above the diagonal into the
lower triangle (see User Manual, Chpt. 3.4.7, page 871).
3.3.5
3.3.6
Round
With the Round function you round all matrix values to a specified precision. The matrix values
are rounded up or down so that the new value is a multiple of the value rounded. Therefore, it
is possible to round up to 0.1 or 0.25, for example (see User Manual, Chpt. 3.5.1, page 875).
3.3.7
3.3.8
PTV AG
187
3.3.9
3.3.10
3.3.11
3.3.12
Projection
The functionality is primarily used if origin or destination total values of a zone are to be
multiplied by a particular value, or a particular expected value is to be attained, which can be
necessary in some circumstances after origin-destination studies. Matrices collected are often
just random samples and must be projected to census values.
Matrix values can be projected per row (singly constrained projection regarding the
generation), per column (singly constrained projection regarding the production) or by row and
column (doubly constrained projection) (see User Manual, Chpt. 3.5.14, page 896).
Singly constrained projection means that each row or column is multiplied by a fixed value.
This value can be a procedure parameter or for zone and main zone matrices an attribute
of the zone or main zone. The complexity of doubly constrained projection is illustrated in the
example below.
Objective: projection of origin and destination demand as follows:
188
zone 1 by 10 %
zone 2 by 20 %
PTV AG
Zone
Origin traffic
20
30
50
40
50
90
Destination traffic
60
80
140
Line by line multiplication, therefore for purely singly constrained projection of the demand
regarding production originating from zone 1 by 10% and zone 2 by 20%, produces the
following matrix.
Zone
Origin traffic
22
33
55
48
60
108
Destination traffic
70
93
163
While the origin traffic has been increased correctly, the destination traffic has not.
For the doubly-constrained projection, the Matrix editor uses an iterative process, also called a
Multi-procedure. In an iterative progression, this process searches for the solution that best
achieves the expected values (see "The multi-procedure according to Lohse (Schnabel 1980)"
on page 189).
The Matrix Editor thus provides the following solution which correctly projects the origin and
destination traffic.
Zone
Origin traffic
21
34
55
45
62
107
Destination traffic
66
96
162
Q ip
q i ( n ) = -------------------------------Z jp
j Fij -----------Zj ( n )
PTV AG
189
Z jp
z i ( n ) = --------------------------------Q ip
i Fij ------------Qi ( n )
Gp
f ( n ) = ----------G(n)
Qip
Zjp
Gp
Fij(n)
Qi(n)
Zj(n)
G(n)
This iterative calculation is done repeatedly until the following conditions are met for all
boundary values (origin and destination expected values).
Qi ( n )
-------------- 1 for all zones i
Q ip
Zj ( n )
------------- 1 for all zones j
Z jp
The threshold suggested by Lohse was used. It states that
1
1
= ----------------------------- or = ---------------------------( QF Q ip )
( QF Z jp )
3.3.13
If you are using a matrix with network references, i.e. a zone or a main zone matrix, you can
choose an attribute of the zone or main zone to separate the rows and/or columns into groups.
190
PTV AG
If in this case, you e.g. select the attribute Main zone number for a zone matrix, singly
constrained projection will use a specific factor per main zone for projection. Projection by item
would use a different factor per main zone relation.
Note: The term "territory" used here merely describes a group of rows or columns and is not
to be confused with the network object of the same name.
3.3.14
b ij
(2)
w ij w ij
= ------------------------------------------------------------------------------------------------- a IJ
(1)
(2)
w kl w kl
k Index ( I )
l Index ( J )
whereby
i, j
i, j
Index(I), Index (J)
bij
Zone indices
aij
wij(1), wij(2)
Use case
You would like to correct a matrix or adjust it using count data. The count data available refers
to a rougher zone structure than your network. In this case, you first aggregate the zone
matrices, then perform a correction procedure (e.g. TFlowFuzzy) and finally disaggregate the
matrix again.
3.3.15
Extending matrices
You can extend external matrices during an arithmetic operation, i.e. you can add columns and
rows. To do so, choose an arithmetic operation that allows you to combine external matrices
with matrices that have different OD pairs.
You can use any arithmetic operation that requires a second operand, e.g. the basic ones or
forming the maximum or minimum.
The matrix data is calculated as follows:
PTV AG
191
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.
3.3.16
99
99
99
99
i = 0 qi
--------------------n
192
PTV AG
Weighted mean
i = 0 qi gi
-----------------------------n
i = 0 gi
with
qi
gi
PTV AG
193
3.3.17
If you only specify one factor for an object generated during splitting, this factor applies to
both the source and destination traffic in the demand matrix.
If origin and destination value are to be distributed with different proportions in a zone
generated by splitting, a destination traffic factor must also be specified after the origin
traffic factor.
For a demand matrix, the matrix value is generally distributed across the zones (1.0 = 100 %)
created through splitting. When choosing the splitting factors for zone generation, you can
decide whether or not you want to include the expected gains (total > 1.0) or losses (total < 1.0)
per split zone.
For a skim matrix, the matrix value per split zone is generally assigned to the new zones using
the factor 1.0, i.e. they remain unchanged.
100
1,001
0.3
0.1
100
1,002
0.5
0.2
100
1,003
0.2
0.7
200
2,001
0.7
0.7
200
2,002
0.3
0.3
In addition, all trips created within the cell are set to null.
This produces the following matrix:
Total of matrix data for all OD pairs from/to 1,001..1.,003 equals 1,000.
194
PTV AG
3.4
Matrix correction
You have different possibilities of correcting the demand matrix values with count data.
3.4.1
A demand matrix based on empirical survey data is outdated and you want to update it
without having to conduct a new (origin-destination) survey. The update shall be based on
based on census data only.
A matrix generated from the transport network model is to be calibrated, therefore counted
volume data are to be used.
A matrix generated from incomplete or not reliable data is to be improved by more
comprehensive/reliable volume data counted simultaneously.
A survey contains the journey distance distribution, but the model does not reflect the data
with the level of accuracy required.
TFlowFuzzy will solve this problem for PuT as well as for PrT. The update only affects the
demand matrix - not the time series - and always refers to total volumes (instead of volumes
per time interval).
The flow of information always follows the given order.
Old
matrix
data
New
count
data
TFlowFuzzy
New
matrix
PTV AG
195
Count data
Network
model
Assignment
TFlowFuzzy
Demand
matrix
Link volumes
Origin/destination travel demand per zone
Volumes of turns at nodes and main turns at main nodes (as long as they are defined)
Volumes via screen lines
Volumes on lanes
PuT passenger trips unlinked per line
PuT passenger kilometers per line
Boarding/alighting passengers at stop areas
Skim data distribution, e.g. journey distance distribution
196
PTV AG
selected network object are then taken from the assignment result of this demand result, and
the count values also only refer to this demand segment. TFlowFuzzy can also simultaneously
update the demand matrices of several demand segments, if only total count values are
specified for all demand segments. Then the count data specified is distributed proportionally
to the respective demand segment share of the assignment volumes. The demand matrix for
each demand segment is then updated individually.
Compared to other procedures, the outstanding quality of TFlowFuzzy is
that you can combine the following for matrix correction: origin/destination traffic, link
volumes, turns, main turns or screen lines, passenger trips unlinked and passengers
boarding/alighting at stop areas and distributions (e.g. journey distance).
Count values do not have to be available for all network objects.
The statistical uncertainty of the count figures can be modeled explicitly.
You can specify that the distribution of the result matrix must correspond to the distribution
of an existing demand matrix.
You can use count data that only covers part of the PuT lines. In this case, only volumes or
boarding/alighting passengers that refer to active line route elements are taken into
account for calculation.
3.4.1.1
Since the eighties, primarily in English-speaking countries, so-called matrix correction (or
matrix update) techniques have been used to produce a current demand matrix from an earlier
travel demand matrix (base matrix) using current traffic count values. Based on research by
Van Zuyten/Willumsen (1980), Bosserhoff (1985) and Rosinowski (1994) which focuses on
matrices for private transport, PTV has extended the application of these techniques to public
transport.
The starting point for the classic procedure is the travel demand for the individual OD pairs fij.
Travel demand is usually described as a matrix, but for our purposes a vector representation
containing all non-zero OD trips is more suitable.
0
f 21
f 31
f n1
f12
0
f32
f n2
f13
f 23
0
f n3
f1n
f 2 n
f 3n =
0
f12
f13
f1n
f 21
f 23
f 2n
f 31
While it is usually assumed, that a matrix based on an earlier time is known, only partial
information is provided for the current state. Important is the situation where there are no data
based on relations (from an origin destination survey) available, but only count values at
individual positions in the network. These can be both origin / destination traffic as well as link
volumes. We note the count values as another vector.
v r = (v1 v2
PTV AG
v3 vm )
197
The trips of any OD pair provides a certain share to each traffic count. In case of boarding and
alighting passengers the marginal sums of the demand matrix are known. In case of link counts
the counted volumes correspond to the sum of all (proportional) OD trips traveling on this link.
In general there is a linear relation between the demand on the OD pairs and the traffic counts.
Af=v
whereby A is called flow matrix. ask is "the share of passengers on movement k, traversing link
s". For origin / destination traffic count values, A is especially constant, as specified with
example n = 3, m = 6.
1
0
0
1
0
1 0 0 0 0 t12 board1
0 1 1 0 0 t13 board 2
0 0 0 1 1 t21 board3
=
0 1 0 1 0 t23 alight1
0 0 0 0 1 t31 alight2
1 0 1 0 0 t32 alight3
In this case, A does not depend on the timetable. However, the supply dependent trip choice
flows into A for link volumes; the flow matrix is obtained for example, through assignment of
any matrix (for example the old demand matrix) on the supply at the time of the count. Both
types of count values can be also be used next to each other without a problem.
A problem for the matrix correction is that, usually m << n2 and therefore the new matrix is
underdetermined by the count values. Out of the countless matrices which match the count
values "match", only the best is selected according to a evaluation function q, thus solves
max q(f), so that A f = v
A combination of entropy and weighting with the proportions of the old matrix usually serves as
an evaluation function; q is usually non-linear, which is why the problem is solved iteratively (for
example with Newton's method).
In this wording of the matrix correction problem there is, however, another weakness of the
classic approach: vector v of the count values is assumed as a known parameter, free of every
uncertainty. A q maximum is only selected from the matrices which fulfill the exact secondary
conditions. The count values thus receive an inadequate weight, because each survey
provides a snap shot, which is afflicted with a statistical uncertainty. Conventional procedures
(for example from Willumsen) do not allow such a state, because the boundary sums are
perceived as "strict" secondary conditions.
PTV has therefore taken on the approach by Rosinowski (1994), who modeled the count
values as fuzzy measured data according to the Fuzzy Sets Theory. If it is known that in a
zone, the origin traffic fluctuates up to 20 % from day to day, in other zones however about
25 %, this is illustrated with the respective bandwidths. In the secondary conditions of the
matrix estimation problem, there are thus Fuzzy Sets ~
v s with sets of variables of different
widths which replace strict values.
max q(f), so that A f = v
198
PTV AG
The illustration of Fuzzy Sets compared to pure limits allows the preference of central values
to be expressed within the set of variables. This means, that values close to the mean values
are generally preferred, but values within the margin are also accepted, if this means that a
much better q value is achieved.
How can the Fuzzy Sets now be treated numerically for the solution of the optimization
problem? The obvious trip is, to include the membership function of the individual Fuzzy Sets
in the evaluation function and in comparison weighted appropriately. To be able to continue
using standard procedures of non-linear optimization, the resulting objective function must also
be twice continuously differentiable, producing restrictions regarding the form of membership
functions. Especially the usually partial linear triangles or trapezoids are eliminated. Instead we
use the same mechanism as for the weighting with the original matrix, to support the choice of
central values from the set of values. As a comparison, here the evaluation function of the
weighted entropy maximization.
q( f ) =
n n
f ij
f ij ln f ij
f ij
i =1 j =1
If f ij is already set as a demand from the original matrix, the maximization of q benefits
matrices which slightly differ from the original matrix. This principle can be transferred to our
new optimization problem:
max q(f, s, s), so that
Af+s=v
A f - s = v
s0
s 0
199
Membership
function
0
3
Membership
function
0
z-*s
z
s
z+*s
the count value itself, where the membership function assumes its maximum
the distance between the count value, where the membership function drops to value 0
a predefined scaling factor ( > 0)
Values z, s and are entries for TFlowFuzzy (see User Manual, Chpt. 3.7.1, page 910). z and
s are specified individually for each count value (link volume, origin / destination traffic, turn
volume or main turn volume, as long as a main node is defined), whereas is a global
parameter for the procedure.
3.4.1.2
A calculation example is used to illustrate the matrix correction procedure. A PuT service is
defined in the very simple network with four zones shown here.
200
PTV AG
The link bars show the assignment result for the following matrix, which we assume were
obtained a long time ago by means of a passenger survey:
$VR
* PTV
* Time interval
0.00
24.00
* Factor
1
* Mode of transport No. 3
*
3 Mode of transport PuT
*
4 Mode of transport PrT
* Number of zones
4
1
2
3
*Zone
1
Total =
0
100
100
*Zone
2
Total =
100
0
100
*Zone
3
Total =
100
100
0
*Zone
4
Total =
100
100
100
4
300
100
300
100
300
100
300
0
Counts have since been completed on all links of the network, and the following volumes
obtained.
The counted values for this example are based on the assumption that the demand matrix has
since changed as follows.
$VR
* PTV
* Time interval
0.00
24.00
PTV AG
201
Factor
1
4
350
100
330
80
300
100
280
0
The counted values from the figure are loaded into Visum LinkAddValues. Additionally, for
each individual counted value or collectively, a random sample fuzzy value can be added,
which means a bandwidth, within which the counted values actually fluctuate from one survey
date to another. This fuzzy value can be accepted as it is or obtained empirically by counting
the same OD relations on different dates.
TFlowFuzzy now calculates a new matrix, which on the one hand exhibits to a very high degree
similar ratios between the number of trips in the individual OD relations as in the old matrix (by
maximizing the weighted entropy), and on the other hand, during assignment matches the
counted values from the new survey within the specified bandwidth.
In the above example TFlowFuzzy, with a random sample accuracy of 5 %, calculates the
following matrix, which matches the assumed "ideal solution" very well.
$VN
4
*
*
1
346
1:
2:
3:
4:
3
298
4
281
148
99
99
100
83
100
99
83
99
346
0
2
331
331
148
298
99
281
99
* 1256
3.4.2
202
PTV AG
3.4.3
3.4.3.1
The projection of the matrix corresponds to the Increase factor model with justification, known
in traffic planning. By comparing the calculated volume with the count data, the counted cross
sections supply information on "adjustment factors" which need to be taken into account. Here
it has to be taken into account that an origin/destination relation can traverse several counted
cross sections, that is, it might be influenced by several adjustment factors.
The calculation process has two stages.
1. Determination of the adjustment factors
First, the calibration function calculates an adjustment factor ki for each count value zi.
3.4.3.2
The Fij matrix of the last assignment serves as the basic matrix.
Zone
Origin traffic
20
30
50
40
50
90
Destination traffic
60
80
140
If the traffic of Zone 1 is to be increased by 10 % and the traffic of Zone 2 by 20 %, the following
matrix (for a projection of the origin only) will result:
PTV AG
Zone
Origin traffic
22
33
55
48
60
108
Destination traffic
70
93
163
203
It is clear that, although the origin traffic increased by the required amount, the destination
traffic did not, because
1.1 * 60 = 66 and 1.2 * 80 = 96.
This is why an iterative procedure, the Multi-procedure according to Lohse (Schnabel 1980), is
used for origin and destination projection, as in an iterative process it searches for that one
solution that is best used to reach the target values (see "The multi-procedure according to
Lohse (Schnabel 1980)" on page 189).
For the above example the following solution is found:
204
Zone
Origin traffic
21
34
55
45
62
107
Destination traffic
66
96
162
PTV AG
Impact models
An impact model contains all methods to calculate the impact of traffic. It calculates results on
the basis of data and thus represents the computation kernel of the application. Components
of the different impact models offered in Visum are in particular assignment, skim calculation,
line blocking, line costing calculation (PuT operating indicators) and emission calculation,
including the impedance models used in them. Each of these methods is part of at least one of
the impact models for users, operators and the environment.
Subjects
4.1
4.1.1
PTV AG
205
Methods to model the travel behavior are based upon search algorithms which determine
routes or connections between an origin and a destination. Procedures used as search
algorithms are those which determine the best, meaning those which determine paths with the
lowest impedance or a set of sufficient paths. Impedance can consist of times, distances, and
costs. Depending on the search algorithm used, the paths found represent routes or
connections. The trips by OD pair are distributed among the paths found. This combination of
path search and trip distribution is called assignment. Private transport assignment assigns
vehicle trips; public transport assignment assigns passenger trips.
For every route or connection between two zones skims can be calculated which describe the
service quality of the route/connection. In addition to this, an assignment produces traffic
volumes for links and turns, and in PuT projects also for stops and stop points plus all objects
of the PuT line hierarchy from the transport system down to the level of individual vehicle
journeys. In contrast to a quality skim such as, for example, journey time, the volume is only an
indirect skim which by itself is not suited for evaluating the transport supply system. The
volume is rather used to deduce
saturation of PuT lines which affects the comfort of passengers and the revenues of
operators
noise and pollution emissions which indicate the environmental impact
Thus, the volume resulting from the user impact model serves as a basis for the procedures
provided by the operator impact model and those of the environmental impact model as well.
Visum offers various assignment procedures for private and public transport. They differ by the
search algorithm and by the procedure used for distributing demand. These assignment
procedures are a central part of Visum. There are PrT models and PuT models.
4.1.2
Compared to the PuT, the PrT network is generally operated by the state, countries or councils,
but also more and more by private investors. Decisions are geared towards the impact on the
general public, rather than on the impacts on the operators themselves, which is why in general
a different operator model has to be used for PrT. Here the economical analysis (EWS) impact
model is available in Visum. This model comprises methods on economical return of
206
PTV AG
4.1.3
4.2
Impedance functions
An impedance function generally measures the effort connected to a traffic process. All
instances are summarized to this effort, which prevent participants from carrying out this
process and therefore create an impedance. Effort examples are especially time and costs
connected to the process. You can also enter subjective criteria in the impedance. Thus, the
impedance of a certain connection in the PuT may increase, if certain comfort criteria are not
satisfied.
Impedance functions play an important role in several impact models. In the assignment, the
impedance function assigns a route or connection an effort. In PrT, especially the journey time
in the loaded network flows into the impedance, but it can also be additional properties such as
traveling expenses and possible toll. For dynamic assignments, it is also the discrepancy
between the departure time and the desired departure time. In PuT, in addition to the travel
time, it is mainly the number of transfers and the fare which have an effect on the impedance.
A problem for impedance functions is that completely different aspects are included and have
to finally arise from conjoint evaluation in form of a number. These different aspects which are
partially measured in different units, must therefore be recalculated and weighted against each
other. In general, weighting of the factors for different groups of assessing personnel is
different. For this reason, impedance functions for example can be defined at the assignment
per demand segment (see User Manual, Chpt. 5.2, page 977) and at line blocking per vehicle
combination (see User Manual, Chpt. 7.1.3.2, page 1169).
In Visum, impedance functions are used in the following contexts:
PTV AG
Assignment (User model): The impedance function assigns the effort to each path, thus
depending on the type of assignment, each route or connection, which the passenger has
to make, if he decides to take this path. The most natural criterion is the travel time which
has the corresponding unit time [s]. Especially in PrT, the travel time of a link is not
constant, but depends on the volume, the coherence is described in a VD function.
207
Demand models (User model): Within the framework of trip distribution, mode choice, as
well as combined procedures for trip distribution and mode choice, the impedance function
allocates an OD pair or the mode choice for this relation to the effort, which has to be
overcome for this choice. In this context we are traditionally talking about utility functions.
Although the supporting concept is identical, the benefit of it is, however, only the negative
impedance of the process.
Line blocking (Operator model): The impedance function assigns each activity (vehicle
journey, empty trip, layover, etc.) in a cycle the effort which arises, if the activity is
performed by this cycle. The most natural criteria here are the costs.
Despite these different application areas, the impedance function structure is always the same:
Each impedance function consists of a sum, in which each summand evaluates a certain
aspect of the effort and is weighted by a coefficient (see illustration 56). To calculate the
impedance of a traffic process, the properties of the process are first determined regarding
each aspect. Each aspect is then evaluated separately, in PrT especially by evaluating the VD
function. This evaluation of individual aspects is then provided and summed up with the
weighting factors.
Illustration 56: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min]
208
PTV AG
4.3
4.4
Skims / indicators
A skim is a measurement taken from the traffic model. Typical examples are the mean travel
time from a zone A to a zone B, which is calculated from the travel times of all paths found, as
well as the total PuT journey time, which is the sum of the journey times of all PuT passengers.
Skims can be divided into global skims, which describe properties of the entire traffic model,
and into skims gained per OD pair. The latter are stored in skim matrices, whereby the entry xij
for the skim value, refers to the relation from zone i to zone j.
Generally, skims measure the properties of the traffic model. In feed back models they are also
the input data for the demand modeling procedures, especially for trip distribution and mode
choice.
4.4.1
Skim matrices
Skim matrices describe properties of each relation from an origin zone A to a destination zone
B in the traffic model. Each individual skim (for example the travel time in a vehicle) is extracted
from the path properties from A to B, which belong to a demand segment. The skim data is then
aggregated with the relative share of demand, which the path would attract, to a skim value for
the OD pair. This also applies, if there is no demand for the relation from A to B, because
distribution does not depend on the demand.
PTV AG
209
The calculation of skim matrices differs between PrT and PuT on some points. The calculation
of PrT skim matrices is either based on present paths from a previously calculated assignment,
or for each OD pair the optimum path with regard to the impedance is determined (in the
possibly loaded network). Compared to an assignment, the network is not loaded in this case.
Because in this case there is only one path per relation, the skim value is extracted directly
from this path. If, however, paths from an assignment are used for skim matrix calculation, the
value of the minimum or maximum path impedance can be output as skim value, or the
weighted or unweighted mean value calculated from all paths by OD pair.
In PuT always more than one route or connection is calculated per OD pair, and the skim value
is derived from these. In addition to the average determination, optionally weighted with the
demand share, the output of properties of the path with the least perceived journey time (PJT,
timetable-based procedure) or with the least impedance (headway-based procedure) as well
as quantiles are available as additional aggregate functions. The skim is especially directly
dependent on the applied search strategy. Because not only the saved, but all paths found are
included in skim matrix calculation, the result differs from the result subsequently derived from
the paths. This is the case, if the demand becomes zero on some paths by an explicitly
requested rounding and the path is therefore not saved, but used for skim matrix calculation. If
demand and volume rounding is switched off, such differences cannot occur.
4.4.2
Global indicators
In addition to the skims by OD pair and demand segment, which are available in skim matrices
and are only calculated on demand, Visum automatically calculates a specified set of global
indicators with each assignment. These are properties of the overall assignment result, i.e., of
the traffic model itself. Typical values are the mean travel time in the network, the total vehicle
impedance in PrT, the total journey time of all PuT passengers, as well as the number of
passenger trips by PuT line. The global values are displayed via lists (see "Evaluation lists" on
page 731).
If several assignments are carried out subsequently, the global values represent the properties
of all paths in these assignment results. Compared to the skim matrices, these values orientate
themselves towards the loaded paths contained in the result. They are thus consistent with
properties of the saved paths.
210
PTV AG
Subjects
5.1
PTV AG
The Incremental assignment divides the demand matrix on a percentage basis into
several partial matrices. Then, these partial matrices are successively assigned to the
network. The route search considers the impedance which results from the traffic volume
of the previous step (see "Incremental assignment" on page 315).
211
212
PTV AG
The Dynamic Stochastic assignment differs from all the previously named procedures as
a result of the explicit modeling of the time axis. The assignment period is divided into
individual time slices, with volume and impedance separated for each such time slice. For
each departure time interval, the demand is distributed across the available connections (=
route + departure time) based on an assignment model as in the case of the stochastic
assignment. With this modeling, temporary overload conditions in the network are
displayed, a varying choice of routes results in the course of the day, and possibly also a
shift of departure time with respect to the desired time (see "Dynamic stochastic
assignment" on page 419).
For each of the mentioned assignment procedures any number of demand matrices can be
selected for assignment.
One demand matrix of one PrT transport system, for example, a car demand matrix is
assigned.
Multiple demand matrices which contain the demand for one or multiple PrT transport
systems, for example, a car demand matrix and a HGV demand matrix are assigned
simultaneously.
Abbreviations which are used together with the User Model PrT, shows the table 47.
v0
t0
vCur
tCur
Impedance = f (tCur)
Volume of a network object [car units/time interval] = sum of volumes of all PrT transport systems
including basic volume (preloaded volume)
NumTSys
q =
i = 1
( q i PCU i ) + q preloadedVolume
qmax
Sat
Volume/capacity ratio
Fij
5.2
PTV AG
Access and egress times are not considered, that is, they are set to 0 minutes.
Turn penalties are not considered.
Capacity and demand refer to one hour.
213
The traffic demand between A-Village and X-City is 2,000 car trips (car.fma matrix) during
peak hour.
To explain simultaneous assignment of multiple demand matrices 200 additional HGV trips
(hveh.fma matrix) are considered. One HGV corresponds to two car units.
On federal roads (link type 20) there is a speed limit of 80 km/h for HGVs.
The example network contains three routes which connect A-Village and X-City. The routes
run via the following nodes:
Route 1: 10 11 41 40
Route 2: 10 11 20 21 30 31 40
Route 3: 10 12 21 30 31 40
Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.
village A
10
10
12
11
11
41
20
40
21
30
city X
31
Type
Length [m]
v0-PrT [km/h]
10
20 Federal road
5,000
1,200
100
11
11
20
20 Federal road
5,000
1,200
100
20
21
20 Federal road
5,000
1,200
100
20
40
90 Rail track
10,000
21
30
20 Federal road
5,000
1,200
100
214
PTV AG
LinkNo
Type
Length [m]
v0-PrT [km/h]
30
31
20 Federal road
5,000
1,200
100
31
40
20 Federal road
5,000
1,200
100
11
41
30 Country road
16,000
800
80
40
41
30 Country road
5,000
800
80
10
10
12
40 Other roads
10,000
500
60
11
12
21
40 Other roads
5,000
500
60
5.3
PrT Paths
All assignments in Visum in the PrT as well as in the PuT are route based. This means that
possible paths in the assignment are calculated for each origin-destination relation and loaded
with a demand share. All other results, especially the different network object volumes and the
skim matrices are derived from these loaded paths. Paths are therefore the central result of the
assignment procedure.
The table 49 displays the PrT paths provided by an equilibrium assignment in Example.ver, in
link-based display.
Origin zone
100
100
100
200
200
Index
Link
From node
To node
1
1
10
11
11
20
20
21
21
30
30
31
31
40
10
11
11
41
41
40
10
10
12
11
12
21
PTV AG
215
Origin zone
Index
3
Link
From node
5
21
To node
30
30
31
31
40
For private transport, you can edit paths manually, because paths are available as network
objects here (see "Paths" on page 52).
5.4
5.4.1
The route choices of travelers depend on objective and subjective factors. The route choice is
particularly determined by the following skims:
In addition to this, a multitude of other factors can influence route choice. One can imagine, for
example, that road users who know their way around will choose other routes than people who
do not know the area and who mainly orient themselves according to the sign-posted traffic
network. Impedance is therefore defined for each transport system and can be customized by
the user. By default, it depends on the following variables:
216
PTV AG
You can also define the impedance in detail. You are then provided with all direct and indirect
numerical attributes of the network objects links, turns, connectors and main turns, for the
definition of the impedance of a route (see User Manual, Chpt. 5.2.2, page 992).
When composing the impedance summands, it can be differentiated between two basic
components:
Summands, which apply depending on the traffic volumes (for example value calculated
tCur with a VD function)
Summands, which are not dependent on the network object volume (for example, toll or link
length)
The time tCur of a network object is calculated with capacity restraint functions (VD functions).
Based on the assumption that the travel time (impedance) of network objects increases with
increasing traffic volume, all assignment procedures are in turn based on the assumption that
travel times of network objects are a monotone incremental function of traffic volume. Thus, in
case of increased traffic in the network the effect of deterrence to alternative routes can be
modeled (see "Predefined VD functions" on page 218).
Because the variables have different units (seconds, meters, money units), impedance cannot
be written in a universally applicable unit. For a combination of the variables, travel time, and
road toll, it may be convenient to express impedance in terms of money units. In this case,
travel times are converted into money units using a "value of time" factor.
Impedances of links
For every PrT-transport system of a link, a TSys-specific travel time (t0_TSys) for free flow is
defined which is calculated from:
link length
permitted speed (v0_PrT) of the link used
Impedances of connectors
Connector impedances are regarded as follows:
PTV AG
Absolute connectors are regarded as being volume-dependent. This means, that the TSysspecific connector time (t0_TSys) does not represent actual impedance which is volumeindependent.
217
Note: The impedance of turns and connectors in contrast to links only depends on the
variable tCur and possibly on the AddValue. Because the impedance of a connector is not
capacity-dependent, the following applies to the access and egress impedance: tCur = t0. The
proportional distribution of traffic demand onto different connectors is, however, reached
through a virtual capacity, so that tCur > t0 can also apply to connectors. For each assignment,
the particular virtual capacity (100%) is then recalculated from the summed up volume total
and the demand to be assigned in the current assignment, e.g. Vol(car-business) + Vol(carprivate) + Demand(HGV) = 100% Connector capacity.
Preloaded volume
When impedances are determined, preloaded volumes can be considered. Preloaded volumes
can be either user-defined additional values or volume values which result from the
assignment of a different matrix.
5.4.2
Predefined VD functions
Travel times for PrT are determined by the saturation of links and turns which result from the
traffic volume and the capacity of these network objects. Due to this, PrT travel times vary in
contrast to PuT journey times, and can only be anticipated to a certain degree before a trip. The
PrT travel time of a route between two zones consists of the following components:
For free traffic flow, the travel time t0 of a link can be determined from the link length and the
free-flow speed v0. For turns at an intersection, the turn time t0 is specified directly. In loaded
networks, the link travel time and the turn time is determined by a so-called volume-delay
function (or VD function). This capacity restraint function describes the correlation between the
current traffic volume q and the capacity qMax. The result of the VD function is the travel time in
the loaded network tcur. Visum provides several function types for the volume-delay functions:
1. the BPR function from the Traffic Assignment Manual of the United States Bureau of Public
Roads (illustration 58)
2. a modified BPR function with a different parameter b for the saturated and unsaturated
state (table 52)
3. a modified BPR function, for which an additional supplement d per vehicle can be specified
in the saturated state (table 53)
218
PTV AG
4. the INRETS function of the French Institut National de Recherche sur les Transports et leur
Scurit (illustration 59)
5. a constant function where the capacity does not influence travel time (tCur = t0)
6. and several functions for turning processes (i.e. t0 is added, not multiplied) as well as
function type linear bottleneck which are used by turn type
7. another modified BPR function (LOHSE) with a linear rise in the oversaturated section, in
accordance with the queuing theories, in order to achieve more realistic times in the
oversaturated section and a better performance in assignments since small changes to the
volume do not result in disproportionate travel time changes. The function is monotonic,
continuous, and differentiable even where sat = satcrit
Note: In addition to the volume-delay functions provided in Visum, you can also specify
user-defined VD functions (see "User-defined VD functions" on page 225).
The table 50 shows the variables used in the descriptions of the VD functions.
sat
q
q max c
satcrit
Degree of saturation at which the linear section of the volume-delay function starts
tcur
t0
Current volume = sum of volumes of all PrT transport systems including preloaded volume
[car units/time interval]
NumTSys
q =
qmax
i = 1
( q i PCU i ) + q preloadedVolume
a, b, c
User-defined parameters
a [0.00;), b {0.00...10.00}, c [0.00;)
PTV AG
219
f(q/qMax)
6
b=2
b=3
b=4
b=5
0
0
0,2
0,4
0,6
0,8
1,2
1,4
1,6
q / qMax
Illustration 58: VD function type BPR according to the Traffic Assignment Manual
satcrit
satcrit = 1
a, b, b, c
, where
satcrit
satcrit = 1
a, b, c, d
with
a, c
a [1.1;100), c [0.00;100)
220
PTV AG
with
a, c
, where
a [1.1;100), c [0.00;100)
, where
satcrit
satcrit [0.00;10]
a, b, c, d
The function models queuing at entry legs whose inflow is restricted by ramp metering signals.
, where
satcrit
satcrit = 1
current volume = sum of volumes of all PrT demand segments [car units/time unit] including
basic volume (preloaded volume)
AnzNSeg
q =
i = 1
( q i PkwE i ) + q Vorbelastung
PTV AG
221
f(sat)
a = 0,0
a = 0,2
a = 0,4
a = 0,6
a = 0,8
0
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,1
1,2
1,3
1,4
1,5
1,6
sat
The impedance functions listed in table 58 are particularly suited to the modeling of turn
impedances. A capacity-dependent wait time is thus added to each basic wait time t0.
LOGISTIC
QUADRATIC
SIGMOIDAL_MMF_NODES (formerly SIGMOIDAL_MMF)
a, b, c, d
Table
222
a, b, c, d [0.00100.00}, f {0.00...10.00}.
The value of parameter f of VD function types SIGMOIDAL_MMF_NODES and
SIGMOIDAL_MMF_LINKS ranges from 0..100.
58:
VD
function
types
SIGMOIDAL_MMF_LINKS
LOGISTIC,
QUADRATIC,
SIGMOIDAL_MMF_NODES,
PTV AG
AKCELIK
a = duration in hours
b = family parameter
d = 1 / Number of lanes (of the link)
qmax = capacity of the network object (of the link)
Unlike AKCELIK, the denominator of this function references directly to the capacity of the network
object. Besides, AKCELIK2 is no wait time function at a node but models the speed reduction on a link.
Value d is intentionally a free parameter, although alternatively the link attribute 'Number of lanes' could
be evaluated directly. By removing this attribute which should always carry the physically existing number
of lanes (for example for the Vissim export), a suitable value of d for example, can model the frictional
loss by pulling in and out events for parking. d = 0.6 would therefore correspond to a slightly lower
capacity than two lanes.
Table 60: VD function type AKCELIK2
satcrit
satcrit [0.00;10]
a [0.00;1000]
b
b [0.00;10]
c
c [0.00;100]
Table 61: VD function type LOHSE
PTV AG
223
LOHSE
45,0
40,0
35,0
30,0
tcur
b=2
25,0
b=3
b=4
b=5
20,0
15,0
10,0
5,0
2,50
2,40
2,30
2,20
2,10
2,00
1,90
1,80
1,70
1,60
1,50
1,40
1,30
1,20
1,10
1,00
0,90
0,80
0,70
0,60
0,50
0,40
0,30
0,20
0,10
0,00
0,0
sat
This function type stems from Metropolis and should not be used in static assignments, as it rises
strongly when reaching the saturation while the previously augmenting VolCapRatio is unaccounted for.
Table 62: VD function type Linear Bottleneck
Some projects may require non-standard VD functions, e.g. because they include further link
attributes or because the conversion of volumes to passenger car units (PCUs) is projectspecific. In this case, you can add your own functions to the pre-defined volume-delay
functions (see "User-defined VD functions" on page 225).
5.4.3
10,000 m
130 km/h
100 km/h
Capacity
224
PTV AG
Car volume
HGV volume
18 /h = 0.005 /s
36 /h = 0.010 /s
with a = 1, b = 2, c = 1
HGV speed only declines if the volume is more than 1644 car units/h, if
tCur = 277 (1+(1644/3000)) = 360s
Table 65: HGV travel times and speeds
Car impedance in loaded network
5.4.4
User-defined VD functions
You can set up user-defined VD functions for the following use cases:
To include further attributes for links, turns and connectors in the calculation
To calculate PCUs in a non-standard way
To define separate volume-delay functions for different transport systems
Volume-delay functions are very often evaluated within the assignment methods, so
computational efficiency is a key consideration. Therefore Visum adopts a compiled rather
than an interpreted approach to user-defined volume-delay functions. Users program their
functional forms as a dynamic-link library (DLL) following a given template. All such *.dll files
need to be copied into the following project directory, which is created during the installation
and which is scanned by Visum at start-up: %APPDATA%\PTV Vision\PTV Visum
13\UserVDF-DLLs (see User Manual, Chpt. 5.2.1.6, page 984).
Note: A *.bmp file with identical file name which is stored in the same folder will be displayed
for VDF selection.
PTV AG
225
5.5
Impedances at node
Intersections are modeled as nodes or as main nodes in Visum. Intersections of roads and/or
railway tracks are bottlenecks in an urban transport network. At the intersections, conflict
points have to be passed in succession by the non-compatible traffic flows. The order in which
the flows traverse the conflicting areas depends on the type of control:
To choose the route within an assignment procedure, the impedance on alternative routes is
decisive, which results in the sum of impedances of all traversed network objects. The
bottleneck effect of a node is thus displayed for all variants of the traffic control by the
impedance of the turn used. The impedance of turns usually corresponds exactly to the travel
time tCur, thus the time required to traverse the node in the turning direction of the route.
For calculating tCur per turn Visum offers three different models that represent the different
compromises between data entry and computing time on the one hand and accuracy and reallife situations on the other.
Turns VDF (see "Impedance of turns from Turns VD function" on page 228)
Nodes VDF (see "Impedance of turns from Nodes VD function" on page 228)
Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the
Highway Capacity Manual (ICA)" on page 229)
To use ICA during assignment, select the method Node impedance calculation (ICA).
Alternatively you can based on an assignment result select method From previous
assignment with ICA.
Comparing advantages and disadvantages in table 67 is to help you choose the appropriate
calculation model for your project.
Model
Advantage
Disadvantage
226
PTV AG
Model
Advantage
Disadvantage
Node impedance
Impedance calculation precisely
Input complexity considerably higher:
calculation (ICA) (see
considers lane allocation and signal
Instead of capacity and t0, model the
"Intersection Capacity
control. Special turn pockets for
lane allocation at the node and Analysis according to
example, are capacity-increasing
where available - the signal control in
the Highway Capacity
and dependent on the entered signal
detail
Manual (ICA)" on
timing, protected and permitted turns Calculation more time consuming
page 229)
are calculated correctly
Assignment convergence slow due to
the inseparable impedance model,
sometimes without additional
measures not at all
From previous
assignment with ICA
(see "Assignment with
ICA" on page 354)
Due to the reasons mentioned we recommend the following for the selection.
For comprehensive models, modeling with VD functions for turns or nodes is appropriate.
ICA cannot be recommended here, because the input complexity for the detailed supply of
nodes with geometry and control data is usually too high. Furthermore, the result after each
acceptable computing time due to the slow convergence of the assignment still contains
approximation errors, which are around the same size as the accuracy gained through ICA.
ICA however, is the method of choice if you want to subsequently calculate and analyze the
performance of one or more nodes of an existing assignment result. This is how you can
determine which aspects of the node contribute to a high impedance. It is therefore
sufficient to only model those nodes completely which have to be analyzed.
With a classical assignment method (Equilibrium or Equilibrium_Lohse, for example), ICA
is only conditionally recommended due to the known convergence difficulties, and it should
only be applied to small-scale analyses with some 100 nodes. To avoid these problems, the
Assignment with ICA method is recommended.
With an equilibrium assignment, best results can be achieved with either the
Equilibrium_Lohse method (see "Equilibrium_Lohse" on page 346) or the From
previous assignment with ICA method (see "Assignment with ICA" on page 354), since
these are more robust towards impedance variations.
In most cases you will globally decide on a calculation model. You can however also combine
different calculation methods within a network, (for example, Turns VD functions as standard
model and ICA simply for very important nodes with complex lane allocation or large conflicting
flows).
All calculation models are based on turn volumes in car units per hour, which are determined
through the user's settings, either from the assigned volume or from counted data via a factor.
PTV AG
227
5.5.1
Attribute
Turn
Description / Effect
Turn
t0 PrT
Turn
Type
Table 68: Attributes for the impedance calculation from Turns VD function
5.5.2
Description / Effect
Turn
Turn
t0 PrT
Turn
Type
Node
Node
t0 PrT
Table 69: Attributes for the impedance calculation from Node VD function
228
PTV AG
5.5.3
The method developed by R. M. Kimber, (Kimber 1980), (Kimber, Hollis 1979), (Kimber,
Daly 1986), which is also described in the British guideline TD 16/93 "The Geometric
Design of Roundabouts", is based on the empirical study of numerous roundabouts and
the statistical adjustment of a model which estimates capacities in dependency of the
geometry (see "Roundabouts according to the TRL/Kimber 2010 method" on
page 272).
The method described in the Highway Capacity Manual 2010, chapter 21 (see
"Roundabouts according to the HCM 2010 method" on page 267).
PTV AG
229
The method according to HCM is recommended, if in theory you prefer consistency for all
control types (roundabouts also according to HCM like signalized and two-way stop nodes)
within a project. Furthermore, the method is not dependent on observations which were
only obtained through driving behavior studies in Great Britain.
For the calculation, the effective control type is decisive instead of the control type. These
values differ in the following: Signalized nodes are regarded as yield-controlled nodes, if no SC
has been allocated to them or if the SC has been turned off (Signal control attribute Turned
off).
Notes: Throughout the model description, special provision for right or left turns relates to
right-hand traffic. For Visum models with left-hand traffic the roles of right and left turns are
reversed (see User Manual, Chpt. 1.5, page 65).
U-turns are never considered in HCM 2000. In Visum it is possible to treat U-turns as far left
turns through the corresponding setting in the procedure parameters for intersection
impedance analysis (in left-hand traffic accordingly as far right turns). This calculation is then
no longer HCM conform. HCM 2010 regards U-turns at two-way stop nodes. Here, the
processing is performed according to HCM 2010 in Visum. Other control types are processed
according to HCM 2000.
5.5.3.1
Uncontrolled nodes
For uncontrolled nodes the impedance of a turn is calculated using a VD function from the node
volume (= Sum of turn volumes) and the node capacity, therefore exactly like calculating the
model Nodes VD function (see "Impedance of turns from Nodes VD function" on page 228),
however without a term for each turn.
The Visum attributes listed in table 70 are considered for the calculation.
Network object Attribute
Description / Effect
Node
Node
t0 PrT
5.5.3.2
Signalized nodes
Notes: In the HCM 2000, chapter 16 describes signalized nodes. In HCM 2010, find the
descriptions in the chapters 18 and 31.
Instead of the method described here for signalized nodes, the method for yield-controlled
nodes is applied to nodes and main nodes of the signalized control type, to which no SC has
been allocated or whose SC has been turned off.
The basic flow chart for performing capacity analyses for signalized intersections is displayed
in illustration 61. You input the intersection geometry, volumes (counts or adjusted demand
model volumes), and signal timing. The intersection geometry is deconstructed into lane (or
signal) groups, which are the basic unit of analysis in the HCM method.
230
PTV AG
A lane (or signal) group is a group of one or more lanes on an intersection approach having the
same green stage. For example, if an approach has just one pocketed exclusive left turn and
one shared through and right turn, then there are usually two lane groups the left and the
shared through/right.
Note: According to HCM 2010, the lane allocation follows different rules. Here, shared lanes
always form a separate lane group. For more details, please refer to HCM 2010, page 18-33.
The volumes are then adjusted via peak hour factors, etc. For each lane group, the saturation
flow rate (SFR), or capacity, is calculated based on the number of lanes and various
adjustment factors such as lane widths, signal timing, and pedestrian volumes. Having
calculated the demand and the capacity for each lane group, various performance measures
can be calculated. These include, for example, the v/c ratio, the average amount of control
delay by vehicle, the Level of Service, and the queues.
I n p u ts
Ge om etry
V olum es
S ig nal tim in g
L a n e G ro u p s &
D em an d A d j
L an e Gro uping s
P ea k h our fa ct or
S atu ratio n F lo w R a te
(C ap a city)
Ba sic s
A djus tm en t F a ct ors
C ap ac ity A n alysi s
V /C R a tio
A v erage D elay
L ev el o f S ervic e
Qu eue s
Note: For HCM 2010, the corresponding flow diagram can be found in HCM 2010, page 1832.
If you use the HCM 2000 or HCM 2010 operations model for signalized nodes, the Visum
attributes in table 71 will have an effect. Make sure that they are set to realistic values prior to
running the analysis.
Alternatively to the calculation method according to HCM, you can apply one of the following
methods:
PTV AG
ICU1
ICU2
231
Attribute
Description / Effect
Link
ICAArrivalType
Link
ICAUpstreamAdj
Link
ShareHGV
Link
Link
Slope
Used in step 6
Node
ICAPHFVolAdj
Node
ICALossTime
Node
Node
ICAIsCBD
Node
ICASneakers
Node
SC number
232
PTV AG
Network object
Attribute
Description / Effect
Geometry
All
Turn
ICAPHFVolAdj
Turn
Signal Control
All
SC
SC
Turned off
Signal group
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
Leg
ICA parking
Leg
Bicycle volume
Lane
Number of vehicles
Lane
Lane
Length
Lane
Width
PTV AG
233
Network object
Attribute
Description / Effect
Lane
Lane
Lane
ICA user-defined
utilization share
Lane
Crosswalk
Pedestrian volume
Notes: The link attribute Turn on red is not regarded for calculation.
Output is possible through the attributes listed in table 72.
Network object Attribute
Description / Effect
Node
Node
Node
Node
Node
Level of service
Node
Turn
Turn
Turn
Turn
234
PTV AG
Description / Effect
Turn
Turn
Turn
Turn
Level of service
Turn
tCur-PrTSys
where
vi
vg
PHF
PTV AG
235
3. Fully secured + permitted if during green time left turns are first fully secured and then
permitted.
4. Permitted + fully secured if during green time left turns are first permitted and then fully
secured.
5. Without left turn stage, all other cases.
Step 5: Proportions of left turning and right turning vehicles calculation by lane
group
The proportion of right and left turn volume by lane group needs to be calculated.
PLT = vLT / vi
PRT = vRT / vi
where
PLT
PRT
vi
vLT
vRT
In HCM 2010, the iterative method mentioned in step 1 is used for the calculation of the turning
movement proportions on shared lanes. For the description in detail, please refer to HCM
2010, page 31-30 et seqq.
2 stages
3 stages
4+ stages
Planning
1,500
1,425
1,375
Operations
1,800
1,720
1,650
This number decreases due to various factors. The SFR is defined as:
si = (so)(N) (fw)(fHV)(fg)(fp)(fa)(fbb)(fLu)(fRT)(fLT)(fLpb)(fRpb)
where
236
si
so
N
fw
fHV
PTV AG
fg
fp
fa
adjustment factor for the position of the link to city center (CBD true/false)
fbb
fLu
fRT
fLT
fLpb
fRpb
First the description of the main calculation is described and then the various SFR adjustment
factors are calculated.
If an ICAIdealSatFlowRate is specified for a turn, it will replace the final result of step 5. All
adjustment calculations are then bypassed.
The calculations according to HCM 2000 or HCM 2010 are similar. The set of factors taking
effect on the saturation flow rate is the same. Merely the calculations of the factors fw (HCM
2010, page 18-36), fLpb and fRpb differ. The latter are calculated by means of the iterative
method, which is described in HCM 2010, pages 31-30 to 31-37.
Deviating from HCM, the optimal saturation flow rate so of pocket lanes can also be calculated
by the number of vehicles which can be accommodated there. The number n of vehicles can
be set by lane. Alternatively, it results from the division of the pocket lane length by the
standard vehicle length which is set by link.
The alternative calculation method using lane length data is only applied, if the lane group
consists of one or more straight through lane(s) and exactly one pocket lane. The pocket lane
must be of a straight through lane or a through-left type or a through-right type lane. If these
conditions are not satisfied, the regular HCM calculation method will be applied.
The optimal saturation flow rate so of a two-lane group, which consists of a through lane and a
pocket, where there is space for n vehicles, then is as follows:
n 3600
s f = s o + min s o, --------------------
gi
Here, so is the ideal saturation flow rate, n is the number of vehicles which can be
accommodated on the pocket, gi is the effective green time and sf is the resulting saturation
flow rate of the lane group.
For shared lanes, the calculation is more complex. Taking a through lane with only straight
turns and a shared left/straight pocket, then the resulting saturation flow rate sf is as follows:
s ST s LT
s f = --------------------------------------------------------------------------v LT
v ST
- s LT
-------------------- s ST + ---------------------v LT v ST
v LT + v ST
PTV AG
237
Here, vLT and vST are the volumes of the left and the straight turns, sLT is the ideal saturation
flow rate of the left turn - therefore 1,900 vphpl - and sST is the ideal saturation flow rate of the
through lanes which results from the first equation.
where
gi
Gi
li
where
ci
capacity i
si
C
gi / C
cycle time
green ratio i
Step 9: Calculation of the critical vol/cap ratio for the entire intersection
The critical v/c ratio of nodes is defined below. The HCM method is concerned with the critical
lane group for each signal stage. The critical lane group is the lane group with the largest
volume/capacity ratio unless there are overlapping stages. If there are overlapping stages,
then the maximum of the different combinations of the stages is taken as the max. For the
description of this method, please refer to HCM 2000, page 16-14, or HCM 2010, page 18-41.
Only if the intergreen method Amber and allred is used for the signal control, loss times will be
determined at all. Per signal group, the loss time results from the amber time and allred time
total minus loss time adjustment.
Xc =
i -s- ci + C-----------L
where
Xc
238
PTV AG
v--
s ci
C
L
cycle time
loss time total of the signal groups of all critical lane groups
Below is an example calculation of critical lane group per signal stage with overlap.
For computation variant ICU1, Xc is defined as follows:
Xc =
i -s- ci + ---Cv
Xc =
i -s- ci
v
1 1 + -----------------C
----
L 1
where
di
dUi
uniform delay
dIi
dRi
PF
permanent adjustment factor for coordination quality (see "Signal coordination (Signal offset
optimization)" on page 281)
In HCM 2010, the equation looks likewise. However, factor PF has been implemented in factor
dUi. For the description of the calculation procedure, please refer to HCM 2010, page 18-45.
1 R g----i f
P C
PA
PF = ------------------------------------------gi
1 ---C
where
PTV AG
fPA
RP
239
Step 10a: Calculation of the uniform delay for each lane group
The uniform delay is the delay expected given a uniform distribution for arrivals and no
saturation. It is calculated as follows:
d Ui
2
1 g----i
C
= 0.5 C ------------------------------------------------------g
i
1 ---- ( min ( X i, 1 ) )
C
where
dUi
gi
Xi = v/c
volume/capacity ratio
Step 10b: Calculation of the incremental delay for each lane group
The incremental delay is the random delay that occurs since arrivals are not uniform and some
cycles will overflow. It is calculated as follows:
2 8 ki Ii Xi
d Ii = 900 T ( X i 1 ) + ( X i 1 ) + ----------------------------ci T
where
dIi
ci
Xi = v/c
volume/capacity ratio
T
ki
Ii
Step 10c: Delay calculation for the residual demand per lane group
The residual demand delay is the result of unmet demand at the start of the analysis period. It
is only calculated if an initial unmet demand at the start of the analysis period is input (Q). It is
set to 0 in the current implementation. It is calculated as follows:
1800 Q bi ( 1 + u i ) t i
d Ri = -------------------------------------------------------ci T
where
240
dRi
Qbi
initial unmet demand at the start of period T in vehicles for lane group (default 0)
ci
Capacity
T
ui
PTV AG
ti
di Vi
d A = -------------------- Vi
where
dA
di
Vi
dA VA
d I = ----------------------- VA
where
dI
dA
VA
Mean delay/vehicle
0 10 sec.
10 20 sec.
20 35 sec.
35 55 sec.
55 80 sec.
80 + sec.
In HCM 2010, the level of service is automatically classified as F, if v/c (volume/capacity ratio)
exceeds the value 1.
For the variants ICU 1, ICU2, and Circular 212, the level of service is defined through the
saturation v/s (volume/saturation flow rate) of the node:
PTV AG
241
LOS
0.000 - 0.600
0.601 - 0.700
0.701 - 0.800
0.801 - 0.900
0.901 - 1.000
>1.000
where
Q
mean queue length maximum distance measured in vehicles the queue extends on
average signal cycle
Q1
Q2
incremental term associated with random arrival and overflow to next cycle
where
PF2
progression factor 2
vi
C
gi
cycle time
Xi
1 R g----i 1 v----i
P C
s i
PF2 = ---------------------------------------------------- 1 g----i 1 R v----i
P s
C
i
242
PTV AG
where
PF2
progression factor 2
vi
C
gi
cycle time
si
RP
Step 14b: Calculate second-term of queued vehicles, estimate for mean overflow queue
Q b 2 8 k i X i 16 k Q b
Qb
Q 2 = 0.25 c i T ( X i 1 ) + ----------- + X i 1 + ----------- + --------------------- + ------------------------
2
ci T
ci T
c i T
(c T )
i
where
T
k
Qb
ci
P3
Q % = Q P1 + P2 e
where
Q
percentile
PTV AG
pre-timed signal
actuated signal
70%
P1
P2
P3
P1
P2
P3
85%
1.2
0.1
1.1
0.1
40
90%
1.4
0.3
1.3
0.3
30
95%
1.5
0.5
1.4
0.4
20
243
percentile
pre-timed signal
98%
1.6
1.0
actuated signal
1.5
0.6
18
1.7
1.5
1.71.7
1.0
13
(W 12 )
30
where
fw
This method differs in HCM 2010. For a description, please refer to HCM 2010, page 18-36.
100
100 + % HV (ET 1)
where
fHV
%HV
EP
%G
200
where
fg
%G
18 N m
N 0.1 -----------------3600 f = -----------------------------------------N
244
PTV AG
where
fp
N
Nm
In Visum, enter fP which is calculated by the formula, as attribute ICA parking directly at the
node leg.
where
fa
CBD
f bb
14.4 N
N ----------------------B3600
= --------------------------------N
where
fbb
N
NB
In Visum, enter fbb which is calculated by the formula, as attribute ICA bus blockage directly
at the node leg.
where
fLu
vg
vgl
unadjusted (input) volume for lane with highest volume in lane group (veh per hour)
For this adjustment factor, an HCM lookup-table is regarded (HCM 2000: table 10-23 on page
10-26; HCM 2010: table 18-30 on page 18-77). Alternatively, lane attribute values can be used
(ICA user-defined utilization share and ICA use user-defined utilization share).
PTV AG
245
or
= 0.85
for exclusive right turn lane
or
1.0 - (0.15) P
RT for shared right turn lane
f RT
where
fRT
PRT
The calculation according to HCM 2010 differs. For shared lanes, the adjustment factor is no
longer explicitly calculated. For more details, please refer to HCM 2010, page 18-38.
f LT
where
fLT
PLT
For permitted staging, there are five cases. When there is protected-plus-permitted staging or
permitted-plus-protected staging, the analysis is split into the protected portion and the
permitted portion. The two are analyzed separately and then combined. Essentially this means
treating them like separate lane groups. Refer to the HCM for how to split the effective green
times among the protected and permitted portions.
1. Exclusive lane with permitted phasing use the general equation below
2. Exclusive lane with protected-plus-permitted phasing use 0.95 for the protected portion
and the general equation below.
3. Shared lane with permitted phasing use the general equation below
4. Shared lane with protected-plus-permitted phasing use the equation above for protected
phasing portion and the general equation below for the permitted portion
5. Single lane approach with permitted left turns use the general equation below
246
PTV AG
The general equation for calculating fLT for permitted left turns is below. Note that this is not the
exact HCM 2000 equation since there are a few different versions depending on the situation
shared/exclusive lane, multilane/single lane approach, etc. But the equation is similar
regardless of the situation. This general equation is the equation for an exclusive left turn lane
with permitted phasing on a multilane approach opposed by a multilane approach.
The equation is basically the percentage of the time when lefts can make the turn times an
adjustment factor. The adjustment factor is based on the portion of lefts in the lane group and
an equivalent factor for gap acceptance time that is based on the opposing volume. The
calculation of the percentage of the time when lefts can make the turn is a function of the
opposing volume and their green time. The equation is as follows:
gu
1
f LT = ----- --------------------------------------------
g 1 + P L ( E L 1 1 )
( f LTmin f LT 1 )
fLTmin = 2 (1 + PL) / g
(N 1) g
P L = 1 + ----------------------------------------g u ( E L 1 + 4.24 )
gu = g - gq (if gq 0, else gu = g)
v olc qr o
-t
g q = ---------------------------------------------------------------0.5 [ v olc ( 1 qr o ) g o ] l
where
PTV AG
fLT
fLTmin
g
gu
PL
EL1
gq
Effective non-protected green time, while left-turns are blocked completely and the spill-back
of the conflict flow is reduced
go
N
volc
No
vo
fLUo
qro
Opposing queue ratio = max[1 - Rpo (go / C), 0] (Rpo = look-up value depends on ArrivalType)
tl
vo C
3600 N o f LU
247
The opposing volume is calculated from the signal groups that show green while the subject
lane group has green. To calculate the opposing volume for a subject lane group, the entire
opposing volume is used even if there is an overlap.
The permitted left movement calculation does not need to be generalized to 4+ legs since only
one opposing approach is allowed. If more than one opposing approach is coded, an error is
written to the log file.
Step 6j: Calculate pedestrian adjustment factors for left and right turns
The computation of the factors for left-turning and right-turning pedestrians and bicyclists is a
considerably complex operation. It is performed in four steps. For the computation, the bicycle
volumes of the legs are regarded and the pedestrian volumes of the crosswalks. A traffic flow
has potential conflicts with two crosswalks on the outbound leg. These two crosswalks head for
the opposite directions.
Note: At a leg which is a channelized turn no conflicts occur between right turn movements
and pedestrians.
Step 1: Determination of the pedestrian occupancy rate OCCpedg.
The pedestrian occupancy rate OCCpedg is derived from the volume. The following applies:
1
C
2
C
v pedg = min 5000, v ped -----1 + v ped -----2
gp
gp
v pedg 2000, if v pedg 1000
OCC pedg =
0.4 + v pedg 10000, else
Here, vpedg is the pedestrian flow rate, v1pedg and v2pedg are the pedestrian volumes of the
crosswalks, C is the cycle time of the signal control and g1p and g2p indicate the duration of
the green for the pedestrians.
Note: In the HCM2000 it is implicitly assumed, that the green for the left turn movements
and the green for the pedestrians start at the same time. In Visum, this is not the case,
however. Thus, the following distinction of cases applies in Visum: If the pedestrian green
time overlaps (or touches) the green or amber stage for vehicles, an existing conflict is
assumed. In this case, the duration of the green of the pedestrian signal group is fully
charged. Otherwise it is assumed, that there is no conflict. In this case, gp = 0 is assumed.
Step 2: Determination of the relevant occupancy rate of the conflict area OCCr
Case 1: Right turn movements without bicycle conflicts or left turn movements from
one-way roads
Decisive for left turns from one-way roads is, that there is no opposite vehicle flow.
248
PTV AG
Here, vbicg is the bicycle flow rate, vbic is the bicycle volume, C is the cycle time of the signal
control, g is the effective green time of the lane group, and OCCbicg is the conflict area's
occupancy rate caused by bicyclists.
These are left turn movements which do not originate from a one-way road. Here, a
distinction of cases is made for the values gq and gp. gq is the clearing time of the vehicle
flow on the opposite leg, and gp is the green time for the conflicting pedestrians. The
following applies:
gp = max(g1p, g2p)
Case 3a: gq gp
Pedestrians and bicyclists are irrelevant here, since the left turn movements have to wait
until the vehicle flow on the opposite leg is cleared.
( 5 3600 ) v 0
Here, OCCpedu is the occupancy rate of pedestrians after the clearance of the vehicle flow
on the opposite leg, and OCCpedg is the pedestrians occupancy rate.
Step 3: Determination of the adjustment factors for pedestrians and bicyclists on permitted
turns ApbT
Here, two cases are distinguished with regard to the values Nturn which is the number of
lanes per turn and Nrec, which is the number of lanes per destination leg.
Here, vehicles have the chance to give way to pedestrians and bicyclists. The following
applies:
ApbT = 1 - 0.6 OCCr
PTV AG
249
Step 4: Determination of the adjustment factors for the saturation flow rates for pedestrians
and bicyclists fLpb und fRpb.
fLpb is the adjustment factor for left turns, and fRpb is the adjustment factor for right turns.
The following applies:
fRpb = 1 - PRT (1 - ApbT) (1 - PRTA)
fLpb = 1 - PLT (1 - ApbT) (1 - PLTA)
PRT and PLT represent the proportions of right turn and left turn movements in the lane
group, and PRTA and PLTA code the permitted shares in the right and left turn movements
(each referring to the total number of right turn and left turn movements of the lane group).
5.5.3.3
Notes: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 19. In most instances, the calculation complies with HCM 2000.
Especially the explicit U-turn handling has been added.
In Visum, two-way nodes are modeled by the control types two-way stop and two-way
yield. In the HCM, the description refers to two-way stop nodes. Basically, the computation
is the same. The only difference is the determination of wait times in step 8.
Nodes of the signalized control type are also calculated according to the method for yieldcontrolled nodes, if no SC has been allocated or the SC has been turned off.
The two-way stop analysis method is based on the gap acceptance theory. The basic idea is
to calculate potential capacities for all movements, and then subtract capacity from these
movements based on movement rank (priority). The calculation flow chart looks like displayed
in illustration 62.
250
PTV AG
Inputs
Geometry
Volumes
%HGV, Ped Vol
Volume
PHF
Identify Conflicts
Potential Movement
Capacity
Capacity Analysis
Delay, LOS, Queues
If you use the HCM 2000 operations model for two-way stop nodes, the Visum attributes in
table 73 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects
Attribute
Description / Effect
Link
Share of HGV
Link
Slope
Used in step 3
Node
Geometry
All
Turn
Turn
Turn
Turn
PTV AG
251
Network objects
Attribute
Turn
ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4
Activate this option, to use the follow-up time set.
Description / Effect
Lane
Lane
Lane
Lane
ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4. The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.
Output is available through the same attributes as for signalized nodes (table 72). Additionally,
the calculated critical gap and follow-up time data is provided.
The method works with movements (Left, Through and Right) at each approach. Each
movement is ranked according to table 74.
Rank
1
Major Through
Major Right
Pedestrian passage minor flow
Major Left
Minor Right
Pedestrian passage major flow
Major Left priority to gaps in the opposing flow
Minor Right priority to gaps in the flow of the right-most lane of the major flow
Pedestrians Priority to any other flow
Minor Through
Minor Left
Note: HCM 2010 also regards U-turns on major flows. They are given rank 2. If the calculation
is based on HCM 2010, the U-turn related setting in the procedure parameters will not affect
these U-turns.
252
PTV AG
Notes: Rank 1 movements do not have conflicting flows since they have the highest priority.
Mainly, rank 1 movements are excluded from the analysis, with the exception of one
additional evaluation (see "Calculation of the critical vol/cap ratio for the entire intersection"
on page 238).
According to HCM 2010, pocket lanes for left turns (rights for left-hand traffic accordingly) in
the major flow are dealt with separately.
Only nodes with three or four legs are described in the HCM. In Visum, also multi-leg nodes
can be calculated. The 'Uncontrolled' rule is applied to conflicting flows between minor legs
which are not separated by a major leg.
For left-hand traffic, the right-hand calculation is performed symmetrically.
For right-hand traffic, the following example models the conflict flow of a left turn on a major
flow:
Volume through traffic in opposing direction + volume right turns in opposing direction
(does not apply, if right turns in opposing direction are separated by a channelized turn and
need to attend a yield sign or a stop sign) + pedestrian volumes minor flow crossing
Conflicting flows
Major Left
OT + OR* + ToP
Minor Right
Minor Through
where
O
Opposite direction
Through
Right
Left
Major
Minor
Far (for minor through/left turns the second major flow encountered)
ToP
FrP
PTV AG
If the major flow (right) is separated by a channelized turn and needs to attend a yield sign
or a stop sign then this flow will not be considered in the conflicting volume calculation for
other flows..
If the major flow has more than one lane, only the right lane volume of the major flow (= vol
/ num through lanes) applies as conflicting, for minor right and minor left turns.
If the major flow has a right turn lane, then the right turns of the major flow do not count for
the conflicting volume.
253
For left turns from the minor flow, the right turn volume of the opposing direction does not
count for the conflicting flow, if the destination link of the two turns has more than one lane.
Notes: Apart from the U-turns, the HCM 2010 differs from HCM 2000 in subtle differences.
For the determination of conflicting flows, please refer to HCM 2010, pages 19-9 to 19-14.
The HCM does not regard bending two-way stop/yield cases. In this case, conflicting flows
are determined according to Brilon and Weinert, 2002.
Example
Sarah needs 4 seconds of space between vehicles to make her left turn and merge with other
traffic safely.
The critical gap equation is:
tcx = tcb + (tcHVPHV) + (tcGG) - tcT - t3LT
where
tcx
tcb
tcHVPHV
tcGG
tcT
two stage adjustment factor (currently set to 0 for one stage modeling)
t3LT
0, otherwise
The base values for the critical gap are calculated as shown in table 76.
Movement
Major Left
4.1
4.1
Minor Right
6.2
6.9
Minor Through
6.5
6.5
Minor Left
7.1
7.5
254
PTV AG
If the calculated values differ from the observed values, manually set values per turn can be
used.
Example
Suppose Frank was waiting behind Sarah in the intersection. If he turns just after Sarah, he
would need a follow-up time of 2 seconds, rather than another 4 seconds to be able to merge
safely with other traffic. So, if the gap between vehicles was at least 6 seconds, both Sarah and
Frank could safely make their turns.
The follow-up time equation is:
t fx = t fb + t fHV P HV
where
tfx
tfb
tfHVPHV
follow-up time adjustment factor for heavy vehicles percent heavy vehicles
Major Left
2.2
Minor Right
3.3
Minor Through
4.0
Minor Left
3.5
If the calculated values differ from the observed values, manually set values per turn can be
used.
Step 5: Calculate the potential (or ideal) capacity for each movement
The potential capacity is the capacity which is achieved if this movement uses all potential
gaps (i.e. no higher ranking movements take up the gaps). Furthermore, it is assumed that
each movement is made from an exclusive lane. The potential capacity is defined as follows:
e (vcxtcx 3600 )
c px = vcx
1 e vcxt fx 3600
PTV AG
255
with
cpx
vcx
tcx
tfx
p vi
p pj
where
cmx
cpx
pvi = 1
P pj
vi
cmi = probability impeding vehicle movement i is not blocking subject movement
wv j ----SP
= 1 ---------------- = probability impeding ped movement j is not blocking subject movement
3600
vi
volume movement i
vj
w
SP
Since the calculation depends on higher rank movement capacities the calculation proceeds
from the top down (from rank 1 to rank 4 movements). Impeding vehicle and pedestrian
movements for each subject movement are listed in table 78:
Movement
Rank
Impeding movements
Major Through
None
Major Right
None
Major Left
ToP
Minor Right
FrP, ToP
Minor Through
Minor Left
256
PTV AG
where
J
Major
Minor
Opposite direction
Through
Right
Left
Far (for minor through/left turns the second major flow encountered)
ToP
FrP
pvJL
vJT
vJR
sJT
sJR
Note: Please refer to HCM 2010 page 19-20, for the description of a short pocket lane on the
major flow scenario.
ii
i
ii
ii
p
p = 0.65 p --------------+ 0.6 p
ii
p +3
i
where
PTV AG
257
pvJL
pvJLF
pvIT
pvR4
pvIR
ppIP
ppJP
vi
c i
where
CSH
vi
cm
Note: Note that the upstream signal and platoon flow adjustments are currently omitted from
the calculation. The same applies for the two-stage gap acceptable adjustment, as well as for
the flared approach adjustment.
c mx
c mx
450 T
mx
where
dx
cmx
T
vx
A similar formula is used for the calculation of either two-way control type (yield or stop):
258
PTV AG
vx
3600
------------- ------vx
vx
c mx c mx
vx
3600
Control delay per movement is aggregated to approach with a weighted (by volume) mean of
all approach movements/shared lanes. Mean approach delay is then aggregated to the entire
intersection with a weighted mean as well. The equations are the same as the ones for
signalized intersections.
Note that rank 1 movements get no delay. If, however, there is no exclusive left turn pocket,
then rank 1 movements may experience delay. There is therefore, an additional delay equation
for rank 1 movements when there are no left turns pockets on the major approaches. The
equation is as follows:
dR 1
v
( 1 p vJL ) d JL ----TN
----------------------------------------------if N > 1
=
vT + vR
(1 p ) d
if N = 1
vJL
JL
(5)
where
dR1
N
pvJL
dJL
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)
This delay is then substituted by the zero delay of rank 1 movements when calculating
approach and/or intersection delay.
Mean delay/vehicle
0 10 sec.
10 15 sec.
15 25 sec.
25 35 sec.
35 50 sec.
50 + sec.
PTV AG
259
Note: For LOS analyses, HCM 2010 additionally takes into consideration whether the
capacity was exceeded. If this is the case, always level F of service will be allocated (HCM
2010, page 19-2).
The intersection queue length calculation is:
Q 95 x
3600 v x
------------- -------2
c mx
v
c mx c mx
vx
x
= 900 T -------- 1 + ------- 1 + -------------------------- ------------
3600
c mx
c mx
150 T
where
Q95x
cmx
T
vx
5.5.3.4
All-way stop
Note: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 20. The calculations described in HCM 2010 and HCM 2000 are
identical.. HCM 2010 additionally includes the guidelines for queue length calculations (HCM
2010, page 20-17), which is missing in HCM 2000. Furthermore, the volume/capacity ratio is
regarded for the LOS calculation. In case of overload, automatically level F is assigned.
The HCM 2000 All-Way stop controlled (AWSC) capacity analysis method is an iterative
method. The model looks at all possible scenarios of a vehicle either being at an approach or
not being at an approach. Based on the input volumes the probability of each scenario
occurring is calculated as well as the mean delay. The v/c ratio is calculated for each scenario
which in turn impacts the others. Therefore, an iterative solution is needed to find the capacity
of each approach.
Unlike the signalized method, which works with signal groups, or the TWSC method, which
works with movements, the AWSC model works with lanes by approach.
The basic calculation is described in the flow chart in illustration 63. The user inputs
intersection geometry and volumes, along with a couple of additional attributes such as PHF
and %HGV. The volumes are adjusted and allocated to the lanes. The next step is to calculate
the saturation (capacity) follow-up time adjustment factors. Then the departure follow-up times
(i.e. the mean time between departures for a lane at an approach) are calculated based on all
the combinations of the probability states. This departure follow-up time for each lane for each
approach is dependent on the other approaches and so it is calculated in an iterative manner.
Once a converged value is found, then the service time, mean delay and LOS can be
calculated.
260
PTV AG
Inputs
Geometry
Volum es
Volume
PHF
Lane volumes
Base Headway
Adjustments
Probability States
Departure H eadway
Final D egree of
Utilization
If you use the HCM operations model for All-Way stop nodes, the following Visum attributes in
table 80 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network object
Attribute
Description / Effect
Link
ShareHGV
Node
ICAPHFVolAdj
Geometry
All
Turn
ICAPHFVolAdj
Output is available through the same attributes as for signalized nodes (table 71).
PTV AG
261
The first step is to PHF adjust the volumes by lane by movement by approach. In addition the
% heavy goods vehicles by lane by movement by approach are also input if available. Since in
Visum volumes are specified by movement and not by lane by movement, they are first
disaggregated per lane according to a standard method.
The next step is to calculate the follow-up time adjustment factors for each lane. The
calculation applies as follows:
hadj = hLTadj pLT + hRTadj pRT + hHVadj pHV
where
hadj
hLTadj
hRTadj
hHVadj
PLT
pRT
pHV
Adjustment factor
Saturation
LT
RT
HV
0.2
-0.6
1.7
0.5
-0.7
1.7
After calculating the follow-up time adjustment factor the departure follow-up time is calculated
in an iterative manner. It involves five steps.
j P ( a j )
where
P(i)
P(aj)
aj
This probability states calculation has a few parts. For each lane type j the P(aj) is calculated.
P(aj) is calculated based on a lookup table (table 82).
262
PTV AG
aj
P(aj)
>0
Xj
>0
1 - Xj
Notes:
If iteration is 1, then Xj = (Vj hd) / 3,600
Value aj is taken from the DOC table (table 83). This table contains all the combinations of 0
and 1 per lane for each approach. For two lanes per approach it looks like displayed in table 83
(see exhibit 17-30 in the HCM 2000 for the full table).
i
Number of
vehicles
Oppsoing
approach
L1
Left
(subject approach)
Right
(subject approach)
L2
L1
L2
L1
L2
64
Table 83: Excerpt from the DOC table for two lanes per approach
The combined probability states probability P(i) is then calculated for each row (i) for each
column (lane type) (j). To calculate P(i) we take the product of all probabilities of each opposing
lane and each conflicting lane P(aj). The result P(i) = P(aj) is the probability state for row (i).
PTV AG
263
P( C1 ) = P( 1 )
4
P( C2 ) = P( i )
2
10
P( C3 ) = P( i )
5
37
P( C4 ) = P( i )
11
64
P( C5 ) = P( i )
38
adjP( C1 ) = a [ P( C2 ) + 2 P( C3 ) + 3 P( C4 ) + 4 P( C5 )] / n
adjP( C2 ) = a [ P( C3 ) + 2 P( C4 ) + 3 P( C5 ) P( C2 )] / n
adjP( C3 ) = a [ P( C4 ) + 2 P( C5 ) 3 P( C3 )] / n
adjP( C4 ) = a [ P( C5 ) 6 P( C4 )] / n
adjP( C5 ) = a [ 10 P( C5 )] / n
where
a
n
where
P(i)
P(i)
adjP(i)
where
hsi
hadj
hbase
For each DOC case i, the base follow-up time hbase is taken from a lookup table which is based
on the particular DOC case (1 5) and geometry group (table 84).
264
PTV AG
Number of lanes
Subject
approach
Opposing
approach
Conflicting
approach
Intersection type
Geometry group
4 leg or T
4 leg or T
4 leg or T
3a / 4a
3b
4 leg
4b
1-2
1-2
4 leg or T
1*
1*
4 leg or T
4 leg or T
Note: * If subject is 3 lanes and either opposing or conflicting approach is 1 lane then
geometry group 5, else geometry group 6.
The model is generalized for 3+ lanes in order to apply it to 4+ leg intersections. The extension
is that these 4+ leg cases are geometry group 6.
The table 85 shows the saturation follow-up time base values.
Geometry group
DOC case
Number of
vehicles (Sum of
the [0,1] for the
case)
1
2
>=3
1
2
>=3
2
3
4
>=5
3
4
5
>=6
3.9
4.7
5.8
7.0
9.6
3.9
4.7
5.8
7.0
9.6
3a
4.0
4.8
5.9
7.1
9.7
3b
4.3
5.1
6.2
7.4
10.0
4a
4.0
4.8
5.9
7.1
9.7
4b
4.5
5.3
6.4
7.6
10.2
4.5
5.0
6.2
6.4
7.2
7.6
7.8
9.0
9.7
9.7
10.0
11.5
4.5
6.0
6.8
7.4
6.6
7.3
7.8
8.1
8.7
9.6
12.3
10.0
11.1
11.4
13.3
The DOC case is dependent on the 64 types of a 4 leg intersection. Nodes with more than 4
legs are first collapsed to four legs.
PTV AG
265
i I P' ( i ) hsi
where
hd
hsi
P(i)
I
These five steps are repeated until the departure follow-up time values converge (change is <
0.1). Now, the calculated departure follow-up time hd differs from the original value. Thus, the
next iteration will return a different result.
Now that the departure follow-up time for each lane is calculated, service time and capacity can
be calculated. The service time is calculated as follows:
t = hd - m
where
t
hd
Service time
move up time (2.0 s for geometry groups 1-4 and 2.3 s for groups 5-6)
The capacity is calculated as follows: the volume of the subject lane is incremented until its
degree of utilization (vjhd)/ 3,600 is 1.0. The volume of the other approaches is held constant.
At this point, the subject lanes volume value is taken to be the subject lanes capacity.
Capacity is therefore dependent on the input volumes for each approach.
The search for capacity is slow in a linear implementation. Thus a binary search is performed
with an upper bound of 1,800 vphpl.
Mean delay per lane is calculated from the equation below. The weighted mean delay for an
approach is calculated based on lane volume weights. Intersection average delay is calculated
based on the weighted mean by approach volumes. The equations are the same as the ones
for signalized intersections.
hd x
2
d x = t + 900 T x 1 + ( x 1 ) + ----------------+5
450 T
where
266
dx
t
T
x
Service time
hd
Vh
3600
d
Utility rate -------------
PTV AG
Mean delay/vehicle
0 10 s
10 15 s
15 25 s
25 35 s
35 50 s
50 + s
Table 86: Determining the LOS based on the mean delay per vehicle
The proposed extension for 4+ legs is to combine multiple lefts or rights into one left or right by
adding the number of lanes together when calculating conflicting flows. For example, when
there are two conflicting lefts for a subject approach, one with one lane and one with two lanes,
they are merged into one conflicting left with three lanes. This allows the existing framework to
be used. It probably slightly understates the delay, but it will work within the existing framework
and will result in additional delay for additional legs.
5.5.3.5
For this analysis method, please refer to HCM 2010, chapters 21 and 33. It is similar to the one
for two-way stop nodes and mainly differs from it in the following points:
PTV AG
267
In p u ts
V ol um es
Vo lu m e
In co m i ng l eg s
C on flic ting v ol um e s
T im e g a p s
C ri ti c al g aps
F ol l ow -up t im es
C ap a city
W a itin g tim e
Q u eu e l en g th
If you use the HCM 2010 operations model for roundabout nodes, the Visum attributes in
table 87 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects
Attribute
Description / Effect
Geometry
All
Node
ICAPHFVolAdj
Turn
ICAPHFVolAdj
Leg
Leg
Leg
Channelized turn
length
Leg
Leg
Length of splitter
island
Leg
Leg
Table 87: Input attributes for roundabout nodes according to HCM 2010
268
PTV AG
Network objects
Attribute
Description / Effect
Leg
Share of bypass
volume
Lane
Lane
Lane
Lane
ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
5 The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.
Table 87: Input attributes for roundabout nodes according to HCM 2010
Output is available through the same attributes as for signalized nodes (table 72).
The calculation method according to HCM 2010 consists of twelve consecutive steps. Here,
the description is reduced to the most important steps.
Step 2: Calculating traffic flows for each lane and conflicting volumes for each
approach
All calculations are based on the traffic flows and conflicting volumes at each approach. These
flows are derived from the turn volumes (in illustration 65 for a roundabout with four
approaches designated with v1 to v12).
PTV AG
269
For the distribution of the volumes to the lanes please refer to HCM 2010, pages 21-14 and 2115.
Example
The flow from the south is the sum of turn volumes v7 + v8 + v9. The conflicting flow which
applies to this flow is however the sum v1 + v2 + v10. This approach can be applied to
roundabouts with a countless number of approaches. U-turns can also be considered in the
same way, if you want to integrate them in the ICA calculation.
If an approach has more than one lane, the total inflow is distributed on lanes.
1. If only one lane is permitted for left turns, its volume is the sum of all volumes of left turns.
2. If only one lane is permitted for right turns, its volume is the sum of all volumes of right turns.
3. The remaining volume is distributed to all lanes in such way, that they all have the same
volume if possible.
Step 3: Capacity
The capacity of an approach depends on various factors: the number of lanes per approach
and the number of lanes in the roundabout and whether a lane is a bypass lane. For each of
the cases, predefined formulas can be used (HCM 2010, equations 21-1 to 21-7). This is the
basic formula:
c = 1130 e
Bv
Here B equals 0.001 for one-lane and two-lane entry roads to single-lane roundabouts. For
single-lane approaches to two-lane roundabouts B equals 0.0007. Two-lane approaches to
two-lane roundabouts use the following values for B: 0.00075 for the inner-most (let) lane, and
0.0007 for the right lane. For bypass lanes, with one conflicting exit lane, B is assumed to be
0.001. 0.0007 is used if there are two conflicting exit lanes.
270
PTV AG
Users with detailed knowledge of critical gaps and follow-up times can replace these formulas.
For the control type 'roundabout', critical gap and follow-up time are set by lane. Turn-related
values of this attribute are not regarded. For the extended computation, the capacity is derived
from the following data (HCM 2010, page 33-3):
Bv
c = Ae
------------A = 3600
gap f
gap
gap c -----------f
2B = ---------------------------3600
where
c
v
gapc
capacity in PCU/h
gapf
follow-up time in s
Visum uses the following standard values: 4 s for the critical gap and 3 s for the follow-up time.
You can optionally overwrite both values by lane.
Pedestrians have a bearing on the capacity. For a detailed description, please refer to HCM
2010, pages 21-16 and 21-17.
To the turns, the approach capacity is distributed in proportion to the volume. The result is
stored in the turn attribute ICA final capacity.
d
c
v
T
The mean delay of a turn is the volume weighted mean of the mean delay of lanes used. The
result is saved in the turn attribute tCur.
Note: For turns with lane turns without allocated signal group, tCur is set to zero.
PTV AG
271
Q 95
3600- v-
2 -----------c 3600
v
v
c
where
Q95
c
v
T
The attribute ICABackOfQueueForDefPerc is the maximum of the Q95 percentiles for the
lanes used.
0 - 10
>10 - 15
>15 - 25
>25 - 35
>35 - 50
>50
The HCM does not determine the calculation of the LOS per approach, turn or node. In these
cases Visum calculates the LOS on the basis of the volume weighted mean delay. If the
volume exceeds the capacity, the LOS is automatically set to F.
5.5.3.6
This analysis method regards approach capacity as a function of geometry and the conflicting
volume in roundabouts. On the basis of numerous observations, this function was calibrated to
British roundabouts.
The illustration 66 shows the calculation process for roundabouts according to the TRL/Kimber
method.
272
PTV AG
Inputs
Geometry
Volumes
Volume
Incoming legs
Conflicting volumes
Capacity
Waiting time
Queue length
Illustration 66: Calculation process for roundabouts according to the TRL/Kimber method
In Visum, the geometry of the roundabout is described through leg attributes. These attributes
are only important, if the node is a roundabout and if TRL/Kimber is selected as analysis
method. In all other cases, the parameters are ignored at ICA calculation. The meaning of the
parameter is illustrated in illustration 67, which has been taken from the DMRB guideline TD
16/93. For a better comparison with this guideline, the common English original attributes and
abbreviations are specified in the tabular overviews. Another parameter describes the
temporal variability of the inflow.
PTV AG
273
Illustration 67: Description of the node geometry for the TRL/Kimber model
The table 89 shows the additional input attributes at legs for calculation according to TRL/
Kimber.
Name
DMRB definition
Value
type
Value range
(Default value)
Meaning
ICAInscribedLength
CircleDiameter (D)
10 - 200 m (40
m)
ICAEntryWidth (e)
Length
3 - 20 m (7 m)
ICAApproachHalfWidth (v)
Length
2 - 15 m (3.5
m)
ICAFlareLength
(L)
Length
1 - 100 m (20
m)
Table 89: Input attributes for calculation according to the TRL/Kimber method
274
PTV AG
Name
DMRB definition
Value
type
Value range
(Default value)
Meaning
ICAEntryAngle () Integer
0..180 (45)
ICAGradeSeparation (SEP)
Length
Double
0 .. 10 (1.0)
See illustration 67
Table 89: Input attributes for calculation according to the TRL/Kimber method
These attributes are only important, if the ToNode of the link has the controller type
roundabout, i.e. the link represents an approach to a roundabout. In all other cases the
attributes are ignored.
The output attributes correspond to those for signalized intersections (table 72).
if F > f q c
else
where
PTV AG
Cap
qc
k
F
f
303 x
0.21 t (1 + 0.2 x)
275
t
M
1 + 5 / (1 + M)
x
S
v + (e - v) / (1 + 2 S)
e(D - 60)/10
1.6 (e - v) / L
The remaining variable descriptions refer to the attributes of the geometry description.
Different from the above mentioned, the following applies for roundabouts with RDistanceExit
> 0:
Cap =1.004F - 0.036SEP - 0.232 qc + 14.35 - f qc(2.14 - 0.023 qc)
( 1 ) ( T ) + ( 1 L 0 )T 2 ( 1 C ) ( L 0 + T )
A = -------------------------------------------------------------------------------------------------------------------------T + 1 C
4 ( L 0 + T ) ( T ( 1 C ) ( L 0 + T ) )
B = -----------------------------------------------------------------------------------------------T + 1 C
1
2
L = --- ( A + B A )
2
where
L
T
L0
C
v
= v / = Saturation
Visum uses the formula modified in (Kimber, Hollis 79) for increased accuracy.
The mean queue length of each turn is equal to the mean queue length of its approach and is
stored in the turn attribute ICAQueueLength.
Step 4: Delays
The mean control-based wait time per approach results from the Kimber and Hollis formula
(Kimber, Hollis 1979), (Kimber, Daly 1986).
276
PTV AG
T
1
J = --- ( 1 ) --- ( L 0 C + 2 )
2
L0 + 1
4 T
1
K = --- --- ( 1 ) + --- TC --------------- ( 1 C )
2
1
2
d = --- ( J + K J )
2
where
d
T
L0
C
v
= v / = Saturation
The mean permitted delay of a turn is equal to the mean permitted delay of its approach and is
saved in the turn attribute tCur.
Visum evaluates, like in Step 3, the increased accuracy modified formula by Kimber and Hollis.
0 - 10
>10 - 15
>15 - 25
>25 - 35
>35 - 50
>50
Table 90: LOS for calculation according to Kimber based on the mean delay
Visum calculates the LOS of the entire node accordingly, on the basis of the volume weighted
mean delay of all approaches.
5.5.4
PTV AG
277
Furthermore, with signal coordination you can optimize the time intervals between more than
one light signal control in the network (see "Signal coordination (Signal offset optimization)" on
page 281).
Note: Optimization regards only those nodes (main nodes), whose effective control type =
signalized. Optimization does not regard those nodes (main nodes) whose SC has been
turned off or to which no SC has been allocated.
5.5.4.1
The following attributes of network objects are relevant for the cycle and green time
optimization:
Network object type
Attribute
Description
SC
Reference to signal
coordination groups
Signal coordination
group
SC
SC
Optimization method
SC
Turned off
Turn
Turn volumes
278
Description
PTV AG
Description
Precision of
computation
5.5.4.2
Seconds or tenths of a Via this parameter you can decide whether seconds or
second
tenths of a second are permitted as green time start and
end.
The predefined cycle time applies as predefined for pure green time optimization.
(v s )ci
Gte
(v s )ci
i
where
Gi
(v/s)ci
ratio of volume v and saturation flow rate s for critical lane group ci in stage i
Gte
The total effective green time for a cycle is the same as the cycle time deducting all intergreens
between consecutive stages. The intergreen between two stages is zero, if the stages share
signal groups. Otherwise, intergreen is given by the attribute Default intergreen of the signal
control.
Each stage must also maintain the minimum green time, which is given by the Minimum green
time attribute of the signal control. If the calculated green time for a stage is less than the
minimum green time, then the green time split equation is rerun with the stage below its
minimum green time omitted. The omitted stage is assigned the minimum green time. That
minimum green is subtracted from the total effective green time and the green time split is
recalculated.
As a result of optimization, new values are assigned to the attributes Green time start and
Green time end of the stages.
PTV AG
279
Max z
P, G( l ) P sl tP z ql l L
min
tP tP
tP C
P
P
where
L
cycle time
sl
ql
tP
min
tP
280
PTV AG
The first secondary condition expresses that the share z of the volume per lane group
depends on the green times of the stages provided for this group. The share z is
maximized.
3. With the optimized signal timing plan, execute another ICA calculation.
4. If the total mean wait time has not improved, cancel the calculation and continue with step
5. If the saturation flow rates have changed, continue with step 2. Otherwise, continue with
step 5.
5. To the stages' attributes Green time start and Green time end, allocate the values
obtained from the recent optimum solution.
5.5.4.3
If you select the Signal cycle and split optimization for a node, Visum calculates an optimal
cycle time for the signal control at the node and at the same time an optimal green time split for
this cycle time. If several (main) nodes belong to a signal control, then automatically all (main)
nodes of this signal control will be optimized.
The calculation includes the following steps:
1. Determine the set T of permitted cycle times at the SC. If the procedure parameter Use
cycle times of coordination groups is active and if the SC belongs to a coordination
group, then only cycle times of the coordination group's cycle time family are permitted.
Otherwise, any cycle time (integer [in seconds]) from the interval between the SC attributes
ICA minimum cycle time for optimization and ICA maximum cycle time for
optimization is permitted
2. To each permissible cycle time t from T the following applies:
Specify optimal green times g*(t) for predefined cycle time t.
Use ICA to calculate the total wait time at the node for g*(t).
3. As an optimal cycle time t* select the t with minimum total wait time. In addition, set the
optimal green time split g*(t*).
The ICA calculation of the total wait time at the node only provides valid values, if the sum of
critical v/s ratios is smaller than or equal to 1. To greater sums always t* = max(T) applies. If
the sum of the minimum green time and intergreens for all stages or signal groups are larger
than the calculated t*, t* is set to the smallest t of T which is larger or equal to this sum. If no
such t exists, t* is set to the sum independently of T.
5.5.4.4
Signal cycle and split optimization always refers to individual signal controls. Signal offset
optimization, however, is used to optimize the offset between the signal times of neighboring
nodes in such a way, that vehicles can pass several consecutive signal controls on green. The
general aim is to minimize the total wait time for all vehicles at the signal control.
Notes: The method does not regard the attributes of the node geometry. Especially the stop
line position per lane is not taken into consideration.
Signal coordination dos not include signalized nodes or main nodes to which no SC has been
allocated or whose SC has been turned off.
PTV AG
281
Example
We will demonstrate the task with the example network displayed in illustration 68.
In the network in illustration 68 the six inner nodes have signal controls and the outer nodes are
only there to connect the four zones. Link and turn volumes result from an assignment. Lane
allocation is usually selected, so that at each approach of a node, a shared lane exists for the
straight and right turns and a 100 m long pocket for left turns additionally. Additional lanes are
only located at individual approaches with an especially large traffic volume. All SC have the
same signal times (illustration 69).
282
PTV AG
Illustration 69: Green time split at all nodes with succeeding left turns
With a cycle time of 80 s, straight and right turns each have a green time of 30 s. Signal groups
for left turns have 5 s more and are protected within this time.
Signal times and lane allocation are selected in such a way that the resulting capacity is
sufficient for all turns. Wait times can occur if neighboring SCs are badly coordinated. For this
example we first assume an offset time of 0 s for all SC. The assignment result illustrated by
link bars results as overlapping of seven paths and one of these is highlighted in the
illustration 70.
PTV AG
283
Illustration 70: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002
This route passes the signalized nodes 7,003, 8,003, and 9,002. Vehicles exiting node 7,003
in direction 8,003 form a group that starts at the beginning of the green time, i.e. at second 0.
Travel time tCur, on the link between 7,003 and 8,003, is 38 s. Without accounting for dispersal
of the group, the first vehicles reach node 8,003 at second 38. The distribution of the actually
driven speed by vehicles leads to a resolution of the original compact platoon (illustration 71).
284
PTV AG
On the left, the diagram shows the arrival rate by cycle second. The first vehicles arrive at
second 30. The arrival rate then steeply increases and decreases as of second 52. The signal
group to continue the journey also has a green time between second 0 and 30. The major part
of the platoon therefore reaches the node at red. The second diagram shows the
corresponding development of the queue length and the third diagram the resulting wait time
in vehicle seconds dependant on the arrival second. The total wait time across all arrivals is
19,069 vehicle seconds, which corresponds to a mean value of 39.20 s per vehicle. This is an
example for bad coordination.
At node 8,002, the situation is much more favorable (illustration 72).
The vehicle group again starts driving at second 0. The travel time on link 8,003 - 8,002, with
tCur = 41 s, is similar to before. However, the continuing signal group 4 for left turns, at node
8, has a green time from second 40 to second 75. Most of the vehicle group arrives during
green time. The queues are distinctly shorter and the total wait time is only 1,608.80 vehicle
seconds (mean: 4.37 s per vehicle).
In this simple example, the aim of signal coordination would be to change the offset between
nodes 7,003 and 8,003, so that the entire vehicle group arrived at 8,003 during green time. At
the same time, however, you would want to maintain the favorable offset between 8,003 and
8,0002. Because a convenient coordination should be achieved not only for one but several
paths (in the example, seven) simultaneously, signal coordination usually minimizes the total
wait time of all SCs by changing the offset times.
Model
Signal coordination in Visum can be used for optimizing SCs in a network, not only along a
linear corridor, as it corresponds with the traditional optimization of the progressive signal
system. This section describes how the optimization model is set up, which Visum solves by
using a standard procedure for mixed integer linear optimization. All attributes which describe
input and output of the procedure are summarized in the following section (see "Input attributes
with effect at signal coordination" on page 288).
Good coordination requires the SCs either have the same cycle times or that the cycle times
are at least in a simple ratio (for example 2:1). Furthermore, SCs have to be located close to
each other, otherwise the platoon will have broken up so heavily by the time it has reached the
next SC, that the arrivals will virtually be uniformly distributed and the wait time cannot be
influenced through the choice of the offset. It is therefore generally not sensible to coordinate
PTV AG
285
all SCs in one network. You determine which SCs should be coordinated, by defining signal
coordination groups and assigning them SCs (see User Manual, Chpt. 2.40.14, page 633). By
default, SCs are not assigned to any signal coordination group and are not coordinated.
For each signal coordination group define the set of the cycle times which are permitted for the
corresponding SCs. Please make sure that the cycle times actually make coordination
possible. Two SCs with cycle times of 60 s and 65 s can generally not be coordinated because
the platoon in each cycle takes place at a different cycle second. Suitable cycle times therefore
have a small LCM (least common multiple), for example, the family { 60 s, 80 s, 120 s } with
LCM = 240 s. Signal coordination optimizes offset times for each signal coordination group
separately and takes those SCs into consideration with cycle times belonging to the permitted
cycle times of the group. SCs with deviating cycle times are ignored and logged in the message
file.
Important for coordination is the behavior of the vehicle platoon during the journey from one SC
to another. Visum determines platoons by analyzing the assignment results for one or more
selected PrT demand segments. From the saved paths of the assignment, Visum determines
how many vehicles on their way first pass signal group SG1 of the SC SC1 and then signal
group SG2 of the SC SC2. We call such a combination of two consecutive signal groups with
one volume a coordination path leg or shorter path leg.
A path leg is relevant for the coordination, if the following properties apply.
All conditions except for the first one are aimed at a platoon remaining along the path leg.
Optimization treats the traffic flows on all path legs interdependently. In each case it is
assumed that within a cycle all vehicles start as a platoon at the beginning of the green time.
This means, that beginning with the green time start, outgoing vehicles flow off with the
saturation flow rate qmax, until the volume per cycle has been exhausted. The following applies:
PCU
q max = 1900 ------------ N
h
Here, N is the effective number of lanes for the turn. If the green time duration is insufficient and
does not allow the volume allocated to a cycle from the assignment to exit with qmax, Visum
ignores the excess volume and logs this in the message file.
The platoon resolution, solely caused by different vehicle speeds, describes the platoon
development formula according to Robertson. This model discretely divides the time in
increments (in Visum of 1 s) and displays the number at time t, at which a vehicle arrives at
the end of a path leg as a function of the number at time t < t, at the beginning of the path leg
departing vehicle.
q' t + T = F q t + ( 1 F ) q' t + T 1
286
PTV AG
where
qt
the number of vehicles arriving at the end of the path leg in time step t
qt
the number of vehicles departing at the beginning of the path leg in time step t
1
F = -------------------with specified constants and
1 + T
For calculating queue lengths it is presumed that separate lanes of sufficient length exist for
separate signal groups at an approach. Visum generally assumes "vertical" queues for signal
coordination and does therefore not consider spillback upstream over several links or have an
effect on the capacity of the turns of other signal groups.
For the evaluation of the progression quality, Visum calculates a number of skims which are
used throughout literature. In the subsequent formulas CT determines the cycle time, GT the
green time and qt the number of vehicles arriving at a node in time step t.
t CT qt avg
t CT qt
Platoon index = ------------------------------------------- with avg = -----------------------CT
q
t
t CT
This size measures the "distance" of a volume profile of an equal distribution. The value varies
from 0 (equal distribution) to 2 (for a distinct platoon). A high value means that coordination is
worthwhile at this node, because the arriving vehicles are focused on part of the cycle time, so
that there is a chance of moving the green time there, by changing the offset time.
t GT qt
Vehicles at green = 100 ------------------------- .
qt
t CT
This size directly measures how well coordination works. It calculates which part of the volume
passes the node without stopping at the SC.
q
t GT t GT
------------------------ -------Platoon ratio =
CT
q
t CT t
The size also measures how well coordination works, whereas high values imply good
coordination. Especially high values are achieved when a large share of arrivals enter at green,
although the green ratio itself is smaller.
The platoon ratio PR is the basis for the important ArrivalType parameter in waiting time
calculations according to HCM.
1
2
3
ArrivalType =
4
5
PTV AG
if
if
if
if
if
if
PV < 0.5
0.5 PV < 0.85
0.85 PV < 1.15
1.15 PV < 1.5
1.5 PV < 2.0
2.0 PV
287
Queue length queuet at a signal group to cycle second t results from the difference of
cumulative inflows and exit flows. For this calculation, Visum also calculates the delays of
travel times with specified arrival time in the queues and hence, the mean and total wait time.
Attributes
Note
PrT paths
Volume
From assignment
A freely selectable
attribute
All
Signal coordination
groups
Name
Meaning
Double
0.0 .. 100.0
Double
0.0 .. 2.0
Double
0.0 ..
Integer
1 .. 6
Time
0 s ..
Double
0.0 ..
288
PTV AG
Note: By the name component 'SC coord', the attribute SC coord arrival typeis indicated as
signal coordination output attribute. It is not identical to the ICA arrival type attribute, which
is used as entry for ICA calculation. If you want to calculate the ICA impedance with an arrival
type which corresponds with the given offset time intervals, first perform the Signal offset
analysis and then copy the SC coord arrival type values to the ICA arrival type attribute.
Procedure parameters
Alongside the network object attributes, the procedure parameters listed in table 93 control
signal coordination.
Name
Meaning
Automatic Analysis
Boole (True)
Set of assigned
PrT_DSeg (all assigned
PrT_DSeg)
MaxSaturation
MinPlatoonIndex
RobertsonAlpha
RobertsonBeta
TravelTimeLinkAttr
TravelTimeLinkFac
TravelTimeTurnAttr
TravelTimeTurnFac
TravelTimeMainTurnAttr
TravelTimeMainTurnFac
MaxCalculationTime
Time
PTV AG
289
Problem solution
To determine an optimal set of offset times per SC, Visum sets up a mixed integer linear
optimization problem. The deciding variables in this problem are the differences of the offset
times of neighboring SCs, the objective function is an in sections linearized approximation of
the wait time in dependency thereof. Secondary conditions express that the differences
between the offset times of adjacent SCs along each circle in the network have to be added to
an integer multiple of the cycle time.
A detailed description of the method is found in Mhring, Nkel, Wnsch 2006.
5.6
PrT skims
With the Calculate PrT skim matrix procedure the PrT skims which are listed in table 94 can be
calculated (see User Manual, Chpt. 5.8, page 1061). The abbreviations in parentheses
indicate the file extensions which are used by default for skim matrix output in version files.
t0-PrTSys (TT0)
tCur-PrTSys (TTC)
Sum of AddValue
Toll (TOL)
Impedance-PrTSys (IMP)
AddValue-TSys (ADS)
User-defined (UDS)
Calculating skims is either done via the best path as regards to the set criterion or via
aggregation from the paths of an assignment result calculated beforehand. In this case you can
select one of the aggregation functions listed in table 95.
Minimum impedance
Maximum impedance
Skim value calculated as a mean over all paths weighted with the
corresponding path volume
290
PTV AG
Moreover, the set of origin-destination relations for skims can be calculated, and also restricted
like the type of network objects which are included in the skim calculation.
5.7
Free distribution
During route search, only the connector time is considered and traffic demand is distributed
without further constraints onto the routes with the lowest impedance.
60 %
Zone3
Zone1
Zone2
40 %
1
Illustration 73: Example network for proportional distribution of the traffic demand
Example: Connector capacity determination for proportional distribution of the total traffic
(illustration 73)
PTV AG
291
5.8
The original volumes of links, connectors and (main) turns resulting from the assignment are
stored with the following attributes:
292
PTV AG
The blocking back model is divided into two phases, the second phase is optional.
5.8.1
PTV AG
You can calculate the blocking back model post-processed following an assignment. It
therefore does not influence the route choice.
293
Alternatively, you can execute the blocking back model in the external iteration of an
assignment procedure. The results are then included in the link impedance and therefore
in the route choice. This modus operandi is not recommended, since it significantly
downgrades the convergence of the particular assignment procedure. To take the blocking
back impact on the route choice into consideration during the assignment, you should
rather use the procedure Assignment with ICA (see "Assignment with ICA" on page 354).
In either case it can be combined with the following assignment procedures: Incremental,
Equilibrium, Equilibrium_Lohse, TRIBUT and any stochastic procedure. However, it cannot be
combined with a dynamic assignment procedure.
If an assignment has already been calculated for at least one demand segment, which is not to
be recalculated, the blocking back model is calculated prior to the execution of the assignment
of the already assigned demand segments. This is to ensure that the values for tcur and tw are
consistent with the current network status and to avoid that assignments with a blocking back
model share and those without are combined.
If the blocking back model is calculated as an integrative part of other procedures, one has to
differentiate between iterative procedures (Incremental assignment, Equilibrium_Lohse and
Stochastic assignment) one the one hand and balancing procedures (Equilibrium assignment
and TRIBUT) on the other hand. During those procedures running step-by-step a corrected
volume will always be calculated after the volume determination and also the wait times will be
calculated by the blocking back model. Then, in the i-th iteration, from the corrected volume a
new value tiCur will be calculated for the current travel time and the wait time tiw will be added.
i
t = t Cur + t w
As new value, the arithmetic mean Ti of all former ti is used, which is also considered in the
subsequent route search.
i
k = 0 t
k = 0 tCur + tw
k
T = --------------------- = --------------------------------------i+1
i+1
For the calculation of the travel time tCurNew, using the corrected volume is necessary, since
the increase of the travel time above the capacity limit is no longer determined by volumedelay functions but modeled by explicitly calculated wait times.
If there is neither any congestion nor a decrease in the volume due to a flow-rate loss, tCur
= tCurNew and tw = 0 apply in any case. The impedance is unchanged compared to a
conventional assignment in this case.
294
PTV AG
If the blocking back model is integrated into an equilibrium assignment (not recommended), the
selected procedure is calculated first and the blocking back model is calculated subsequently
in an outer loop. Both methods are based on the fact that the volume of a link equals the total
volume of all routes traversing that link. For that reason a link-related modification of the
volume, as performed by the blocking back model would have no effect.
Instead, the result of the calculation of the blocking back model is used to modify the VD
functions of each link temporarily so that identical travel times result for unchanged network
volumes and for the changed network volumes with the original VD functions. These modified
VD functions can then be used for another iteration of an equilibrium assignment. If the network
volume has not changed, an equilibrium state has been reached which regards the modified
travel times tCur that result from the blocking back model. Otherwise a further iteration is carried
out, that includes blocking back model and assignment. As is the case with other methods, the
modified VD functions are averaged over several iteration steps in order to suppress the
alternation of the route choice between several alternatives.
The equilibrium state that is reached by this integrated calculation procedure is characterized
as follows: in due consideration of the changes to the travel times (and thus to the impedances)
which result from the volume calculated by means of the blocking back model, the travel time
(the impedance) is the same for each route of an OD pair.
Limiting capacity
According to rule 1, the traffic flow from link to link along a route is limited by the capacity of the
link and the capacity of the link's ToNode and the capacity of the turn during the blocking back
model calculation. In the blocking back model parameters you can select individually, whether
link and turn and node capacities are to be regarded. The settings have the following meaning:
Link capacity restricts the outflow per link. As threshold, either the link attribute Capacity
PrT can be used or the summed up Capacity PrT of the outgoing turns. The latter option
is only provided for compliance with out-dated versions. It is no longer recommended. It is
recommended to use the option Turn capacity instead.
Node capacity restricts the flow per node (sum of all turn volumes) to the node attribute
Capacity PrT. These node capacities are only regarded for traffic flows on secondary links
(tmodelspecial = true) towards the node. Traffic flows on major legs therefore also have an
effect on crossing routes via secondary links.
Turn capacity restricts the flow per turn to the turn attribute Capacity PrT.
5.8.2
PTV AG
295
Here, VolDem(L) is the link volume resulting from assignment, Cap(L) is the PrT capacity of the
link, and ScalingFactor is the scaling factor for capacities from the blocking back model
parameters. Furthermore, VolBasic volume(L) is a basic link volume. You can select it in the
general procedure settings via PrT settings > Assignment.
Analogously, excess congestion factors Turn(T) and Node(N) are defined for turns T and nodes
N. Since basic volumes can only be preset for turns and links in Visum, the sum of the basic
volumes of the turns at the node is used as basic volume for nodes. Now, the excess
congestion factor of the network is the maximum of the excess congestion factors of all links,
nodes, and turns whose capacities are to be taken into account. It indicates by which factor the
(remaining) capacity in the network is exceeded at most.
The percentage of traffic corresponding to the reciprocal of this number can pass through the
network without any congestion. If 1, the procedure is not carried out. In this case, the
corrected volumes (Vol) equal the volumes calculated in the assignment (VolDem), thus no
congestion occurs.
If the denominator in the formula for the excess congestion factor calculation falls below 0 or
becomes 0 for a link or node or turn, there is no more free capacity available and the procedure
terminates.
296
PTV AG
VolDem
Volume demand: volumes from the assignment without consideration of withheld vehicles in
the blocking back model (i.e. if no blocking back model is calculated or no congestion occurs,
VolDem equals the volume Vol)
Vol
Cap
K
Q
P
Firstly, the network is loaded with that portion of demand which does not cause congestions
yet. Then, the remaining demand flows into the network step-by-step. At first, the greatest
natural number n is determined, that satisfies n/N 1/. The general is then as follows:
Initialize Vol for all links, turns, nodes and connectors by entering 0.
Initialize Q or all links and connectors by entering 0.
For all links L and connectors C, load Vol(L)*n/N or Vol(C)*n/N, respectively.
For j = n+1 to N
For each demand segment
For each route R of the demand segment
Load VolDem(R) / N to route R.
Loading a volume flow to a route R with the n-th part of VolDem (flow) is performed as follows.
Let L0, L1, ..., Lk be the generalized links of a route, i.e. L0 is the origin connector, Lk is the
destination connector, and the real links are in between. Now, the traffic from the origin zone
flows via L0, L1, ..., Lk to the destination zone, at which the traffic flow is always limited by the
capacities of the links and turns and nodes and by congestions that might have formed.
Capacities bear limiting effects as described below. Let toNode(L) be the To node of a link L and
let Turn(Lj, Lj+1,T) be the turn from L to Lj+1 for the links L and T. Now, the flow from Lj to Lj+1
is limited by the capacity of Lj, and by the capacity of the To node of Lj, and by the capacity of
the turn from Lj to Lj+1.
Note: If you have decided that a particular capacity should not have an effect, then the
calculation assumes an infinite capacity. Connectors have an infinite capacity by definition.
The maximum volume maxFlow from Lj to Lj+1 then is
maxFlow(Lj, Lj+1) = min{Cap(Lj) ScalingFactor - VolBasic volume(Lj),
Cap(toNode(Lj)) ScalingFactor - VolBasic volume(toNode(Lj)),
Cap(Turn(Lj, Lj+1)) ScalingFactor - VolBasic volume(Turn(Lj, Lj+1))}
If the amount of in-flowing traffic on a link of the route exceeds the amount, that can flow off to
the next link, then the portion of traffic that keeps flowing depends on the remaining free
capacity:
PTV AG
297
Traffic that cannot flow into the next link is added to the queue length. If the queue on a link
exceeds the maximum stocking capacity K, then backups will arise on previous links of the
route. In that process, the backup has to be subtracted from the volume(s) of the previous
link(s) again (also nodes and turns are concerned), since this flow actually cannot have
reached the congested link being located ahead in the route course:
Function PropagateQueue(R):
propagatingQ = 0
For j = k-1 to 1
If Q(Lj) > K(Lj)
propagatingQ := Q(Lj) - K(Lj)
Q(Lj) = K(Lj)
Q(Lj-1) := Q(Lj-1) + propagatingQ
Vol(Lj-1) = Vol(Lj-1) - propagatingQ
Vol(toNode(Lj-1)) := Vol(toNode(Lj-1)) - propagatingQ
Vol(Turn(Lj-1, Lj)) := Vol(Turn(Lj-1, Lj)) - propagatingQ
After phase 1, nodes require a special treatment for the following reason: Though there are no
turns at connectors, connector nodes are loaded in the process. To achieve the state, that the
node volume = sum of all turn volumes at connector nodes after phase 1, the node volume of
connector nodes is recalculated from the turn volumes after the procedure.
We use a simple example with two routes to illustrate the procedure. Route 1 leads from A to
D, route 2 from B to C. Both routes have a volume VolDem of 200 vehicles. The volume is
distributed to the routes in four iteration steps with 50 vehicles each. The number of iteration
steps is based on the procedure parameter Number of shares for flow distribution in phase
1. For reasons of simplification, only the link capacity is considered as limiting capacity in the
example. Route 1 is always charged first. There is a bottleneck on route 1. On route 2, a
backup arises though this route does not traverse the bottleneck link.
298
PTV AG
Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2.
In the first two iteration steps, each of the two routes is loaded with 50 vehicles. Queues do not
form yet (illustration 74).
Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1
Route 1: On the highlighted link, a bottleneck is located in iteration step 3. Due to the
insufficient stocking capacity of this link, the queue propagates to the preceding link
(illustration 75).
PTV AG
299
Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2
Since there is now a congestion on the link in the middle, also the vehicles following route 2 get
stuck in the queue (illustration 76).
Illustration 77: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1
Another 50 vehicles are added to route 1 in iteration step 4. As the stocking capacity of the link
in the middle is fully exhausted, vehicles continue to propagate backwards (illustration 77).
300
PTV AG
Illustration 78: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2
The 50 vehicles with route 2 cannot even reach the link in the middle; they all get stuck in the
congestion on the first link (illustration 78).
PTV AG
301
Illustration 79: Blocking back model, phase 2, relief of congestion. Initial situation
The illustration 79 shows the initial situation prior to relief of congestion in phase 2. Only the
queue lengths from phase 1 are regarded, there is no further influx. For congestion relief, four
portions are used (M = 4).
Illustration 80: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1
On route 1, the maximum congestion efflux is limited by the link capacity Cap = 100. Thus, Cap
/ M = 25 vehicles can flow off in iteration step 1 (illustration 80).
302
PTV AG
Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2
On route 2, the maximum congestion efflux is limited by the capacity of the link in the middle.
Since two routes traverse the link in the middle, only a certain portion of the capacity is
available for route 2 for this iteration, (Cap / M = 100); this portion is (Cap / M) (VolDem(Route
2) / VolDem(link in the middle)) = 100 (200 / 400) = 50 (illustration 81).
Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1
During iteration step 2, again 25 vehicles flow off via route 1 (illustration 82).
PTV AG
303
Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2
Illustration 84: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1
During iteration step 3 only some (12.5) vehicles flow off via route 1 which are part of the
remaining queue on the link in the middle (like in iteration 1 for route 2). The link on the right,
however, is traversed by only one route; that is why the total capacity is provided for the flow
off of the congestion for this iteration (Cap / M = 25) (illustration 84).
304
PTV AG
Illustration 85: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2
On the link in the middle, the remaining congestion can flow off via route 2 (illustration 85).
The congestion efflux in phase 2 thus works in a similar way as the formation of the congestion
in phase 1, save that the traffic does not enter the network via the connectors, as usual, but
exists at the links with congestion in the network. In each iteration, we let flow off a portion of
the traffic which is restricted by the capacities of the links and nodes and turns; thus, new
queue lengths will be obtained. This is repeated until either the maximum number of iterations
set for phase 2 is reached (user-defined parameter for the blocking back model) or until the
congestion is no longer available. More accurately, the procedure is described as follows.
Initialize prevQ with queue lengths on links and connectors after phase 1
For j = 1 until (max. number of iterations in Phase 2) or until any prevQ = 0
For each demand segment
For each route R of the demand segment
Calculate the congestion flow off for R according to M and the
capacities
and thus obtain currQ
Calculate wait time
prevQ:= currQ
In detail, the relief of congestion goes like this: In each iteration step, the M-th portion of the
capacity of links, nodes and turns is available. Thus, the maximum traffic that can flow off of
link L due to the link's capacity, is Cap(L) / M per iteration. To each route R, that traverses link
L, a certain share in the capacity is provided; this share equals the route's share in the original
total link volume, i.e. VolDem(R) / VolDem(L). For a link L that belongs to a route R, the
maximum outflow of a congestion results from the following formula:
maxOutflow(L) = (Cap(L) / M) (VolDem(R) / VolDem(L))
Furthermore, the outflow is restricted by the capacity of the To-Node and by the turn capacity.
Let L0, L1, ..., Lk again be the generalized terms for links of a route, i.e. L0 is the origin
connector, Lk is the destination connector, and the real links are in between. Thus, the
maximum outflow from Lj to Lj+1 results as follows:
PTV AG
305
The traffic flow that actually flows out comes from the existing queues. For each route R, the
traffic originating from the queue on link Lj is as follows:
sourceVolQ(Lj) = prevQ(Lj) (VolDem(R) / VolDem(Lj))
The origin traffic of a link (limited by the maximum outflow maxOutflow) flows to the next link.
This traffic is then added to the origin traffic on the next link. If maxOutflow is smaller than the
origin traffic, queues will form again. The following therefore applies:
Function QueueOutflow(R, M):
arrivedFlow = 0
For j = 0 to k-1
totalSourceVol := sourceVolQ(Sj) + arrivedFlow
propagatingFlow:= min(totalSourceVol, maxOutflow(Lj, Lj+1))
currQ(Lj) := currQ(Lj) - propagatingFlow
arrivedFlow := propagatingFlow
Propagate queue backwards
Please note that the results of the blocking back model may depend on the order of routes that
are processed. However, the more shares you choose for the distribution of the traffic flow, the
smaller the possible differences will be. If the blocking back model is applied to the same
network for example, on the one hand with an equilibrium assignment and with LUCE on the
other hand, then the results might differ slightly even if all routes are identical.
This is due to the fact, that - in contrast to other assignment procedures - LUCE does not
directly provide routes, but bushes in the first instance, which represent multiple routes at the
same time. In conjunction with LUCE, the blocking back model calculations are performed
directly on the bush level. Since the bushes can include various from-links and to-links for each
link, the traffic flows need to be distributed appropriately. This is performed in a way as if
several routes were processed simultaneously. From this, slightly deviating results may be the
outcome.
306
PTV AG
Illustration 86: Integral indicating the overall wait time over the interpolated measured queue lengths
with I being the duration of the first simulation interval in seconds. The sum extends over the
measured values with QL(0) indicating the queue length QL after the first simulation phase. If
the second phase is not calculated, the second term in the bracket is omitted and the wait time
results in the duration of the simulation interval for phase 1 and the queue length at the end of
the first phase.
0
if Q ( L ) = 0
=
WL
else
--------------------------------------------- effectivecapacity
On inks with traffic jams, the effective capacity results from the minimum of link capacity
attribute Cap and reduced volume Vol, created through spillback congestion.
5.9
PTV AG
307
Minimum impedance value calculated hypothetically for the next iteration step on the
assumption that all vehicles based on the current impedances in the network use the
best path.
TEC =
ij r P
min
[ Rr R ij ] q r
ij
where
TEC
Difference between total impedance in the charged network and the hypothetical
impedance resulting if all vehicles took the shortest path per OD pair.
Pij
Rijmin
5.10
308
PTV AG
1. Impedance Ria is converted to the utility Uia of route i in the time interval a:
Uia = f(Ria)
2. From this utility Uia the percentage of demand Pia is calculated (where n is the total number
of routes).
a
a
P i :=
Ui
----------------------n
j = 1 Uj
The models reveal differences in the functional relation f of impedance and utility.
5.10.1
Ui = Ri
a
P i :=
Ri
-----------------
a
Rj
j
The sum of all routes j is taken and is used as a parameter for modeling the impedance
sensitivity. In this distribution method, the ratios of the various impedances are decisive. It
does not matter, therefore, whether two routes have impedances of 5 and 10 minutes, for
example, or 50 and 100 minutes the distribution is the same. The illustration 87 shows the
parameterization of the Kirchhoff distribution model on the interface.
5.10.2
Ui = e
PTV AG
Ri
309
a
P i :=
Ri
e
------------------------a
j e
Rj
5.10.3
()
x 1
-------------(x)
log ( x )
if 0
if = 0
When calculating the utility, b()(Ria) is now included in the Logit model instead of Ria, thus
a
Ui = e
()
( Ri )
results.
The percentage Pia of the route i in terms of the demand for time interval a is then calculated
as follows:
a
P i :=
()
( Ri )
e
-------------------------------------a
()
j e
( Rj )
The importance of the Box-Cox model is illustrated by the two special cases below.
310
PTV AG
With these parameter settings, b(0)(Ria) = log(Ria) applies, thus the following applies to the
choice:
a
a
Pi
log ( R )
i
Ri
e
- = -----------------= ---------------------------------a
log ( R j )
a
Rj
e
a
Pi
( Ri 1 )
i
e
e
- = -----------------------= -----------------------------------a
a
( Rj 1 )
Rj
e
e
5.10.4
--------- 1
R amin
e
a
P i := ---------------------------------------------applies.
2
a
j e
Rj
--------- 1
R amin
Here, Rmina := minjRja is the smallest occurring impedance, and is again a parameter to
control the impedance sensitivity. When calibrating, do not forget that is squared.
PTV AG
311
In this case, the impedance of a route is related to the minimum impedance, which therefore
measures the relative difference from the optimum. Due to this different approach, the Lohse
model can be used as an alternative to Kirchhoff and Logit. It should be noted, that the Lohse
distribution formula cannot be regarded as a special form of Box-Cox transformation. The
illustration 90 shows the parameterization of the Lohse distribution model on the interface.
5.10.5
Ui = e
R ai
--------- 1
R amin
--------- 1
R amin
e
a
P i := ---------------------------------------------2
a
j e
Rj
--------- 1
R amin
= ------------------------------------a
1+e
( R min )
312
PTV AG
The following example illustrates the effect of the distribution model Lohse with variable beta.
The illustration 91 compares different best paths (10 min, 50 min, 150 min, 300 min) with
"detour" alternatives. The distribution to the routes is done on the basis of the sumptuary ratio
and the absolute value of the best path.
For shorter best paths and their alternatives lower detour sensitivity is assumed than for longer
best paths.
Illustration 91: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse)
10
0.800
Rmina
0.010
10 min
3.32
10
0.800
0.010
50 min
4.26
10
0.800
0.010
150 min
6.68
10
0.800
0.010
300 min
9.00
Table 96: Parameters for the distribution with variable beta in illustration 91
The illustration 92 shows the parameterization of the Lohse distribution model with variable
beta on the interface.
PTV AG
313
Illustration 92: Parameterization of the Lohse distribution model with variable Beta
5.10.6
Example 1
Alternative 1 has an impedance of 5, alternative 2 an impedance of 10. Thus alternative 2
has a 5-unit higher impedance or a double impedance compared to alternative 1.
Example 2
The impedance of example 1 is increased by 100 units, so that alternative 1 now has an
impedance of 105 and alternative 2 an impedance of 110. This means that alternative 2
thus has a 5-unit higher impedance, as in example 1; however, the impedance ratio is now
0.95 rather than 0.5.
Example 3
The impedance of example 1 is doubled, so that alternative 1 now has an impedance of 50
and alternative 2 an impedance of 100. This now means that alternative 2 has a 50-unit
higher impedance; the impedance ratio is 0.5 as in example 1.
The distribution results demonstrate that in the Logit model the difference of impedances is
decisive, so that examples 1 and 2 result in the same distribution values. The Kirchhoff model,
on the other hand, evaluates the ratio of the impedances and thus generates the same
distribution values for examples 1 and 3. The Box-Cox model allows a combination of Logit
and Kirchhoff, which is also illustrated by the distribution values.
It would seem that the Logit model cannot be recommended for practical use, because the
basis for a passengers choice is different for short and long connections. In practice, it will
certainly make a difference whether a passenger has to travel 5 and 10 minutes (table 97), or
105 and 110 minutes (table 98). In the case of long journeys, the additional 5 minutes are not
as important as in case of short trips. The weaknesses of the Kirchhoff model in the example
in table 99, where one can expect all passengers to chose alternative 1, are not relevant for the
assignment, because connections that differ to such an extent would not be found in the search
at all and would therefore not be real alternatives for the road-user.
314
PTV AG
No.
Kirchhoff
Logit
Box-Cox
Lohse
94 %
78 %
86 %
100 %
10
6%
22 %
14 %
0%
Kirchhoff
Logit
Box-Cox
Lohse
105
55 %
78 %
62 %
51 %
110
45 %
22 %
38 %
49 %
Table 98: Distribution for two alternatives with impedance 105 and 110
No.
Kirchhoff
Logit
Box-Cox
Lohse
50
94 %
100 %
100 %
100 %
100
6%
0%
0%
0%
Table 99: Distribution for two alternatives with impedance 50 and 100
Kirchhoff
=4
Logit
= 0.25
Box-Cox
= 1, = 0.5
Lohse
=4
5.11
Incremental assignment
The incremental assignment procedure models how a network continuously fills up. At the
beginning, road users can use a free network for which exactly one shortest route exists for
every origin/destination relation. The traffic network is then successively loaded. Every step
congests the road network with additional vehicles and, in this way, increases impedance on
the congested links, turns and connectors. Because of the changed impedance, alternative
shortest routes may be found in every step.
The matrix is incrementally assigned to the network in the form of several parts. In this process,
the entire demand is proportionally distributed over the number of iteration steps defined by the
user (maximum 12). The default is an incremental assignment with three iteration steps (33 %,
33 % and 34 %).
PTV AG
The first step determines lowest impedance routes for all required OD-relations of the
current network for either a free network or based on a basic volume.
The defined percentage of the first incremental step of the matrix is then assigned to these
routes.
Subsequently, the new network impedances resulting from these volumes are calculated
via the VD functions.
On this basis, the next iteration step again calculates lowest impedance routes.
315
This procedure is continued until the entire matrix has been assigned to the network.
If 100% is entered for the first iteration step, Visum calculates the impedances of the current
network and carries out a so-called best-route assignment.
5.11.1
Iteration step 1
The shortest route, in the unloaded network, is route 2 with an impedance of 18:00 min. It
is loaded with 50 % of the car trips, i.e. 1,000 car trips.
Iteration step 2
The shortest route in the unloaded network is route 1 with an impedance of 20:50 min. It is
loaded with 25 % of car trips, that is, with 500 car trips.
Iteration step 3
After the second iteration step, route 1 remains the shortest route with an impedance of
29:50 min. It is again loaded with 25 % of the car trips, i.e. with another 500 car trips. It now
has a total of 1,000 car trips.
After the third iteration step, route 3 turns out to have the lowest impedance.
This route, however, is no longer found because all trips have been assigned.
In the example above, the impedance of a route results from the sum of the link impedances of
the route. Additional impedances for connectors and turns are not considered. In addition to
this, it is assumed that impedance results from current travel time tCur, and that current travel
time in turn results from the BPR function with a=1, b=2 and c=1.
LinkNo
316
Type
Length [m]
v0 [km/h]
Capacity
t0 [min]
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
30
16,000
80
800
12:00
30
5,000
80
800
03:45
10
40
10,000
60
500
10:00
11
40
5,000
60
500
05:00
PTV AG
Route
Length [m]
t0 [min]
1+8+9
26,000
18:45
1+2+3+5+6+7
30,000
18:00
10+11+5+6+7
30,000
24:00
LinkNo
Volume
tCur
Step 1 (50%)
Volume
tCur
Step 2 (25%)
Volume
tCur
Step 3 (25%)
1,000
05:05
1,500
07:41
2,000
11:20
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
1,000
05:05
12:00
500
16:41
1,000
30:45
03:45
500
05:13
1,000
09:37
10
10:00
10.00
10.00
11
05:00
05:00
5:00 AM
Route
Volume
tCur
Step 1 (50%)
Volume
tCur
Step 2 (25%)
Volume
tCur
Step 3 (25%)
20:50
500
29:35
1,000
51:42
1,000
30:30
1,000
33:06
1,000
36:45
30:15
30:15
30:15
Table 101: Example of the incremental assignment (BPR function a=1, b=2, R=tCur)
5.11.2
PTV AG
317
Input
Demand matrix F
Number of iteration steps N
Demand proportion Pn for each iteration step n = 1, N
n=0
Volume q 0 = 0 or basic volume
Impedance
determination
Route search
Volume
n = n +1
no
Query
n= N ?
yes
End
5.11.3
318
PTV AG
PTV AG
x1
(X)
(*)
Apart from the parameters which are directly set in the assignment procedure
319
5.11.4
5.12
The number and the size of layers (partial matrices) mainly decide on the goodness of the
results. However, there is no procedure to specify optimal layers.
The calculation ends after the specified number of steps has been executed without
checking correspondence between the resulting traffic volume and link impedances.
Equilibrium assignment
The Equilibrium assignment distributes the demand according to Wardrop's first principle.
"Every road user selects his route in such a way, that the impedance on all alternative routes
is the same, and that switching to a different route would increase personal travel time (user
optimum)."
This behavioral hypothesis underlies the unrealistic assumption that every road user is fully
informed about the network state. In transport planning this hypothesis is approved of given a
fundamental methodical advantage of the equilibrium assignment - with quite general
320
PTV AG
requirements, the existence and uniqueness of the assignment result (expressed in volumes
of the network object) is guaranteed. Moreover, measures for the distance of an approximation
solution from the equilibrium exist, from which an objective termination criterion can be derived
for the procedure, which generally is an iterative problem solution.
The equilibrium assignment determines a user optimum which differs from a system optimum,
as shown in table 104 and table 105.
A user optimum means that the same impedance results for all routes of a traffic relation
between zones i and j (within the scope of calculation accuracy). This results directly from
the condition, that changing to another route is not profitable for any road user (table 104).
A system optimum however means that the total impedance in the network, which is the
product of route impedance and route volume is minimized for all OD pairs. On average,
this procedure leads to shorter journey times per road user, but there are (few) road users
which use routes to serve the general public, with an impedance above average
(table 105).
Route
Links
Volume
tCur [min]
Volume tCur
1+8+9
736
38:19
470:05:53
1+2+3+5+6+7
995
38:21
636:01:21
10+11+5+6+7
269
38:20
171:50:02
Total
2,000
1277:57:17
Table 104: Calculation of the user optimum for the example network
Route
Links
Volume
tCur [min]
Volume tCur
1+8+9
734
37:43
461:46:27
1+2+3+5+6+7
919
37:13
569:58:45
10+11+5+6+7
347
41:13
238:11:24
Total
2,000
1269:56:36
Table 105: Calculation of the system optimum for the example network
5.12.1
PTV AG
Because the procedure only terminates when all routes of any OD pair are in the balanced
state, the procedure provides more realistic results than the incremental procedure.
For a lower volume/capacity ratio, a similar result is achieved as with best-route
assignment, because the route search does not find new routes. In this case it is
recommended to use an incremental assignment with suitable parameters as initial solution
or the Equilibrium_Lohse procedure.
The computation time required by the equilibrium assignment depends on the volume/
capacity ratio in the network. Because new routes are found in every iteration step for a
strongly saturated network, more computation time is required in this case.
Compared to stochastic assignment procedures (see "Stochastic assignment" on page 365
and "Dynamic stochastic assignment" on page 419) the equilibrium assignment provides
distinct network volumes. Compared to the number of calculated iterations, the gap is a
more objective termination criterion.
321
5.12.2
The impedance of the links is determined from the current travel time tCur. The current
travel time tCur is in turn calculated using the capacity restraint function BPR with a=1, b=2
and c=1.
The access and egress times for the connectors are not considered, that is, they are set to
0 minutes.
Turn penalties are not considered.
The traffic demand between A-Village and X-City is 2,000 car trips during peak hour.
Capacity and demand refer to one hour.
The example network contains three routes which connect village A and city X.
Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.
322
PTV AG
village A
1
10
10
11
12
11
41
20
40
21
30
city X
31
Type
Length [m]
v0-PrT [km/h]
10
20 Federal road
5,000
1,200
100
11
20
20
20 Federal road
5,000
1,200
100
21
20 Federal road
5,000
1,200
100
20
40
90 Rail track
10,000
21
30
20 Federal road
5,000
1,200
100
30
31
20 Federal road
5,000
1,200
100
31
40
20 Federal road
5,000
1,200
100
11
41
30 Country road
16,000
800
80
40
41
30 Country road
5,000
800
80
10
10
12
40 Other roads
10,000
500
60
11
12
21
40 Other roads
5,000
500
60
As a result, the assignment provides values from table 107 for the three routes (PrT paths).
Route
tCur
Impedance
Volume(AP)
46min 39s
2,798
1,157.488
46min 34s
2,794
618.079
46min 12s
2,772
224.432
PTV AG
323
The most important assignment results for the links are displayed in table 108.
Link tCur
11min
40s
700
1,908
9,537.839
5min 47s
347
1,157
5,787.442
5min 47s
347
1,157
5,787.442
7min 48s
468
1,450
7,249.603
7min 48s
468
1,450
7,249.603
7min 48s
468
1,450
7,249.603
26min
35s
1,595
750
12,001.270
8min 19s
499
750
3,750.397
10
15min
12s
912
292
72
2,924.321
11
7min 36s
456
292
72
1,462.161
5.12.3
324
PTV AG
PTV AG
x1
(*)
Apart from the parameters which are directly set in the assignment procedure
325
If you use metric units, enter the long lengths for kilometers and speeds in km/h. For imperial
units enter the long lengths in miles and speeds in mph.
5.12.4
min!
aE
Ra ( x ) dx
0
r qijr = qij, ij
ijr : a P
a E
q ijr = q a, a
ijr
qa
aE
qa =
326
E
qa
Ra(x)
qij
qijr
Pijr
E+u
volume of object a
PTV AG
E-u
Du
Ou
In Visum, edges are all links, turns and connectors, whereas nodes are zones and network
nodes.
The objective function shows that the sum of impedances of all edges is minimized. The
secondary conditions indicate the following (from top to bottom).
Due to the non-linear objective function, the optimization problem is not solved directly but
iteratively. Because of the monotonicity of the impedance function, the minimum is reached, so
that starting with a starting solution between the alternative paths, a movement i-j is shifted, so
that the paths all have the same impedance.
During the equilibrium assignment the steps showed in illustration 95 will be made.
PTV AG
327
Input
n =0
Network
balancing
n = n +1
Route search
Query
yes
no
End
Illustration 95: Procedure of the equilibrium assignment
328
PTV AG
Network balancing
The procedure of the network balancing is displayed in illustration 96.
Input
Route search
Pair balancing
Update
impedance
Query
no
yes
End
Illustration 96: Procedure of the network balancing for an OD pair in the equilibrium assignment
Termination criterion
Visum cancels the iteration process for calculating the equilibrium, if one of the following
conditions has been fulfilled:
PTV AG
Network balancing has been achieved, this means a permitted deviation of impedances of
the routes compared in pairs was reached or undercut.
The specified number of external iterations was reached without a network balancing being
reached (in very highly loaded networks it is possible that the permitted deviations which
were specified do not result in a state of balance because only integer vehicles are shifted).
The convergence criterion Max. gap is reached or undercut.
329
5.12.5
In case of an equilibrium assignment with blocking back model the maximum deviation was
reached or undercut (see "Blocking back model" on page 292). The procedure is cancelled
if the congestion volume values and the congestion wait times of two external iterations
deviate by the max. rel. difference or less.
Volume
tCur [min]
Starting solution
1,000
51:42
1,000
36:45
30:15
Network balancing 0
776
41:54
Routes 1 + 2
1,224
41:56
33:22
649
36:25
Routes 1 + 3
1,224
42:58
127
36:23
649
35:15
Routes 2 + 3
1,067
40:17
284
40:15
734
38:09
Routes 1 + 2
982
38:10
277
38:51
741
38:27
Routes 1 + 3
982
38:07
277
38:31
741
38:30
Routes 2 + 3
990
38:14
269
38:15
736
38:19
Routes 1 + 2
995
38:21
269
38:20
330
PTV AG
The table 111 shows how the equilibrium procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 213). The volume determined
with the incremental procedure is used here as the initial solution (see "Example of the
incremental assignment" on page 316). This starting solution encompasses two routes, each
loaded with 1,000 car trips. The specified absolute deviation is a value of five impedance units,
and the relative deviation is specified as being 0.1 %. Based on the starting solution, the
following steps are then carried out.
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
PTV AG
331
5.13.1
cij
cij(fij)
ZN
Dod
Kid
ij
Demand flow between origin oZ and destination dZ, generic element of the (|Z|21) vector
D, that is the demand matrix in row major order
ijk = 1, if arc ijA belongs to path k, and 0, otherwise for kK, this is the generic element
of the (|A||K|) matrix D
odk
Fk
Ck
The cost of path k for kK this is the generic element of the (|K|1) vector C
Wid
|S|
There are two fundamental relations between flow variables. The flow on arc ijA is the sum
of the flows on the paths that include it:
fij = kK ijk Fk
The travel demand between origin oZ and destination dZ must be equal to the sum of the
flows on the paths that connect them:
kKod Fk = Dod
(6)
By definition, the minimum cost to reach destination dZ from node iN is the cost of any
shortest path that connects them:
332
PTV AG
(7)
In this case, the traffic assignment problem can be formalized through the following program:
min (f) =
c
(
x
)
d
x
:
f
ij A ij
f ij
(8)
where
To ensure the existence and uniqueness of the solution to problem (8) we assume that:
cij(fij) is non-negative, continuous, strictly monotone increasing;
Kod is non-empty;
Dod is non-negative.
Problem (8), which is convex, can also be expressed in terms of path flows as follows:
k K ij Fk
min (F) =
c
(
x
)
d
x
:
F
(9)
ij
ij
f=0
where, although the solution uniqueness does not hold anymore, the convexity of the
mathematical program is preserved, implying that any descent algorithm in the space of path
flows will provide one of the global solutions, which then make up a convex set.
k
The relevance of program (9) to traffic assignment stands from the fact that, in the case of
additive path costs, its first order (necessary) conditions coincide with the following formulation
of the deterministic user equilibrium based on Wardrop's Principles, for each oZ and dZ:
kKod
(10.1)
Ck Wo ,
kKod
(10.2)
Fk 0,
kKod
(10.3)
Fk (Ck - Wod) = 0,
d
kKod Fk = Dod
(10.4)
all used paths (Fk > 0) have minimum cost (Ck = Wod);
any unused path (Fk = 0) has not a lower cost (Ck Wod).
We have a user equilibrium if conditions (10.1) to (10.4) hold jointly for each OD couple, while
considering that each path cost Ck is a function (potentially) of all the path flows F through the
arc cost function:
Ck = ijA ijk cij(kK ijk Fk), in compact form C = T c(F)
(11)
Since the gradient of (F) C = T c(F), by linearizing the objective function of problem (9) at
a given a point F, for X F we obtain:
PTV AG
333
(12)
From equation (12) we recognize that a direction E-F is descent if and only if:
CT(E-F) < 0.
(13)
In other words, to decrease the objective function and maintain feasibility we necessarily have
to shift path flows getting a lower total cost with respect to the current cost pattern, i. e. move
the current solution from F towards an E such that CTE < CTF, where C = Tc(F). The
necessity derives from the convexity of the problem, since in this case at any point X such that
CT(X-F) > 0 we have: (X) > (F).
This approach to determine a descent direction can be applied to each OD pair separately, to
each destination, or to the whole network jointly. Based on the above general rule, setting the
flow pattern E by means of an all-or-nothing assignment to shortest paths clearly provides a
descent direction. If we adopt such a direction for all OD pairs of the network jointly, and apply
along it a line search, we obtain the well known Frank-Wolfe algorithm. However, at equilibrium
each OD pair typically uses several paths, implying that any descent direction that loads a
single path is intrinsically myopic; in fact such algorithms tail badly.
Once we get a feasible descent direction E-F, since is convex, we can move the current
solution along the segment F+(E-F) and take a step (0,1] such that the objective function
of problem (9), redefined as () = (F+(E-F)), is sufficiently lowered. In this respect,
knowing that is C1 and convex, and thus also is such, several methods are available to
determine an which minimizes (). Visum uses an Armijo-like search and determines the
largest step = 0.5k, for any non-negative integer k, such that
(0.5k)/ < 0.
(14)
This method requires to compute the directional derivative of the objective function:
()/ = [c((F+(E-F)))]T[(E-F)],
(15)
which implies to evaluate the arc costs at the candidate flows F+(E-F) and then the
difference between the corresponding total costs obtained with the flows E and F. If such total
costs with E are smaller than those with F, then ()/ is negative so that the optimal solution
is more toward E, and vice versa.
5.13.2
334
PTV AG
To reach any destination dZ, at the equilibrium only shortest paths are utilized. Given that the
arc cost functions are strictly monotone increasing, they make up an acyclic [*1] sub-graph of
G, i.e. a (reverse) bush rooted at d. At strict monotonicity, any arc cost can be null only if its flow
is such. However, in Visum links and connectors may have null impedance, producing twofold
consequences: a) the corresponding arc cost functions loose strict monotonicity, so that
uniqueness is not guaranteed anymore. b) The sub-graph made-up by arcs with positive
destination flows at some of the possible equilibria may be cyclic. The implementation of LUCE
in Visum specifically addresses this issue and converges to one among the possible equilibria
by forcing an acyclic solution and equally splitting the flow among all alternatives with minimum
cost in presence of uncongested sub-paths. This special case is not further dealt with below.
On this base, when seeking a descent direction, in the following we will limit our attention to the
current bush B(d) and introduce an updating mechanism to make sure that eventually any
shortest path will be included into it; equilibrium is actually only attained this way. Let us focus
on the local route choice at a generic node iN for road users directed to destination dZ.
For the topology of the bush we will use the following notation:
FSB(i, d) = {jN: ijB(d)} the forward star of node iN made-up by nodes that can be
reached from it through arcs belonging to the current bush B(d) of
destination dZ
BSB(i, d) = {jN: ijB(d)} the backward star of node iN made-up by nodes that can reach it
through arcs belonging to the current bush B(d) of destination dZ
yijd
yijd = fijd / fid current flow proportion on arc ijA directed to destination dZ, if
fid > 0, yijd = 0 else
eijd
PTV AG
335
eid
gij
Gid
The average cost Cid is the expected impendence that a user encounters by travelling from
node iN to destination dN. Here it is defined recursively based on the current flow pattern:
if fid > 0, then Cid = jFSB(i, d) yijd (cij + Cjd), else
(16.1)
(16.2)
as if drivers utilize paths accordingly with the current flow proportions. In the following we
assume that the cost function cij(fij) is continuously differentiable for each arc ijA:
gij = cij(fij) / fij
(17)
Under the assumption that an infinitesimal increment of flow leaving node iN directed towards
destination dZ would diverge accordingly with the current flow proportions, we have:
if fid > 0, then Gid = Cid / fid = jFSB(i, d) yijd 2 (gij + Gjd), else
Gid
jFSB(i, d) [Cid
= cij +
Cjd]
(gij +
Gjd)
jFSB(i, d) [Cid
= cij +
(18.1)
Cjd],
(18.2)
where the derivatives gij + Gjd are scaled by the shareyijd of fid utilizing arc ij and then passing
through node j, that jointly with the flow proportion involved in the averaging yields the square
yijd 2.
The average costs and their derivatives can be computed by processing the nodes of the bush
in reverse topological order according to d, starting fromCdd = Gdd = 0.
We now address the local user equilibrium for the eid drivers directed to destination dZ, whose
available alternatives are the arcs of the bush exiting from node iN. To each travel alternative
we associate the cost function:
vijd(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),
(19)
resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing the generic arc ij, with jFSB(i, d).
This problem can be formulated, in analogy to (10.1) to (10.4), by the following system of
inequalities:
eijd [vijd(eijd) - Vid] = 0,
jFSB(i, d),
(20.1)
vijd(eijd) Vid,
jFSB(i, d),
(20.2)
eijd 0,
336
jFSB(i, d),
(20.3)
PTV AG
(20.4)
where we denote:
Vid
vijd
Cost of the local alternative jFSB(i, d), to reach destination dZ from node iN via j.
If eid = 0, the solution to the above problem is trivially: eijd = 0, for each jFSB(i, d). Consider
then the case where eid > 0. To improve readability, problem (20.1) to (20.4) can be rewritten
as:
xj (aj + bj xj - v) = 0,
jJ,
(21.1)
aj + bj xj v,
jJ,
(21.2)
xj 0,
jJ,
j xj = 1,
(21.3)
(21.4)
where:
J
aj
bj
xj
eijd / eid
Vid
Applying the usual Beckmann approach we can reformulate the equilibrium problem (21.1) to
(21.4) as the following quadratic program:
min{jJ 0 xj(aj + bj x) dx: xX} = min{jJ aj xj + 0.5 bj xj2: xX},
(22)
where X is the convex set of all vectors satisfying the feasibility conditions (21.3) and (21.4).
The gradient of the objective function is a vector with generic entry aj + bj xj, and then the
Hessian of the objective function is a diagonal matrix with generic entry bj. Therefore, if all
entries bj are strictly positive, the Hessian is positive definite and problem (22) has a unique
solution. In order to ensure such a desirable property we assume without loss of generality that
the derivates gij are strictly positive for all arcs ijA. Since the arc cost functions are strictly
monotone increasing, gij can be zero only if also fijd is zero. Therefore, at the equilibrium bj = 0
implies xj = 0. In practice we will substitute any gij = 0 with a small .
To solve problem (21.1) to (21.4) we propose the following simple method. In order to satisfy
condition (21.1), either it is xj = 0, and in this case condition (21.2) requires aj v, or it is aj + bj
xj = v. Let J0 J be the set of alternatives with zero flow, that is J0 = {jJ: xj = 0}. For any given
J0 the solution is immediate, since from (21.4) it is jJ (v - aj) / bj = 1; therefore we have:
v = (1 + jJ\J0 aj / bj) / (jJ\J0 1 / bj),
PTV AG
(23.1)
xj = (v - aj) / bj,
jJ\J0,
(23.2)
xj = 0,
jJ0.
(23.3)
337
The flow proportions provided by (23.1) to (23.3) implicitly satisfy (21.4). But to state that the
chosen J0 yields the solution of problem (21.1) to (21.4), we still must ensure the following
conditions: aj < v, for each jJ\J0 (as required by (21.3), since xj = (v - aj) / bj > 0), and aj v, for
each jJ0 (as required by (21.2), since xj = 0). This implies that at the solution the value of v
resulting from (23.1) must partition the set J into two sub-sets: the set J0, made up by the
alternatives j such that aj v; and its complement J\J0, made up by the alternatives j such that
aj < v.
At a first glance the problem to determine the set J0 of alternatives with zero flow may seem to
be combinatorial. However, this is not the case. The equation (23.1) can be rewritten as a
recursive formula. It then shows the effect of removing an alternative k from the set J0:
v[J0\{k}] = (v[J0] jJ\J0 1 / bj + ak / bk) / (jJ\J0 1 / bj + 1 / bk).
(24)
The right hand side of (24) can be interpreted as an average between v[J0] and ak with the
positive weights jJ\J0 1 / bj and 1 / bk. Therefore, the local equilibrium cost increases by
removing from J0 any alternative kJ\J0, for which ak is higher than the current value v[J0]. Vice
versa it decreases by adding such alternatives to J0. Consequently, the correct partition set J0
can be simply obtained by adding iteratively to an initially empty set each alternative jJ\J0
such that aj > v, i.e. each alternative for which (23.2) yields a negative flow proportion.
5.13.3
Descent direction
To obtain a complete pattern of arc flows ed for a given destination dZ consistent with the local
user equilibrium we simply have to solve problem (20.1) to (20.4) at each node iN\{d}
proceeding in topological order, where the node flow is computed as follows:
eid = jBSB(i, d) ejid + Did
(25)
We have shown that a given direction is descent if, and only if (13) applies (see "Mathematical
formulation and theoretical framework" on page 332). In terms of arc flows directed to
destination dZ, the following results:
ijA cij (eijd - fijd) < 0,
(26)
d
expressing that the shift of flow from f to e must entail a decrease of total cost with respect to
the current cost pattern. The proof that the proposed procedure provides a descent direction
goes beyond the scope of this description. For more detailed information, please refer to
Gentile G., 2009.
In the following we present an example showing the computation of the descent direction
provided by the LUCE algorithm. We consider the graph of the Braess paradox, with 4 nodes
and 5 arcs.
338
PTV AG
Illustration 98: Numerical example of the procedure to obtain the descent direction
The arc cost function is cij = Tij + Qij fij2, so that its derivative is gij = 2 Qij fij.
There is only one destination d = 4, and two origins with travel demand D14 = 9 and D24 = 2. We
consider an initial flow pattern where all available paths, the 3 routes from 1 to 4 and the 2
routes from 2 to 4, are equally used by each OD pair. In this case it is fij = fijd and the bush is
the entire network.
After we evaluate at the current flow pattern the arc costs and their derivatives, we can
compute for each node i the average cost Cid and its derivative Giditeratively starting from the
destination, where Cdd = Gdd = 0, and proceeding in reverse topological order. To this aim we
apply the formulas:
Cid = jFSB(i, d) yijd (cij + Cjd), Gid = jFSB(i, d) yijd 2 (gij + Gjd).
While the computation for node 3 is trivial, since its forward star is a singleton, for node 2 we
have:
C24 = y234 (c23 + C34) + y244 (c24 + C44) = 0.5 (21 + 52) + 0.5 (42 + 0) = 57.5,
G24 = y234 2 (g23 + G34) + y244 2 (g24 + G44) = 0.52 (8 + 14) + 0.52 (16 + 0) = 9.5,
PTV AG
339
Illustration 99: Numerical example of the procedure to obtain the descent direction
Now we can compute for each node i the node flows eid and the arc flows eijd iteratively by
proceeding in topological order.
To this aim we shall focus on the local route choice of the eid users, whose available
alternatives are the arcs of the bush exiting from node i. To each travel alternative we
associate the cost function:
vij(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),
resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing arc ij, and we look for an equilibrium. We have shown that the latter can be
determined using the following formulas:
Vid = (1 + jJ aijd / bijd) / (jJ 1 / bijd), eijd = eid (Vid - aijd) / bijd,
where: aijd = (cij + Cjd) - (gij + Gjd) eid yijd, bijd = (gij + Gjd) eid. J is set initially to the forward
star FSB(i, d); if some eijd results to be negative, then it is set to zero, j is removed from J and
the computation is repeated.
We start then with node 1, whose node flow is e14 = D14 = 6:
a134 = (c13 + C34) - (g13 + G34) e14 y134 = (29 + 52) - (12 + 14) 9 0.33 = 3
a124 = (c12 + C24) - (g12 + G24) e14 y124 = (41 + 57.5) - (12 + 9.5) 9 0.66 = -30.5,
b134 = (g13 + G34) e14 = (29 + 14) 9 = 387.
b124 = (g12 + G24) e14 = (41 + 9.5) 9 = 454.5.
V14 = (1 + a134/b134 + a124/b124) / (1/b134 +1/b124) = (1+ 3/387-30.5/454.5) / (1/387+1/454.5) = 196.6,
e134 = e14 (V14 - a134) / b134 = 9 (196.6 - 3) / 387 = 4.5,
e124 = e14 (V14 - a124) / b124 = 9 (196.6 + 30.5) / 454.5 = 4.5.
Then we go on with node 2, whose node flow is e24 = e124 + D24 = 4.50 + 2 = 6.5:
a234 = (c23 + C34) - (g23 + G34) e24 y234 = (21 + 52) - (8 + 14) 6.5 0.5 = 1.5,
a244 = (c24 + C44) - (g24 + G44) e24 y244 = (42 + 0) - (16 + 0) 6.5 0.5 = -10,
340
PTV AG
Finally, we consider node 3, whose volume is e34 = e134 + e234 + D34 = 4.5 + 2.43 + 0 = 6.93:
Since there is only one alternative, the following applies: e344 = e34 = 6.93. Only for completeness we compute V34 as follows:
V34 = (c34 + C44) + (g34 + G44) (e344 - e34 y344) = (52 + 0) + (14 + 0) (6.55 - 6.93 1) = 46.7.
The flow pattern we have just found is a descent direction because we have:
ijA fijd cij = 949 > ijA eijd cij = 897.
The illustration 98 represents the AON assignment to shortest paths (marked by *). The
illustration 99 displays the equilibrium flow and cost pattern (marked by *). It can be seen that
one single iteration of the proposed descent direction allows a substantial step towards the
solution.
5.13.4
Assignment algorithm
Below we provide a pseudo code of the procedure within the framework of an assignment
algorithm.
function LUCE
f = 0
initialize the solution flows to zero
perform n iterations
for k = 1 to n
for each destination d
for each dZ
for each ijA
compute arc costs and their derivatives
cij = cij( fij)
gij = max{cij( fij)/fij, }
if fid > 0 then yijd = fijd / fid else yijd = 0
B(d) =B(B(d), c, f)
initialize or modify the current bush
Cd d = 0
the average cost of the destination is zero
Gdd = 0
so its derivative
for each i:ijB(d) in reverse topological order for each node i d in the bush
if fid > 0 then
Cid = jFSB(i, d) yijd (cij + Cjd)
compute the node average cost to d
and its derivative
Gid = jFSB(i, d) yijd 2 (gij + Gjd)
else
Cid = min{cij + Cjd: jFSB(i, d)}
Gid = jFSB(i, d) [Cid = cij + Cjd] (gij + Gjd) / jFSB(i, d) [Cid = cij + Cjd],
d
e = 0
reset the arc and node flows to d
for each oZ
load on the origins the demand to d
eod = Dod
for each i:ijB(d) in topological order for each node i d in the bush
J = FSB(i, d)
initialize the set of arcs with positive flow
= 0
until = 1 do
PTV AG
341
=1
The bush of each destination dZ is initialized with the set of efficient arcs that bring closer to
the destination, where the minimum costs are evaluated at zero flow. At the generic iteration,
any non-efficient arc on the bush carrying no destination flow is removed from it, while any arc
that would improve shortest paths on the bush is added to it, if its reverse arc does not carry
destination flow. If the resulting sub-graph is acyclic, then it is substituted to the current bush
of that destination. Since the LUCE algorithm tends to an equilibrium on the bush, eventually
the flow on non-efficient paths disappears and the bush can be properly modified.
Note that, beside the initialization of the bushes, the LUCE algorithm does not require shortest
path computations, but only simple visits of the bushes.
5.13.5
342
PTV AG
5.13.6
Skim matrix (also for a freely definable skim) in case of route-based assignments:
for the Minimum weight, always the shortest path is used for calculation
for the Mean over route volumes weight, the shortest path is used only if the OD pair
is not in the bush; otherwise, the skim data is weighted with the volumes of the edges
from the origin to the destinations.
Flow bundle
TFlowFuzzy
COM: TFlowMatrix
OD pair filter
Blocking back
Generate demand matrix from paths
5.13.7
PTV AG
343
5.13.8
Illustration 100: Example for the proportionality with balanced link volumes
The zones 1 and 2 are connected to node A, the zones 3 and 4 are connected to node B. A
and B are connected by the two links x and y, which have the same VDF. Demand is 500 trips
each from 1 to 3 and from 1 to 4. The image shows the resulting link volumes in the balanced
state. But the link volumes can result from the various route volumes overlaying on the links.
Three of them are listed in the table:
Volume
Variant 1
Variant 2
Variant 3
1-x-3
200
500
250
1-y-3
300
250
1-x-4
300
250
1-y-4
200
500
250
Table 112: Variants of route volumes for the link volumes in illustration 100
With regard to the impedance balance, all variants are equivalent, though variant 3 has the
advantage that the route distribution at node A is proportional for the relations to the zones 3
and 4. Since the links x and y have the same impedance one cannot assume that at node A
road users on their way to the destination x will not distribute to the links in the same way as
those heading to destination y.
Due to the separate handling of the OD pairs, the path-based equilibrium procedure could
generate any of the indefinite number of path volume variants arbitrarily, whereas LUCE
always charges the paths proportionally as shown in variant 3. But this advantage is based on
the fact, that LUCE simultaneously balances all path volumes to an origin zone. Identical turn
proportions can therefore be generated within an origin zone only, they are not reached for the
routes of various origin zones.
This is illustrated by the extended example in illustration 101, now with 500 trips each between
the zones 2 and 3, and 2 and 4. Again, the image shows balanced link volumes.
344
PTV AG
Illustration 101: Extended example for the proportionality with balanced link volumes
Even though the route distributions to the paths within an origin zone show consistent shares,
this does not apply to the paths of different origin zones. Again various volume variants can be
generated:
Volume
Variant 1
Variant 2
Variant 3
250
1-x-3
200
500
1-y-3
300
250
1-x-4
200
500
250
1-y-4
300
250
2-x-3
300
250
2-y-3
200
500
250
2-x-4
300
250
2-y-4
200
500
250
Table 113: Variants of route volumes for the link volumes in illustration 101
For the same reason as above, variant 3 is the preferable variant, since there is no need for
unequal loading of the routes. However, this balancing procedure cannot be performed in a
purely origin-based way. LUCE provides the option to harmonize the path volumes over all
origin zones subsequently to the determination of meshes of the same impedance (compare
mesh A-B in the example) which is based on the paths that were calculated during the actual
assignment. This is always the case, since in an isolated view the mesh is in a balanced state;
thus, volumes can be shifted between the path alternatives from different origin zones without
any changes to the link volumes or impedances. Thus, the equilibrium state can be retained.
Since mesh finding and route choice optimization are time-consuming this procedure is
provided as an option which can additionally be activated in the LUCE procedure parameters.
For the reliable detection of balanced meshes the assignment should have finished with a gap
of 10-6 or better. In this case, the optimization of the route distribution will additionally take
another 20% - 50% of the assignment run time.
The optimization of the route distribution is highly recommended if route volumes shall be
analyzed or used in further computations. This applies to the following operations:
PTV AG
345
But if primarily link-related assignment results are required (volumes, travel times), then
optimization is not required, since this would not improve the given results.
5.14
Equilibrium_Lohse
The Equilibrium_Lohse procedure was developed by professor Lohse and is described in
Schnabel (1997). This procedure models the learning process of road users using the network.
Starting with an "all or nothing assignment", drivers consecutively include information gained
during their last journey for the next route search. Several shortest routes are searched in an
iterative process whereby for the route search the impedance is deduced from the impedance
of the current volume and the previously estimated impedance. To do this, the total traffic flow
is assigned to the shortest routes found so far for every iteration step.
During the first iteration step only the network impedances in the free network are taken into
account (like 100 % best-route assignment).
The calculation of the impedance in every further iteration step is carried out using the current
mean impedances calculated so far and the impedances resulting from the current volume, i.e.
every iteration step n is based on the impedances calculated at n-1.
The assignment of the demand matrix to the network corresponds to how many times the route
was found ("kept in mind" by Visum).
The procedure only terminates when the estimated times underlying the route choice and the
travel times resulting from these routes coincide to a sufficient degree; there is a high
probability that this stable state of the traffic network corresponds to the route choice behavior
of drivers.
To estimate the travel time for each link of the following iteration step n+1, the estimated travel
time for n is added to the difference between the calculated actual travel time of n (calculated
from the VD functions) and the estimated travel time of n. This difference is then multiplied by
the value DELTA (0.15...0.5) which results in an attenuated sine wave.
The termination condition arises from the requirement that the estimated travel times for
iteration steps n and n-1, and the calculated actual travel time of iteration step n, sufficiently
correspond to each other. This is defined by the precision threshold EPSILON.
5.14.1
Type
Length [m]
20
5,000
v0 [km/h]
R0* [min]
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
346
PTV AG
LinkNo
Type
Length [m]
v0 [km/h]
R0* [min]
20
5,000
100
1,200
03:00
20
5,000
100
1,200
03:00
30
16,000
80
800
12:00
30
5,000
80
800
03:45
10
40
10,000
60
500
10.00
11
40
5,000
60
500
05:00
Links
Length [m]
1+8+9
26,000
R0* [min]
0:18:45
1+2+3+5+6+7
30,000
0:18:00
10+11+5+6+7
30,000
0:24:00
Input parameters:
V2 = 4
V3 = 0.002
2.5
f ( TT ) = ----------------------------------------
1+e
4 0.002 TT
TT1
f(TT1)
Delta 1
R1* [min]
2.78
0.0452
0.4796
07:00 a.m.
2,000
11:20 AM
2,000
11:20
2.78
0.0452
0.4796
07:00
2,000
11:20
2.78
0.0452
0.4796
07:00
2,000
11:20
2.78
0.0452
0.4796
07:00
2,000
11:20
2.78
0.0452
0.4796
07:00
2,000
11:20
2.78
0.0452
0.4796
07:00
12:00
0.00
0.0450
0.5000
12:00
03:45
0.00
0.0450
0.5000
03:45
10
10.00
0.00
0.0450
0.5000
10:00
11
05:00
0.00
0.0450
0.5000
05:00
Route
Volume 1
R1
R1*
0:27:05
0:22:45
PTV AG
347
Route
Volume 1
R1
R1*
2,000
1:08:00
0:41:59
0:49:00
0:35:59
LinkNo
TT2
f(TT2)
Delta 2
R2* [min]
2,000
11:20
0.62
0.0450
0.4925
09:08
1,000
05:05
0.27
0.0450
0.4962
06:03
1,000
05:05
0.27
0.0450
0.4962
06:03
1,000
05:05
0.27
0.0450
0.4962
06:03
1,000
05:05
0.27
0.0450
0.4962
06:03
1,000
05:05
0.27
0.0450
0.4962
06:03
1,000
30:45
1.56
0.0451
0.4855
21:06
1,000
09:37
1.56
0.0451
0.4855
06:36
10
10.00
0.00
0.0450
0.5000
10.00
11
05:00
0.00
0.0450
0.5000
05:00
Route
Volume 2
R2
R2*
1,000
0:51:42
0:36:50
1,000
0:36:45
0:39:22
0:30:15
0:33:08
348
LinkNo
TT3
f(TT3)
Delta 3
R3* [min]
1,333
0.27
0.0450
0.4963
07:56
06:42
667
03:56
0.35
0.0450
0.4953
05:00
667
03:56
0.35
0.0450
0.4953
05:00
1,333
06:42
0.11
0.0450
0.4984
06:22
1,333
06:42
0.11
0.0450
0.4984
06:22
1333
0.0450
0.4984
06:22
667
20:20
0.0450
0.4994
20:43
0.04
667
06:21
0.04
0.0450
0.4994
06:28
10
667
27:47
1.78
0.0451
0.4842
18:37
11
667
13:53
1.78
0.0451
0.4842
09:18
PTV AG
Route
Volume 3
R3
R3*
667
0:33:23
0:35:07
667
0:34:40
0:37:03
667
1:01:47
0:47:02
The table 114, table 115, table 116 and table 117 illustrate the first three iteration steps of the
Equilibrium_Lohse procedure for the example network.
Iteration step 1, n = 1
Volume 1
The volume of the first iteration step results from an "all or nothing" assignment onto the
lowest impedance route in the unloaded network. For impedance R0*, this is route 2 loaded
with 2,000 car trips.
Current impedance R1
The current impedance R1 of every link results from the BPR capacity function (a =1, b = 2,
c= 1). For link 1, for example, the following can be calculated:
R1 (link 1) = 3 min x (1+(2,000/1,200)) = 11 min 20s
V1
2.5
- = -------------------------------------------f ( TT 1 ) = ------------------------------------= 0.0452
V 2 V 3 TT 1
4 0.002 2.78
1+e
1+e
1 = Bottom +
Top Bottom
0,5 0,15
= 0.15 +
= 0.4796
(
)
f
TT
(1 + TT1 ) 1
(1 + 2.78)0.0452
Iteration step 2, n = 2
Volume 2
The lowest impedance route for R1* is route 1. Now two routes exist, route 1 and 2. Each
route is loaded with 1/n, i.e. the demand, so that each route is used by 1,000 cars.
Current impedance R2
The current impedance R2 of every link increases on newly loaded links 8 and 9, and it
decreases on links 2, 3, 5, 6 and 7.
PTV AG
349
Iteration step 3, n = 3
Volume 3
The lowest impedance route for R2* is route 3. 2,000 car trips are now equally distributed
across routes 1, 2 and 3.
Current impedance R3
The current impedance R3 again results from the current volume 3 via the VD function.
Iteration step 4, n = 4
The concluding route search based on R3* determines route 1 as the shortest route. Thus, the
following route volumes result:
5.14.2
350
PTV AG
PTV AG
x1
(X)
(*)
Apart from the parameters which are directly set in the assignment procedure
351
352
PTV AG
5.14.3
Input
n=n+1
Route
search
Route
volumes
TTn = Rn R *n 1 R *n 1
Impedance
determination
f (TTn ) = V1 (1 + e V2 V3 TTn )
n = lower +
upper lower
(1 + TTn ) f (TTn )
Query
no
Rn R
*
n 1
< E = E1 Rn 1
E2 / E3
yes
End
Illustration 102: Procedure of the Equilibrium_Lohse assignment
PTV AG
353
5.14.4
5.15
5.15.1
Fundamental principle
In Visum, any variant of the equilibrium assignment uses volume-delay functions for links and
turns to model the impedance that increases with increasing volumes. In urban network
models, the Turn VDFs are of particular importance, since the nodes affect the network
performance to a much greater extent than links do. The mathematical formulation of the
assignment problem assumes, that the impedance which is calculated by the VDFs depends
only on the volume and the capacity of the individual network object (link, turn). Volume delay
functions with this property are called separable VDFs. In reality, this holds approximately for
links, but it does not apply to turns via nodes. Typical counter-examples are the permitted turns
at signalized nodes or turns from minor approaches at two-way nodes. In these cases, the
impedance does not only depend on the volume of the turn itself, but also from the volumes of
the conflicting flows, i.e. the volumes of other turns via this node. Thus, the associated volumedelay functions can no longer be separable. This is a problem for the mathematical solution of
the assignment problem, since existence and uniqueness of the equilibrium solution require
separable volume-delay functions.
Two requirements can be derived from this analysis:
354
Realistic impedance modeling for nodes premises that nodes are modeled in detail in a way
that conflicts between turns can be identified correctly. Transferred to Visum this means,
that for these nodes the geometry and control have to be modeled in the junction editor.
Subsequently, precise impedances and capacities of the turns can be calculated using the
Intersection Capacity Analysis (ICA).
For lack of separability, the values calculated by means of ICA may not directly be used to
replace the volume-delay functions in the assignment procedure, since the convergence
would get lost then.
PTV AG
PTV AG
355
5.15.2
356
With the Use current assignment result as initial solution option set by default. the
assignment times required for subordinate LUCE assignment are short.
Stable route distribution, especially with option Optimization of the proportionality of
route volumes at meshes.
Calculation of the blocking back model, using so-called bushes, is considerably faster than
conventional calculation methods.
Due to the stable routes, also the blocking back result is more stable and thus convergence
can be reached sooner.
PTV AG
5.15.3
PTV AG
Prior to the assignment with ICA calculation, the geometry and control need to be modeled
correctly for the nodes the ICA impedance calculation has been activated for. To check
whether the calculation can be performed correctly for all nodes, from the Calculate menu,
choose >Network check and check the Viability for ICA option.
For turns, the design volume PrT needs to be a volume-representing attribute (Volume PrT
or Volume PrT with base). Enter the settings via menu Calculate > General procedure
settings > navigator entry PrT settings > Node impedances. For the design volume PrT,
only factor 1.0 is permitted. This is due to the fact, that the calibration of the VDFs by turn
would fail otherwise. The VD function used for turns is based on the hourly capacities
output by ICA. This means that you can only perform assignment with ICA for assignment
periods of 1h. As a result, hourly values for link and turn capacities must be defined.
357
358
PTV AG
x2
(x)
Meaning
Indicates whether the ICA-Turn function is to be used for this turn in the
assignment with ICA.
Last capacity used during assignment with ICA. The Capacity PrTV
attribute is not used for turns at (main) nodes calculated with ICA.
t0 that was recently used with ICA assignment. The t0 PrT attribute is
not used for (main) turns at nodes calculated with ICA.
Table 121: Additionally calculated turn/main turn attributes for assignment with ICA
Attribute
Meaning
Table 122: Additionally calculated link attributes for assignment with ICA
PTV AG
359
Furthermore, numerous diagnostic outputs are provided which can be used for convergence
check. If the procedure converges either slowly or not at all, the outputs provide useful
information, e.g. which turns show significant differences when calculated with ICA impedance
calculation or the VD function.
As long as the procedure is running, you can watch the process in the "Goodness of PrT
assignment with ICA" list.
*.csv files are created to which the program saves turn attribute data after each iteration.
These files are helpful when you want to compare the development of attribute values of
individual turns during the course of assignment with ICA.
Some result attributes of the assignment with ICA are saved to user-defined attributes, if
required. This data can be used for the comparison of the convergence reached in different
runs of the assignment with ICA. To do so, first copy the values of the user-defined
attributes, before they are overwritten during the next calculation.
Optionally, an Excel report is created which contains the results of the recent ICA
calculation. From the report it is to be seen, which volumes were used for the calculation
and which capacities resulted from that. For nodes of the all-way stop type, the v/c value is
output the same way as for nodes of the two-way stop type.
The precise times, when attribute data is stored in an iteration is described with the procedure
(see "Procedure of the Assignment with ICA" on page 360).
5.15.4
360
If the assignment with ICA is not based on existing assignment results, the parameters
used in the VD function for turns and links are first initialized. For turns, the input values are
used that you have specified in the Procedure parameters window (Input tab). Depending
on the control type used, additional signal times and geometric data are considered. The
parameters initialized for turn capacities, t0, and the VD functions A and B are used to
perform the first subordinate assignment. The link attribute Effective capacity in
assignment with ICA is initialized with the Capacity PrT value. If your assignment with
ICA is based on existing assignment results, the parameters are available from the last
assignment with ICA and initialization is skipped.
First the subordinate assignment procedure is performed. Choose one of the following
assignment procedures: Equilibrium assignment, Equilibrium_Lohse or Equilibrium
assignment (LUCE). For nodes, for which ICA calculation has been activated, use turnspecific VD functions. In this case, no ICA calculations are carried out during the
subordinate assignment procedure.
The turn-specific VD functions used and the adaptation of link VD functions are described
in separate paragraphs (illustration 104).
PTV AG
After completion of the subordinate assignment procedure, the blocking back model is
applied. For calculation of the blocking back model, the turn capacities at nodes calculated
with ICA are taken into account.. Optionally, you may additionally use the capacities
defined in the link capacity model. The link impedance results obtained through blocking
back model calculation are adjusted in order to account for the additional wait times caused
by traffic jams on the links.
Notes: By applying the blocking back model, only phase 1 is calculated.
The blocking back model is not applied while the subordinate assignment procedure is
performed.
During finalization of the ICA assignment, the global parameters of the blocking back
model (see User Manual, Chpt. 5.5.2, page 1008) are adapted to the procedure
parameters of ICA assignment, i.e. settings that differ are first ignored during ICA
assignment and then overwritten.
PTV AG
Prior to the ICA calculation, the current values are determined for volume and impedance
and also the parameters of the VDFs are recorded (according to the settings: in attribute
files, as user-defined attributes and in the Goodness of PrT assignment with ICA list).
Then, the turn volumes calculated in the recent iteration and in the current iteration are
smoothed, i.e. the weighted mean is calculated.
Using ICA, the program calculates turn impedances and capacities. For this ICA
calculation, the design volume used is the smoothed turn volume (including the basic
volume, depending on the design volume set).
Calculation of the new, turn-specific VD functions is performed in two steps and separately
for each turn. In the first step, the parameters of the VD function are determined through
interpolation of three sampling points. One sampling point is given by the smoothed turn
volumes and the respective impedance (see previous step). To determine two additional
sampling points, reduce or increase the volume of the turn currently being processed, while
maintaining the other turn volumes passing via the node. The impedance of the current turn
is then recalculated with ICA. Since the VD function to be interpolated possesses three free
parameters (t0, A, B), it is clearly defined by the three sampling points. In the second step,
these parameters and also the capacity are smoothed by means of the values resulting
from the previous iteration. In the procedure parameters, a minimum capacity per turn can
be set. If the smoothing result is below the minimum capacity, the minimum capacity will be
used instead. The convergence check is performed after the determination of the new
VDFs. If the convergence constraints are satisfied, the parameters of the VDF will be reset
to the value of the recent iteration. This means the VD functions are in accordance with the
subordinate assignment last performed. In the flow diagram, qTn represents the volume of
turn T in iteration n.
If the convergence test is failed, the attributes Deterred upstream volume in assignment
with ICA, for links and turns, and Effective capacity in assignment with ICA, for links,
are updated. These values are required for application of the VD function during the next
subordinate assignment (or for an assignment based on existing assignment results).
361
362
PTV AG
5.15.5
max ( 0, q q-
t 0 + A ----------------------------------
cap
t cur ( q, cap, t 0, A, B, q ) =
t + A
else
0
if q q cap
Thereby
tcur
PTV AG
Turn attribute corresponds to tCur of the turn-specific VD function including the VD function
parameters. Attribute tCur_PrTSys for assignment with ICA contains the value calculated
at the end of the assignment with ICA.
363
A and B
q
t0
cap
Turn attribute that corresponds to smoothed capacity in the assignment with ICA.
Attribute Final capacity for assignment with ICA contains the value calculated at the end
of the assignment with ICA.
Turn attribute calculated as the difference between demand volume and volume. Deterred
volume refers to the part of the volume that, according to blocking back calculation, is held
back at bottlenecks upstream from the turn and so does not reach it.
Attribute Deterred volume upstream in assignment with ICA contains the value
calculated at the end of the assignment with ICA.
Turn attribute
Attribute Final t0 for assignment with ICA contains the value calculated at the end of the
assignment with ICA.
During the assignment, the factors A and B are updated with each ICA impedance calculation
per turn. You can find the values of the last iteration in the turn attributes Final A for
assignment with ICA and Final B for assignment with ICA. The following data are also
saved to turn attributes: t0 values (Final t0 for assignment with ICA), the capacity (Final
capacity for assignment with ICA), and the difference between demand volume and current
volume (Deterred volume upstream in assignment with ICA).
Thereby
364
tcur
vdfbase
q
cap
effcap
PTV AG
Link attribute that represents the difference between demand volume and volume plus
queue length. Deterred volume refers to the part of the volume that, according to blocking
back calculation, is held back upstream and so does not reach the link.
Attribute Deterred volume upstream in assignment with ICAcontains the value
calculated at the end of the assignment with ICA.
By adapting the link VD function, you ensure that the additional impedance caused by spillback
congestion is accounted for in subordinate assignment, i.e. for route search and route choice.
5.16
Stochastic assignment
Stochastic assignment procedures assume that traffic participants in principle select the best
route, but evaluate the individual routes differently due to incomplete and different information.
In addition, in a stochastic PrT assignment the demand is distributed (see "Distribution models
in the assignment" on page 308) to the found routes as for a PuT assignment using a
distribution model (e.g. Logit, Kirchhoff, Box-Cox, Lohse or Lohse with variable beta).
In order to take the spatial similarities of the routes into account during the distribution, a
similarity measure is determined from overlapping routes (analogous to independence during
timetable-based PuT assignment) it is called the Commonality Factor (C-Logit) or the
independence of each route (according to Ben Akiva) is determined.
This results in the following sequence:
1. Route search for all traffic cells for current impedance.
2. Commonality Factor or independence calculated from overlapping of all routes of an origin/
destination pair.
3. Distribution of demand to the routes of each OD pair, taking the Commonality Factor or
independence into account.
4. Repeat from step 3 until demand for all OD pairs is in equilibrium.
5. Repeat steps 1 4 until no new routes are found or until the change in the link volumes
between two iteration steps is very small.
During the route search, the number of possible routes can be increased in that it is not just the
shortest route that is found, but a number of alternatives are found using a multiple best path
search and a variation in the link impedances.
5.16.1
PTV AG
365
5.16.2
366
PTV AG
(x)
(*)
Apart from the parameters which are directly set in the assignment procedure
5.16.3
PTV AG
The external (global) iteration with iterator n is used for the route search. This loop is
repeated until either n = N or until no new shortest routes are found.
The internal iteration with iterator m is used to assign the volume to the routes. This loop is
repeated until either m = M or until the deviations of the impedances on the network
elements and the deviation of the volumes on the routes between two iteration steps is very
small.
367
Start of
external
iterartion
Search
impedance
Counter for
external
iteration
Route search
Termination
external
iteration
R oute
preselection
Independence
368
n =0
n= n + 1
no
stop
ja
Delete all routes with R > a R* min + b and
t0 > c t 0,min + d
PTV AG
Start of internal
iteration
Initialisation of
choice
impedance
m =0
Counter for
internal
iteration
m= m +1
Choice
impedance
Route choice
q rm =
Route volume
Update search
impedance
q r (m1) ( m 1) + q rm '
m
*
*
Rnew
= Ro*ld + Rnew Rold
Termination
criterion for
internal
iteration
no
Termination of
external
iteration
ja
n = max. number of external iteration
stop
no
yes
The alternative route search by stochastic variation of the impedances is closely related to
other procedures used to determine k-shortest paths and shares their common drawback that
often new routes are found that differ insignificantly from previous routes. Such routes are not
desirable as they hardly change the volume situation in the network and only increase the route
quantity, which leads to extended computing time and higher memory requirements. For this
reason a detour test is offered as part of the stochastic assignment that discards a route r2 if a
route r1 already exists that matchesr2, with the exception of a subsection, and if this subsection
PTV AG
369
in r2 is significantly longer than in r1. More precisely, r2 is discarded in favor of r1 if the following
applies (illustration 106).
r1 = AT1B
r2 = AT2B
The route sections A and B can be empty if the subsection is at the start or the end of the
routes.
5.16.4
370
PTV AG
Case 1
Portion
Route 1
expected
Logit
Route 1
50%
50%
Route 2
50%
50%
Route 2
Impedance R1 = R2
Case 2
Portion
Route 1
expected
Logit
Route 1
33%
33%
Route 2
33%
33%
Route 3
33%
33%
Route 3
Impedance R1 = R2 = R3
Case 3
Portion
Route 2
Route 1
expected
Logit
Route 1
approx.
28%
33%
Route 2
approx.
44%
33%
Route 3
approx.
28%
33%
Route 3
Impedance R1 = R2 = R3
Route 2
The C-Logit approach proposed by CASCETTA is a suitable way of overcoming this problem.
To do this, a so-called commonality factor C is introduced to measure the overlapping of the
two routes r and s as follows:
PTV AG
371
t 0 rs
l rs
C rs = --------------------- or C rs = --------------t0 r t0 s
lr ls
with
Crs
t0rs
t0r
Time t0 of route r
lrs
lr
Length l of route r
Thus, Crs equals 1, if the two routes are identical, and will be 0, if the two routes do not overlap.
The commonality factor Crs is determined for all route combinations. Then, the correction factor
CFr of a route r compared to any other route s is defined as follows:
1 - = --------------------------------1
CF r = --------------- Crs 1 + Crs
rs
The correction factor of a route r is 1 if the commonality factors Crs for all routes s have the
value 0, i.e. the route has no overlap with another route. In any other case it is below 1. The
correction factor CFr is then regarded in the Logit model as follows:
Vr
e CFr
P = ------------------------------------------N
s = 1 ( e
Vs
CF s )
In the case of Box-Cox, Kirchhoff, Lohse or Lohse with variable beta, its inclusion is also
carried out in the same way.
Alternatively, the correction factor CFr can be determined using a simpler approach according
to Ben Akiva. It is then defined as:
CF r =
t0 a
- ---------
a P -----t 0 r N ija
or
CF r =
la
with
372
t0a
Time t0 of link a
t0r
Time t0 of route r
la
Length l of link a
lr
Length l of route r
Nija
PTV AG
5.16.5
= 8 R0.5
Compared to the "objective" impedances (resulting from impedance definitions and VDFs),
the impedances of the network objects are changed for alternative shortest path searches.
They are drawn randomly from a normal distribution which has the objective impedance R
as mean value and whose standard deviation is given as a function of R.
LinkNo
Type
v0 [km/h]
Length [m]
R0* [min]
R0* [s]
20
100
5,000
1,200
03:00
180
20
100
5,000
1,200
03:00
180
20
100
5,000
1,200
03:00
180
20
100
5,000
1,200
03:00
180
20
100
5,000
1,200
03:00
180
20
100
5,000
1,200
03:00
180
30
80
16,000
800
12:00
720
30
80
5,000
800
03:45
225
10
40
60
10,000
500
10:00
600
11
40
60
5,000
500
05:00
300
Route
Links
Length [m]
R0* [min]
R0* [s]
1+8+9
26,000
0:18:45
1,125
1+2+3+5+6+7
30,000
0:18:00
1,080
10+11+5+6+7
30,000
0:24:00
1,440
Input parameters
BPR function with a = 1, b = 2, c = 1
Bottom = 0.5, Top = 0.5 = 0.5
Assignment with Logit, = 0.001
Table 125: Impedance in the unloaded network, input parameters for stochastic assignment
After completing the search, the correction factor for the independence of each route is
determined according to Cascetta. It is based on the similarity of the individual route pairs with
reference to time t0 or to the length. The table 126 shows the commonality factors C. From this,
the correction factor CFr of route r is calculated.
Route 1
1 - = ----------------------------------------1
CF 1 = ---------------= 0.8596
+
1.0
0.16
+ 0.0
C
1j
j
PTV AG
373
Route 2
1 - = -------------------------------------------1
- = 0.6264
CF 2 = ---------------+
0.16
1.0
+ 0.43
C
2
j
Route 3
1 - = ----------------------------------------1
CF 3 = ---------------= 0.6978
+
0.0
0.43
+ 1.0
C3 j
j
Route pair
t0ij
t0i
t0j
Cij
1,1
1,125
1,125
1,125
1.00
1.2
180
1,125
1,080
0.16
1.3
1,125
1,440
0.00
2,1
180
1,080
1,125
0.16
2.2
1,080
1,080
1,080
1.00
2,3
540
1,080
1.440
0.43
3,1
1,440
1,125
0.00
3,2
540
1,440
1,080
0.43
3.3
1,440
1,440
1,440
1.00
Table 126: Calculation of the commonality factor C for all route pairs
The share by route is calculated from the correction factor according to Cascetta and from the
impedance Rmin0 in the unloaded network.
For Route 1, the portion is calculated using the Logit model as follows:
-0.0011125
0.8596 e
P 1 = ---------------------------------------------------------------------------------------------------------------------------------------------------------------= 0.425
-0.0011125
-0.0011080
-0.0011440
0.8596 e
+ 0.6264 e
+ 0.6978 e
In the same way, the portions showed in the table 127 result for Routes 2 and 3. The volume
of each route qr1 in the first iteration step results from the product of portion P and demand F.
For Route 1, the calculation is as follows: 0.425 2000 = 849.4 PCU. From the route volumes,
the link volumes and thus the network impedances can then be calculated (illustration 108).
This results in the impedances R1 of the routes. These interim results can be verified in Visum
if the maximum number of internal iterations are set to M = 1 in the assignment parameters.
Route
Rmin0
exp(Rmin0)E
Portion P
qr1
R1
0.8596
1,125
0.279079049
0.425
849.4
2,470
0.6264
1,080
0.212737561
0.324
647.5
1,961
0.6978
1,440
0.165335421
0.252
503.2
2,848
0.657152032
1.000
2,000.0
Total
374
PTV AG
A Village
X City
Illustration 108: Volumes and link run times after the first internal iteration step m=1
For the route choice in the second iteration step, an estimated impedance Rmin1 is calculated.
Since = 0.5, this impedance results from the formation of the mean value of Rmin0 and R1. On
the basis of Rmin1, as in the first iteration step, the assignment is then made for the 3 routes.
For each route, the interim result is qr2. To smooth the volumes between two iteration steps,
the MSA method (Method of Successive Averages) is used.
q r ( m 1 ) ( m 1 ) + q rm'
q rm = ---------------------------------------------------------m
This route volume then leads to the link volumes and impedances of the second iteration step
(table 128). The iterations are repeated until the termination criteria are met.
Route
Rmin1
exp(R)E
Portion P
qr2
qr2
R2
0.8596
1797.6
0.142432
0.3944
788.8
819.1
2,405.2
0.6264
1,520.7
0.136919
0.3791
758.3
702.9
2,016.0
0.6978
2,144.0
0.081775
0.2264
452.9
478.0
2,785.6
Total
0.361126
2,000
PTV AG
375
5.17
TRIBUT
Taking road toll into consideration, a constant value of time is set in conventional procedures,
which in principle can be used to convert the costs (toll) into time and the conventional
monocriterial assignment procedures are directly applicable.
Compared to the conventional approach, TRIBUT uses a concurrent distributed time value.
Accordingly, TRIBUT calculates in the route search as well as in the route choice with two
separate criteria, namely with time and costs (bicriterion).
This method has been used for many years in France, for the evaluation of privately financed
freeways with toll management. Compared to the conventional approach, this approach is a
more realistic price elasticity when using toll roads.
Road tolls are transport system-specific and can either be defined for a link or a link sequence.
Using link sequences allows modeling of non-linear toll systems.
Road toll modeling is an add-on which basically can be used with any equilibrium assignment
procedure. Visum provides two extensions of this kind: TRIBUT-Equilibrium (as extension to
the "Equilibrium" method) and TRIBUT-Learning procedure (as extension to the
"Equilibrium_Lohse" method).
5.17.1
376
PTV AG
PTV AG
377
5.17.2
Here, VT is the value of time in [/h], for example. Though this equation applies to all tollregarding assignment procedures, the TRIBUT procedure differs from other procedures in two
properties:
Link toll
In the simplest case, the route's monetary costs result from summing up the toll amounts by
link along the route.
The following applies:
378
tL = t(VolL)
VolL
Volume of link L
CL
VT
PTV AG
This toll type applies to the HGV toll in Germany, for example: On parts of the network
(highways), heavy goods vehicles have to pay a toll amount which is precisely proportional to
the covered distance. Thus to each link of the highway link type the product from the link length
x constant km cost multiplication can be allocated as toll amount. For any other link and for any
other transport system, the toll amount = 0. The total of these amounts summed up along a
route represents the cost resulting from the distance traveled on highway links for the transport
system HGV.
For link toll, no toll system has to be defined. It is not necessary either to include the link
attribute Toll-PrTSys in the impedance definition, since TRIBUT regards this amount
automatically.
Note: The TRIBUT-Equilibrium assignment always regards the link-specific toll values. The
TRIBUT-Learning procedure only regards the link-specific toll values of links which do not
belong to any toll system.
Area toll
Especially toll systems for inner city areas often use a different type. For the area toll, a
geographically coherent section of the network is stated as toll area. A distance-independent
fixed amount is charged, if a section of a route runs through the toll zone.
c
R r = t r + ------r- =
VT
c
------t
+
L r L VT
0
Illustration 109: Example for area toll: The London Congestion Charging Zone
PTV AG
379
At first view, the monetary costs of a route do not depend on the individual links being
traversed, but on the route course as a whole in this case. Basically this is right, however,
TRIBUT - like any other assignment procedure - is based on shortest path searches via links
and requires the impedances by link therefore. That is why TRIBUT puts the area toll down to
the link toll case. For that, define the toll area first by creating a network object 'toll system' of
the area toll type and then allocating the toll area's number to all links which are located in the
area as value for the attribute Toll system number. The toll system additionally stores the
fixed toll amount for each transport system. For the clear definition of the figure described
below, all connector nodes of a zone need to be located either within the toll area or outside of
it.
On this basis, TRIBUT defines the toll amounts for links, turns, and connectors as follows:
cL = 0 for all links L
cC = 0 for all connectors C
c
c T = T --- for all turns T, with T = 1, if turn T leads from a link inside the toll area to a link
2
outside or vice versa, i.e. if the toll area border is crossed. Otherwise, T = 0.
c
c X = X --- for all transitions X from connectors to links, where X = 1, if the transition X leads
2
Zone 1
Link outside
of toll area
Link inside
of toll area
Turn with toll
Connector
with toll
Connector
without toll
Illustration 110: Reducing the area toll to the link toll case
(For clarity reasons, turns without toll are not displayed)
Summing up the toll amounts along a route results in an amount null for routes that do not
touch the toll area at all. Any other route (origin traffic, destination traffic, through traffic, internal
traffic of the toll area) is charged with the toll amount of c, since they traverse exactly two
network objects with toll amount = c/2 each.
In a Visum model, you can define multiple toll systems of the area toll type. Then, the
definitions for turn and connector cost are applied to each toll system with the associated fixed
toll amount. For turns between two toll areas the two toll amounts are charged.
Please note the two characteristics. For routes, that cross the border of the toll area multiple
times the toll amount is charged multiple times. This might not correspond to reality, however
it cannot be avoided for the required reduction to additive toll amounts per network object.
Furthermore, the internal traffic within the toll area can be excluded from toll calculations in
380
PTV AG
reality. For the TRIBUT route choice it is no problem that these flows are nevertheless charged
with toll amounts, since the toll comparably refers to all route alternatives and thus this additive
constant value does not modify the equilibrium solution. But when calculating a skim matrix of
the impedance for future use in a demand model for example, you need to perform an
additional matrix operation after skim matrix calculation to subtract the toll amount from the
internal traffic OD pairs data.
Note: Only the TRIBUT-Learning procedure takes the area toll into consideration.
For links that belong to a toll system the link attribute Toll-PrTSys is not regarded.
Matrix toll
Another type of toll models is often applied to arterial highways. In this case we have a
physically cohesive subnetwork with a limited number of connections (entries and exits) to the
remaining network (illustration 111).
Toll amounts are not defined as the sum of toll amounts by link, but arbitrarily as fee by pair
(entry, exit). Using such a fee matrix, the operator has more flexibility since the toll amounts for
longer routes can be defined irrespectively of the toll amounts for shorter sections of a longer
route. Usually, those tariffs are on a diminishing scale, thus the rate per kilometer declines with
increasing total distance.
As a matter of principle, such a matrix toll (which is named according to the fare matrix) cannot
be reduced to summing up the toll amounts by link. Let us have a look at the example in
illustration 112:
Link outside
of toll area
3
1
Link inside
of toll area
Node
with number
PTV AG
381
The links 1-2 and 2-3 form a highway corridor with matrix toll. For that, define the toll area first
by creating a network object 'toll system' of the matrix toll type and then allocating the toll area's
number to all links which are located in the area as value for the attribute Toll system number.
The toll system additionally stores a matrix for each transport system which contains the toll
amounts between all border nodes of the toll area. In this example, these are the nodes 1, 2,
and 3. The toll amounts are listed in table 131.
from / to node
Please note, that the toll amount for the overall link is less compared to the two individual links.
For each pair (entry, exit) in the toll area, TRIBUT generates a virtual link with the toll amount
from the matrix in the network and uses these virtual links for the shortest path search. In
contrast, the original links in the toll area are not regarded for the shortest path search. For
travel time computation, the volumes by virtual link are transferred back to the original links.
This allocation is always based on the route with the minimum time (regarding t0) required
between 'from node' and 'to node' of the virtual link. The illustration 113 shows the graph that
is generated for the shortest path search in the example.
Link outside
of toll area
Virtual link
with road toll
Node
with number
This modeling approach assumes a degressive toll matrix, i.e. if there are three nodes A, B,
and C, always cA-C cA-B + cB-C. Furthermore, the number of virtual links that are added to the
search graph exhibits quadratic growth proportionally to the toll area's number of border nodes.
Thus you should use a toll matrix only in those cases where the toll area is connected to the
surrounding network by a manageable number of nodes.
In a Visum model, you can define several toll systems of the matrix toll type. Nevertheless,
each link may belong to just one toll system.
Notes: Only the TRIBUT-Learning procedure takes the matrix toll into consideration.
For links that belong to a toll system the link attribute Toll-PrTSys is not regarded.
382
PTV AG
TRIBUT
monocriterial
In the full course of the assignment, only one
criterion is used, because the costs cR of a route
are converted into a constant time penalty.
bicriterial
During the assignment, both criteria (tR and cR)
must always be available for each path.
The complexity of a bicriterial route choice procedure can be made clear in a time-cost diagram
(illustration 114).
cost
c
cA
Route A
VT = - |cB-cA|/ |tB-tA|
Route B
cB
tA
tB
time t
5.17.3
Each point on the diagram, for example A = (tA,cA), corresponds with a route of the same
origin destination relation.
A certain time value VT corresponds with a family of parallel straight lines with a negative
slope.
If two routes lie on one VT straight, they are equally good (for a user with the same VT).
This VT is also characterized as a critical VT for two routes.
( )
VT = log N vt ,
PTV AG
383
( )
vt
Distribution parameter
This parameter corresponds with the standard deviation of the associated standard normal variable.
VT = log N vt ,
The position parameter vt corresponds with the Median of VT = log N vt , , which means
( )
0,060
Density function g1(vot)
Density function g2(vot)
0,050
g(vot)
0,040
0,030
0,020
0,010
0,000
0
10
20
30
40
50
60
70
80
90
value of time
384
PTV AG
1,200
Distribution function G1(vot)
Distribution function G2(vot)
1,000
G(vot)
0,800
0,600
0,400
0,200
0,000
0
10
20
30
40
50
60
70
80
90
value of time
5.17.4
D
VTcrit C/D
X
C
VTcrit B/C
VTcrit A/B
Y
A
t
PTV AG
385
The illustration 117 shows a route search with six routes. It can be verified graphically or
analytically, that there is no VT for which route X or Y would be preferred over A, B, C or D.
Generally spoken, the VT-straight lines A-B, B-C, C-D form a convex front. All routes which lie
to the right of this convex front no longer have to be observed, because they cannot be
optimal for any user (for no VT).
The relevant routes on the convex front are also designated as set of the efficient routes. Only
these efficient routes are saved for further search and later distribution.
There are two aspects:
5.17.5
For bicriterial procedures you can also discard most alternatives from a multitude of
possible routes, so that the route search can be calculated with the finite time spent and
memory used.
The bicriterial procedure has to memorize and save several paths at the same time,
whereas during and after a monocriterial search always one solution (best path) is found for
each source destination relation.
Route split
The result of a route search only comprises the efficient routes. Under these, the demand for
an OD relation is set. The critical VT are decisive for every neighboring routes on the efficient
front. In the example, there are three critical values of time - A/B, B/C and C/D.
As illustrated in illustration 118 the demand shares of the four efficient routes can be derived
from the probability distribution of the VT.
100%
P (D)
P (C)
P (B)
50%
P (A)
VTcrit C/D
0%
5.17.6
386
PTV AG
Initial solution
Route spl it
Route search
B
N
A
5.17.7
PTV AG
387
5.17.8
List outputs
Via the menu Lists > Toll, the list types Toll matrices and Toll systems are provided, which
offer the following attributes for selection:
388
PTV AG
5.18
5.18.1
PTV AG
389
Simulation of heavily congested urban and extra urban networks, where oversaturation
conditions and the back propagations of congestion among adjacent roads are present
over a large part of the network for several hours each day.
Simulation of networks with transient congestion effects, leading to route choice varying
during the assignment period.
Simulation of networks in presence of dynamic management and/or time varying access
policies, such as time varying tolls, signal timing plans, lane usage permission.
Simulation of incident effects and incident management
Simulation of evacuation plans, in particular when the maximum evacuation time is
required.
Below you can find a complete overview of the model underlying the Dynamic User Equilibrium
procedure implemented in Visum. However, in order to improve readability, any bibliographic
reference is omitted, along with many analytic proofs. For those, and for a deeper insight into
the model and/or the theories underlying it, the reader may refer to the bibliographic section,
which includes all the scientific papers on which this model is based (see "Literature" on
page 769).
5.18.2
390
PTV AG
Apart from the temporal dimension, the main difference between the static and the dynamic
user equilibrium relates to the consistency constraints between arc and path model variables.
While in the static case these constraints involve only the spatial dimension of the system, in
the dynamic case they concern the temporal dimension also. More specifically, for given path
flows, the determination of the arc flows, which in the static case requires only the arc-path
incidence matrix, in the dynamic case involves also the travel times on the network; that is, the
network flow propagation model depends also on the path performances (diagonal arrow in
illustration 122).
The present formulation of the WDDTA has three essential innovations compared to existing
WDDTA methods:
1. Instead of a simulation approach, it adopts a temporal profile approach, where the value of
a given variable of the problem is determined as a function of time for the entire period of
analysis, based on the temporal profiles of the other variables of the problem, which are
assumed to be fixed to their current value; this approach, conceptually depicted on the right
hand side of illustration 123, has an iterative nature, since each variable has to be
recalculated until a convergence is achieved.
period of analysis
period of analysis
Illustration 123: Time slice approach (left side) and time profile approach (right side) to the Continuous
Dynamic Network Loading problem
2. Spill-back can be modeled explicitly simply by switching between two alternative network
performance models. Without spillback, arc performance (the relationship between arc
inflow and outflow time series) depends only on the properties of that arc; with spillback,
capacities upstream of bottlenecks are reduced so that arc storage capacities are not
exceeded (illustration 124).
PTV AG
391
network loading
map
demand
flows
arc conditional
probabilities
arc performance
function
arc costs
network performance
model
Illustration 124: Scheme of the fixed point formulation for the WDDTA with spillback congestion
3. The path choice model can adopt either a deterministic view where only objectively leastcost paths are loaded, or a Probit view where impedances are perturbed stochastically to
reflect subjective user perceptions.
This approach presents several advantages:
Consistency between path and link flows (network loading) is achieved in the same
iteration as the equilibration between demand and supply. Nested loops are avoided.
An implicit path approach generates rational path probabilities without the need to
enumerate all paths.
A major advantage of the temporal profile approach, is that the assignment period may be
subdivided into long time intervals (typically 5-15 minutes), instead of a few seconds for the
simulation approaches, saving computation time and memory. This allows overcoming the
difficulty of solving WDDTA instances on large networks and long periods of analysis.
The complexity of the algorithm is roughly equal to that of a static assignment multiplied by
the number of (long) time intervals introduced.
For queue spillover modeling, the interaction among the flows on adjacent arcs is propagated
in terms of time-varying arc exit capacities. The approach is then to reproduce the spillback
phenomenon as a hypercritical flow state, either propagating backwards - from the final section
of an arc - and reaching its initial section, or originating on the latter that reduces the capacities
of the arcs belonging to its backward star and eventually influences their flow states.
The description of the dynamic user equilibrium has the following structure. First, the main
variables underlying the continuous model are introduced, along with some significant results
of the traffic flow theory underlying the presented model (see "Mathematical framework of the
Dynamic User Equilibrium" on page 393). Subsequently, the network performance model and
its submodels are described (see "Network performance model" on page 397). Then, the
display of the network loading map (see "Assignment of the network demand (network
loading)" on page 406) is followed by a description of the overall Dynamic User Equilibrium
model, both for the deterministic and Probit case (see "The overall model" on page 408). A
numeric example including the analysis rounds off the procedure description (see "Example of
the Dynamic user equilibrium" on page 410).
392
PTV AG
5.18.3
For an arc a representing a link in the Visum network, TL(a) would correspond to its FromNode
and HD(a) to its ToNode. The forward and backward star of node xN are denoted,
respectively, FS(x) ={aA: x = TL(a)} and BS(y) = {aA: y = HD(a)}. The zones constitute a
subset Z N of nodes.
When traveling from a node oN to a node dZ users consider the set Kod of all the paths
connecting o and d on G. We are interested in the n:1 many-to-one shortest path problem from
each node N to a given destination Z. Graph G is assumed to be strongly connected, so
that Kxd with xN dZ is non-empty.
Path topology is described through the following set notation:
A(k) = concatenated sequence of arcs constituting the path kKod from oN to dZ.
Vehicle demand, which are moving from origin oN to destination dZ and are departing at
time
fa()
Fa()
ua()
fa ( ) d
(27)
For the calculation of network performance, travel times are introduced through inflow-outflow
functions, and the following notation is adopted.
PTV AG
ca()
ta()
fa-1()
Ck()
Cost of path kKod from oN to dZ for vehicles departing from node o at time
Tk()
Outflow time of path kKod from oN to dZ for vehicles departing from o at time
393
Due to the presence of time-varying costs, it may be convenient to wait at nodes in order to
enter a given arc later. In the following, it is assumed that vehicles are not allowed to wait at
nodes, but paths with cycles may result. However, the shortest paths include at most a finite
number of cycles.
Since waiting at nodes is not allowed, the path exit time Tk() is the sum of the travel times of
its arcs A(k), each of them referred to the instant when these vehicles enter the arc when
traveling along the path. Moreover, assuming that path costs are additive with respect to arc
costs, its cost Ck() is the sum of the costs of its arcs A(k). The outflow time or the cost,
respectively, of path k can then be retrieved through the following recursive equations:
Tk ( ) = Th (t a ( ))
(28)
Ck ( ) = ca ( ) + Ch (ta ( ))
(29)
where a = (o, x)A is the first arc of k and hKxd is the rest of path k (illustration 125).
ta()
Tk() = Th(ta())
ca()
time
Ch(ta())
a = (o, x)A(k)
hKxd
dZ
oN
(x, y)A(k)
y
time
Illustration 125: Recursive expressions of path exit time, entrance time and cost
The strict First In First Out (FIFO) rule holds if the following property is satisfied for each arc
aA:
t a ( ' ) > t a ( ) , for all t > t
(30)
The monotonicity expressed by (30) ensures that the temporal profiles of the arc exit times are
invertible. Moreover, the FIFO rule applies also to the entrance times.
t xy 1 ( ' ) > t xy 1 ( )
394
(31)
PTV AG
Any arc aA consists of a homogeneous channel with two bottlenecks located at the beginning
and at the end. The flow states along the arc are determined on the basis of the Simplified
Theory of Kinematic Waves (STKW), assuming the concave parabolic-trapezoidal
fundamental diagram depicted in illustration 126, expressing the vehicle flow qa(x,) at a given
section x of the arc and instant t, as a function of the vehicle density ka(x,) at the same section
and instant.
The arc is then characterized by:
La
Length of arc a
Qa
Capacity of the initial bottleneck and of the homogeneous channel associated with arc a, called
in-capacity;
Sa
Capacity of the final bottleneck associated to arc a, simulating the average effect of capacity
reductions at road intersections (i.e. due to the presence of traffic lights), called out-capacity Sa
Qa;
Va
KJa
Wa
propagation speed of hypercritical flow states on arc a, called hypercritical kinematic wave
speed.
Within this framework, for links the in-capacity corresponds to the physical mid-block capacity,
whereas out-capacity reflects the bottleneck capacity imposed by the signal control or priority
rules at the downstream junction. Exit connectors (x, d)A: xN \ Z, dZ are arcs with infinite incapacity, entry connectors (o, y)A: oZ, yN \ Z are arcs with infinite out-capacity. Turns,
however, are represented by arcs having zero length and in-capacity equal to their outcapacity.
Illustration 126: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among
vehicular flow, speed and density along a given arc.
In illustration 126, k2a k1a is assumed, implying the following relation among the above
parameters:
PTV AG
395
2- -----1-
KJ a Q a ----V W
a
Based on the fundamental diagram, it is possible to identify two families of flow states.
Then, koa(q) and voa(q) express the density and the speed as functions of the flow in presence
of hypercritical flow conditions, while kua(q) and vua(q) express the density and the speed as
functions of the flow in presence of hypocritical flow conditions.
When modeling arcs with low speed limits, i.e. representing urban roads, it may be assumed
that the vehicle speed under hypocritical flow conditions is constant and equal to the speed
limit, until capacity is reached. In this case, the simpler trapezoidal fundamental diagram
depicted in illustration 127 may be adopted, where, in order to guarantee k2a k1a, the
following relation must apply:
1- -----1-
KJ a Q a ----V a W a
hypocritical flow conditions
flow
Qa
q
kua(q)
Qa / Va
Wa
voa(q)
Va
k1a
k2a
koa(q)
KJa
density
-Qa / Wa
Illustration 127: The trapezoidal fundamental diagram suggested for urban links
In order to implement the proposed models, the period of analysis [0, Q] is divided into n time
intervals identified by the sequence of instants = {0, , i, , n}, with 0 = 0, i < j for all 0
i < j n, and n = Q. For computational convenience, we introduce also an additional instant
n+1 = .
In the following we approximate the temporal profile g() of any variable through either a
piecewise linear or a piecewise constant function, defined by the values gi = g(i) taken at each
instant i. This way, any temporal profile g() can be then represented numerically through
the vector g = (g0, , gi, , gn).
396
PTV AG
5.18.4
arc inflows
arc outflows
Illustration 128: Scheme of the fixed point formulation for the NPM
Exit flow and travel time models for time-varying exit capacity
Under the condition that the FIFO rule applies and vehicles are therefore not able to overtake,
an arc performance model with time-varying exit capacity is introduced in this section. The exit
flow is achieved by propagating the inflow temporal profile along the arc and thus calculating
the corresponding time-series of the travel time.
PTV AG
397
Assuming that the capacity at the end of a given edge aA is not reduced due to spillback
effects, for a vehicle entering the edge at time , the hypocritical exit time ra() can be
expressed, dependent of the previous part of the inflow time series, which corresponds to the
inflow fa() at any time .
ra ( ) = ra ( f a ( ) : )
(32)
for the trapezoidal fundamental diagram (see "Hypocritical exit time model for a trapezoidal
fundamental diagram" on page 399) (illustration 127)
for the parabolic fundamental diagram (see "Hypocritical exit time model for a parabolic
fundamental diagram" on page 399) (illustration 126)
If, however, at the end of the edge there is a bottleneck with a time-varying capacity a() Sa
for each time , the time series of the cumulative outflow is determined, whose value Ea() at
time t is defined as follows.
Ea ( ) = min Fa ra 1 ( ) + a ( ) a ( ) :
(33)
a ( ) d
(34)
This means that a() - a() vehicles can exit the edge between times and .
The above expression (33) is based on the following specification of the FIFO rule, stating that
the cumulative exit time at the exit instant ta() of a vehicle that enters the arc at t is equal to
the cumulative inflow at time t. This means the following:
Ea (ta ( )) = Fa ( )
(35)
Then, equation (33) can be explained as follows: If there is no queue at a given time t, the travel
time is equal to the hypocritical travel time, so that, based on the FIFO rule (35), the cumulative
exit flow is equal to the cumulative inflow at time ra-1() when a vehicle that enters the arc at
time ra-1() is leaving it at t. If a queue develops at time s < t, the exit flow from this point of time
to the time where the queue breaks up, then corresponds to the exit capacity. Based on the
FIFO rule, this results in a cumulative exit flow Ea() from the cumulative inflow at time ra-1()
plus the integral value of the exit capacity between and t, which is a() - a().
By definition, the exit flow ea() from arc a at time t is:
ea ( ) = dEa (r ) / d
(36)
By definition, ea() a() applies at any time and hypercritical exit flows occur if ea() = a().
Knowing the cumulative inflow and exit flow temporal profiles, the FIFO rule (35) yields an
implicit expression for the arc exit time temporal profile.
t a ( ) = max r a ( ), min : E a ( ) = F a ( )
398
}}
(37)
PTV AG
The illustration 129 depicts a graphical interpretation of equation (37), where the time profile of
the cumulative exit flow Ea() complies with the lower envelope of the following curves:
a) the cumulative inflow Fa(), shifted forward in time by the hypocritical travel time ra() -
thus yielding the temporal profile Fa[ra-1()]. This represents the rate at which vehicles
entering the arc arrive at its end.
b) for every time s, the cumulative time series of the exit capacity is shifted vertically so that
it goes through the point (,Fa[ra-1()]). This represents the rate of vehicles that can exit the
arc following time s. No queue is present when curve a) prevails. Queuing starts, when the
cumulative exit flow curve falls below the time-shifted cumulative entry flow curve, this
means that more vehicles arrive at the final section of the arc than can exit. In the diagram,
therefore, the queue arises at time s''. In illustration 129, the calculation of the exit time from
the cumulative time series of inflows and outflows is illustrated by thick arrows.
(38)
In this case, using (33) equation (38) can be made explicit as follows:
{ (
Ea ( ) = min Fa La / Va + a ( ) a ( ) :
(39)
PTV AG
399
In cases where it might require large computational effort, it can be replaced by a simpler
model that averages traffic conditions and thus limits the number of traffic situations
encountered by vehicles on arc. Readers who would like to get a general feel for the model as
a whole may just note the general idea and skip to the conclusion of this section (see "Input
and output attributes of the dynamic user equilibrium (DUE)" on page 412).
Illustration 130: Flow pattern given by the Simplified Theory of Kinematic Waves
Wa ij =
fa j fai
= vua ( f a i ) + vua ( f a j ) Va
j
i
kua ( f a ) kua ( f a )
(40)
In theory, given a piece-wise constant inflow time series, it is possible to determine the
trajectory of a vehicle entering the arc at instant t, and thus its hypocritical exit time ra(). The
illustration 130 shows that it may be extremely cumbersome to determine these trajectories, in
fact.
In order to overcome these difficulties, as depicted in illustration 131, we assume that at each
instant ri, 0 i n-1, a fictitious shockwave is generated on the initial arc section separating the
actual flow state (fai+1) from a region with the average speed i = L / (rai - i) of the vehicle
that reaches the arc at time i.
400
PTV AG
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.
Wa i = i + vu ( f a i +1 ) Va
(41)
average trajectory of the vehicle entering the running link at time i, , 0 i n-1
fictitious shockwaves
space
outflow profile
La
1
3
vua
vua
2
Wa
0
Wa
Wa
fa3
f
1
Wa
3 4
fa
1
2
a
fa1
Wa
4
fa5
4
inflow profile
time
Illustration 131: Flow pattern given by the Averaged Kinematic Wave model
Note that the trajectory of a vehicle entering the current link at time (i-1,i] is directly
influenced only by the mean trajectory of the vehicle entered at time i-1, which synthesizes the
previous history of flow states on the link.
The approximation introduced has little effect on the model efficacy. Moreover, it satisfies the
FIFO rule, which is still ensured between the arc initial and final sections, while local violations
that may occur within intermediate sections are of no interest.
Based on the above, the hypocritical travel time ai = a()i, 0 i n-1 can be specified as
follows:
a) If a vehicle entered at time i does not meet the fictitious shockwave Wai-1 before the end
of the arc, its hypocritical exit time is simply:
ra i = i + La vua ( f a i ) .
Here, fai is the arc inflow during time interval (i-1,i].
PTV AG
401
b) Otherwise, its hypocritical exit time is determined on the basis of the two speeds it
assumes before and after crossing the fictitious shockwave.
ra i = i + i + ( La i vu ( f a i ) ) i 1 .
where i is the travel time of the vehicle before it reaches the fictitious shockwave
(illustration 132).
i = (i i 1 ) Wa i 1 (vu ( f a i ) Wa i 1 ) .
rai
space
rai-1
i-1
i-1
W i-1
i
i-1
L
vu(f ai)
time
(42)
402
PTV AG
In reality, hypercritical flow states may actually occur at different densities. Their kinematic
wave speeds are not only lower than v0, implying that the vehicles will reach the first arc
section with a delay when starting from the final section, but also somewhat different from each
other, which generates a distortion in their forward propagation in time. Notice that the
fundamental diagrams adopted here are capable of representing the dominant delay effects
but not the distortion effects, since all backward kinematic waves have the same slope.
The spillback effect on the entry capacity is investigated by exploiting the analytical solution of
the STKW. The flow state occurring on an arc section is the result of the interaction among
hypocritical flow states coming from upstream and hypercritical flow states coming from
downstream. Specifically, on the initial section, the one flow state coming from upstream is the
inflow, while the flow states coming from downstream are due to the exit capacity and can be
determined by back-propagating the hypercritical portion of the cumulative exit flow temporal
profile, thus yielding what we refer to as the maximum cumulative inflow temporal profile.
According to the Newell-Luke minimum principle, the flow state consistent with the spillback
phenomenon occurring at the initial section is the one implying the lowest cumulative flow.
Therefore, when the cumulative inflow equals or overcomes the maximum cumulative inflow,
so that spillback actually occurs, the derivative of the latter temporal profile may be interpreted
as an upper bound to the inflow. This enables the determination of the proper value of the entry
capacity that maintains the queue length equal to the arc length.
The instant a() when the backward kinematic wave generated at time on the final section of
arc aA by the hypercritical exit flow ea() = a() would reach the initial section is given as
follows.
a ( ) = + La / wa (ea ( ))
(43)
By definition the points in time and space constituting the straight line trajectory produced by a
kinematic wave are characterized by a same flow state. Moreover, illustration 133 shows that
the number of vehicles encountered by the hypercritical wave relative to the exit flow q for any
infinitesimal space ds traveled in the opposite direction is equal to the time interval ds
[1 / va (q ) + 1 / wa (q )] multiplied by that flow. Therefore, integrating along the arc from the final
to the initial section, we obtain the maximum cumulative flow Ha() that would be observed at
time a() in the initial section as:
PTV AG
(44)
403
space
kinematic wave
vehicles
ds
wa(q)
va(q)
time
ds / wa(q)
ds / va(q)
Illustration 133: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles
In the fundamental diagrams adopted here, the hypercritical branch is linear and therefore
a() is invertible. Since wa(q) = wa, the time at a() = is = - La /wa - based on (43).
Furthermore, Ha() = Ea() + La KJa results -based on (44) q/va(q) = KJa - q/wa. Therefore, the
maximum cumulative inflow Ga() that could have entered the arc at time t due to the inflow
volume is given by the following equation:
La
E ------ + L a KJ a
wa
Ga ( ) = a
L
L
if e a -----a- = a -----a-
w a
w a
(45)
else
If the cumulative inflow Fa() at time t equals or exceeds the maximum cumulative inflow Ga(),
so that spillback occurs at that instant, then the entry capacity a() is given by the derivative
dGa()/d of the latter; otherwise, it is equal to the in-capacity Qa.
Differentiating Ga() implies the following:
dGa ( ) / d = ea ( La / wa )
- if G a ( ) F a ( )
a ----w a
a ( ) =
else
Qa
(46)
The illustration 134 shows how, based on equation (45) the time series of the maximum
cumulative inflow can be obtained graphically through a rigid translation (thick arrows) of the
cumulative exit flow time series for La / wa in time and for La KJa in value. Moreover, it points
out that, if Ga() is greater than Fa(), the queue is shorter than La and a() = Qa.
Otherwise spillback occurs and a() = a( - La /wa).
404
PTV AG
La / Va
vehicles
maximum cumulative inflow Ga()
inflow Fa(), fa()
exit flow Ea(), ea()
entry capacity a()
La
KJa
La / Va
La / wa
'
flow
''
time
Q
a
time
Illustration 134: Graphical determination of the time series of the inflow capacity in the case of triangular
fundamental diagram, piecewise constant inflow, and constant exit capacity
PTV AG
405
When considering diverging links xN, that is an intersection with a single backward edge,
the exit flow of this edge a = BS(x) is determined by the most restrictive entry capacity among
the forward edges. If no arc is spilling back, the exit capacity is set equal to the out-capacity. If
only one arc bFS(x) is spilling back, that is fb() b(), then the exit capacity a() scaled by
the share of vehicles turning on arc b is set equal to the entry capacity of b in order to ensure
capacity conservation at the node while satisfying the FIFO rule a() fb() / a() = b()
applied to the vehicles exiting from arc a. If more than one arc bFS(x) is spilling back, the exit
capacity is the most penalizing among the above values. On this basis, the following equation
is derived:
a ( ) = min{S a ; b ( ) u a ( ) / f b ( ) : b FS (x ), f b ( ) b ( )}
(47)
Note that, in contrast with the models presented in the previous two sections, this model is
spatially non-separable, because the exit capacities of all the arcs belonging to the backward
star of a same node are determined jointly, and temporally separable, because all relations
refer to a same instant.
It is assumed that vehicles do not occupy the intersection if they cannot cross it due to the
presence of a queue on their successive arc, but wait until the necessary space becomes
available. Indeed, this model is not capable of addressing the deterioration of performances
due to a misusage of the intersection capacity.
ca ( ) = ta( ) + ma ( )
(48)
Here, ma() describes the monetary costs and the value of time.
5.18.5
(49)
It can be proved that the following dynamic version of the Bellman relation for each node oN
(illustration 135) is equivalent to problem (49).
wod() = min { Cox ( ) + wx d (tox ( )) } : x FS (o )
406
(50)
PTV AG
dZ
oN
(o, x)FS(o)
xN
cox() + wxd(tox())
tox()
Illustration 135: Dynamic version of the Bellman relation
The set of Bellman relations (50) can be solved using a dynamic programming approach
described below.
If path k Kod is used, i.e., its choice probability Pk() is positive, then its cost Ck() is equal
to the minimum cost wod(), to travel from o to d departing at time t.
Vice versa, if path k is unused, i.e., its choice probability is zero, then its cost may not be
smaller than the minimum cost.
Pk ( ) [ Ck ( ) w0 ( ) ] = 0
(51)
PTV AG
407
P k ( ) = p ox ( ) P h ( t ox ( ) )
(52)
where (o, x) is the first arc of k and h Kxd is the rest of path k.
The dynamic Wardrop condition is satisfied when the conditional probabilities of the edges are
calculated as follows.
d
p ox ( ) [ C ox ( ) + w x ( t ox ( ) ) w o ( ) ] = 0
(53)
( o, x ) FS ( o) pox ( )
(54)
= 1
p ox ( ) 0
(55)
Equation (49) states that road users exiting at time t from node oN and directed to the
destination dZ may choose among the forward star FS(o) only an arc (o, x) for which the cost
Cox() plus the minimum cost wxd(tox()) to reach the destination once entered x at time is equal
to the minimum cost wod(). In x, the passage time is tox() here.
The flow foxd() of vehicles directed to destination dZ that enter the arc (o, x)A at time t is
given by the arc conditional probability poxd() multiplied by the flow exiting from node o at time
t. The latter is given, in turn, by the sum of the outflow uyod() from each arc (y, o)BS(o)
entering o, and of the demand flow Dod() from o to d. This results in the following equation:
f ox ( ) = p ox ( ) D od ( ) +
d
( y, o ) BS ( o )
u yo ( )
(56)
Applying the FIFO and flow conservation rules, the outflow from y at time can be expressed
in terms of the inflow at a at time tyo-1().
u yo d ( ) = f yo d (t ) yo 1 ( ) / dt yo ( ) / d
(57)
where the weight dtyo()/d stems from the fact that travel times vary over time, so that users
exit from y at a certain rate and, in general, enter in o at a different rate, which is higher than
the previous one, if the arc travel time is decreasing, and lower, otherwise.
The total inflow and outflow of arc (o, x)A at time t are then:
f ox ( ) =
5.18.6
d Z fox ( ) ;
d
u ox ( ) =
d Z uox ( )
d
(58)
408
PTV AG
p(w, c, t)
(p, t ; D)
w(c, t)
f, u
f, u
network
performance model
E( f, )
*( f, u)
c(t)
E
E( f, )
( f, E, ; Q)
E
S
t( f, u, E)
(f, u, ; S)
Illustration 136: Variables and models of the fixed point formulations for the network performance model
(left hand side) and for the dynamic assignment with spillback (right hand side)
In analogy with the static case, the Network Loading Map (NLM) is a functional relation
yielding, for given demand flows D, an arc flow pattern f consistent with the arc performances
t, and c, through the deterministic route choice model p(w(c, t), t, c), and the network flow
propagation model (p, t; D). The assignment uses an implicit path enumeration and is based
on the minimum costs w from each node to destination, as well as on the resulting conditional
probabilities p of the edges. In turn, the arc performance model yields the arc exit time pattern
t, and the arc cost pattern c, consistent with the arc inflows f and arc outflows u. The
deterministic equilibrium results from the feedback of network loading map and arc
performance model.
PTV AG
409
(59)
where each a() is extracted from a standard normal variable N[0,1] and h = 1, , H.
2. For each perceived arc cost pattern of the sample, determine with the deterministic NLM a
consistent arc inflow pattern.
3. Calculate the mean of the resulting deterministic arc inflow patterns, thus obtaining an
undistorted estimation of the Probit arc inflow pattern.
Note that, based on equation (59), the entire time series ah() is disturbed by just one random
number. This means, that the error of estimation of road users does not depend on the time of
day. This is consistent with the behavior of users, who perceive the arc cost temporal profile as
a whole. On the contrary, the travel times that underlie the network flow propagation, are
considered as constant throughout the simulation.
5.18.7
410
Link
La[km]
Qa [veh/h]
Va [km/h]
Wa [km/h]
1 / Ka[m]
0.4
2,000
50
15
7.0
0.6
2,000
50
15
7.0
0.6
2,000
50
15
7.0
0.4
2,000
50
15
7.0
PTV AG
Link
La[km]
Qa [veh/h]
Va [km/h]
Wa [km/h]
1 / Ka[m]
0.4
2,000
50
15
7.0
0.1
4,000
50
15
3.5
The assignment period is constituted by 100 intervals of 1 minute. For the first 33 minutes of
simulation, constant demand flow from node 1 to node 5 is assumed, which equals D15 = 2,300
veh/h.
2
C
A
E
D
3
Illustration 137: Example network
The outputs of two assignment runs, one without and the other with spillback congestion, are
presented in illustration 138. Without spillback, the congestion is evenly located only on turns
CF and DF (which can be gathered observing turn travel times), so that on all the paths
between node 1 and node 5 the queue is about equal, and path A-E-D-F has fewer users since
it is clearly not convenient. With spillback, however, the queue propagates from turn CF to arc
C and up to arc A, and from turn DF to arc D and up to arcs B and E. Moreover, the spillback
effect is greater on arc B than on arc E because of the different capacities of turn ED and turn
BD. Then, after an initial growth, the travel time on arc D remains constant, since congestion is
propagated upward, while the travel time on arc B grows faster than the travel time on arc E,
so that path A-E-D now becomes competitive, as it implies a longer route but a lower travel
time. That is why the flow on arc E increases from around 150 veh/h to 670 veh/h
approximately.
DUE without spillback - inflow [veh/h]
2000
arc A
arc B
1500
arc C
arc D
1000
arc E
500
0
0
PTV AG
500
1000
1500
2000
2500
3000
3500
411
2000
arc A
arc B
1500
arc C
arc D
1000
arc E
500
0
0
500
1000
1500
2000
2500
3000
300
3500
turn AC
250
turn BD
200
turn CF
150
turn DE
100
turn ED
50
0
0
500
1000
1500
2000
2500
3000
300
3500
arc A
250
arc B
200
arc C
150
arc D
100
arc E
50
0
0
500
1000
1500
2000
2500
3000
3500
5.18.8
Input Supply
The available network is defined as usual by nodes, links, turns, zones, and connectors
(optionally also main nodes and main turns). The attributes listed in table 133 are relevant for
DUE.
412
PTV AG
Network object
Attribute
Optionally timevarying
Link
TSysSet
Length
v0 PrT
Capacity PrT
Toll_PrTSys
DueVWave
DueFunDiag
SpacePerPCU
LinkSpacePerPCU
Comment
in [veh/h]
in [veh/h]
Link type
vMax_PrTSys
Turn
TSysSet
t0 PrT
Main turn
Zones
Connectors
Capacity PrT
TSysSet
in [veh/h]
t0 PrT
Capacity PrT
in [veh/h]
SharePrTOrig/Dest*)
Do connectors have
shares{Yes/No}
t0_TSys
Weight*)
Connector share, if
enabled for zone
Some of the attribute can be temporarily restricted. These attributes will then have a default
value, but may assume a different value during a given interval within the assignment period.
The transport system set and the connector shares have the same meaning as in all other
assignment methods.
Impedances are handled in a special way in DUE (see "Network performance model" on
page 397). In particular, link travel time is the sum of t0 with free flow and a wait time at the
bottleneck which is assumed to be located at the end of the link. The free-running travel time
t0 depends on a flow-density fundamental diagram. The fundamental diagram can have one of
two different shapes which differ in the sub-critical branch, this means, where density is less
than the critical density (at which maximum flow is reached). The shape is defined by the link
attribute DueFunDiag.
PTV AG
413
In the case of urban links, a trapezium shaped fundamental diagram is recommended. In this
type of diagram, the hypocritical branch is linear, which means that vehicles travel at free-flow
speed v0 (on the free-running part) until capacity is reached. The illustration 139 illustrates how
the shape of the diagram is determined by the link attributes.
sub-critical
hyper-critical
2500
CapacityPrT
-D
UE
vW
av
e
1500
v0
Flow [veh/h]
2000
1000
500
0
0
20
40
60
80
100
120
140
160
Density [veh/km]
Illustration 139: Shape of the fundamental diagram based on the link attributes
Notice that the jam density is the maximum number of vehicles per 1 km of link length. For a
single-lane link a typical value for SpacePerPCU would be around 7 m, resulting in a jam
density of ~140 vehicles / km.
In order for the fundamental diagram to be well-defined, the sub-critical and hyper-critical
branches must not overlap. Therefore the link attributes must satisfy the condition:
Capacity PrT (1 / v0 + 1 / DueVWave) 1 000 / LinkSpacePerPCU
For freeway links, the assumption of constant sub-critical speed is not always justified, and an
approach similar to volume-delay functions appears more suitable.
In this type of diagram, the sub-critical branch is parabolic (illustration 140), speed decreases
from v0 at free flow to 0.5 v0 at capacity and the flow-density curve reaches capacity with zero
derivative. The validity condition for the attributes then becomes
Capacity PrT (2 / v0 + 1 / DueVWave) 1,000 / LinkSpacePerPCU.
414
PTV AG
sub-critical
hyper-critical
2500
zero derivative
CapacityPrT
-D
UE
vW
av
e
1500
1000
v0
/2
v0
Flow [veh/h]
2000
500
0
0
20
40
60
80
100
120
140
160
Density [veh/km]
The wait time at the end of the link is a function of the bottleneck capacity. This is defined for
each turn by turn attribute Capacity PrT. To work correctly with DUE, turn capacities should
be determined in the following way:
First, determine the saturation capacity of each lane of the upstream arc, as the lane
capacity multiplied by the green time fraction (g/c) corresponding to that lane in the case of
a signalized intersection, or by some suitable multiplier in case of non-prioritized approach
at a non-signalized intersection.
Then, determine each turn capacity as the sum of the capacities of lanes allowed for the
corresponding maneuver.
Note: In case of lanes allowed for more than one maneuver, the corresponding lane capacity
is not to be split among the corresponding turns, but is to be entirely assigned to each turn
corresponding to the allowed maneuvers. In this case in fact, DUE will, based on the turn
flows resulting from WDDTA, internally identify the actual capacity to be assigned to each
turn.
PTV AG
415
Example
80 m
g = 30 s
g = 45 s
g = 45 s
The signalized intersection in illustration 141, with lane capacities = 1,800 veh/h, a signal cycle
= 90 s, and green fractions should be implemented in Visum as shown at the bottom of
illustration 142. The turns approaching from the West have the following capacities:
Whereas the capacity of the right lane, which can be used to go either straight or right, is added
both to the straight turn capacity and to the right turn capacity.
Q1
Q2
Q3
links
turns
For the compensation of the turn capacity overestimation due to shared lanes the out capacity
PrT of the incoming link from the West can be set, by adding up the saturation flow rate and the
green ratio by lane for example:
S = 1,800 30/90 + 1,800 45/90 + 1,800 45/90 = 2,400
Note: For the PrT lane capacities and/or the link out capacity you can define time-varying
values. In this way, you can model the effects of various green time splits depending on the
time of day.
Input Demand
DUE accepts a description of time-varying demand. Like elsewhere in Visum, this description
can take two possible forms:
416
PTV AG
Total demand matrix with a demand time profile which assigns percentage shares of the
total matrix to time intervals.
A demand time profile in which each time interval refers to a different demand matrix.
If the assignment time interval including the extension exceeds one day you need to use the
calendar add-on.
DUE is a multi-class assignment method, this means, multiple demand segments, each with its
own demand description, can be assigned in a single run.
Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure
parameters) to have an effect
Optionally time-varying
PTV AG
417
The definition of queue lengths as a measure of oversaturation is not easily defined, as in the
DUE model queues may move and only gradually approach the situation where traffic is at a
standstill at queue density. Because queues move (at a speed depending on the hyper-critical
branch of the fundamental diagram), and separation between vehicles (density) is not
constant, it would furthermore be misleading to speak of queue length in meters. Therefore we
adopt a definition which is similar to congestion hits in more microscopic simulations. The
value of the queue length (for a given link and time interval) is the number of vehicles
experiencing hyper-critical delay, i.e. spend more time on the link than the free-running link
travel time resulting from v0 plus the sub-critical wait time at the bottleneck (e.g. waiting for the
next green time in the cycle).
The table 135 gives an overview of all DUE output attributes.
5.18.9
418
Link capacity = Saturation flow rate. The lane-specific value has to be multiplied by the
number of the link's lanes.
Bottle-necks at nodes due to control strategies, for example, have to be modeled as turn
capacities. On the one hand, the latter allow for congestion modeling by overloaded turns,
on the other hand, the inflow in overloaded links upstream can be controlled.
PTV AG
5.19
The out capacity of links can be used to correct the impact of shared lanes on turn
capacities. Shared lanes are neglected when turn capacities are defined which causes an
overestimation in the sum of the capacities of the link's exit turns. If the turn capacities are
not modeled in detail, the out capacities should be defined in any case.
Zones have to be connected in the subordinate network. To avoid unwanted network inflow
effects it is even recommended to add links and thus make it possible to connect zones to
one-leg nodes.
For the assignment, time intervals of only 5 - 15 min are recommended. This also applies if
you are interested in hourly values for the analysis. In this case, different intervals can be
defined the assignment time interval and the analysis time intervals.
The assignment time interval and the time extension have to be defined appropriately, all
vehicles need to be able to reach their destinations within this time range. When the
assignment comes to an end, at least in the last interval, the volumes of all network objects
should be zero.
It is recommended to activate the option Blocking back model not until plausible results
without spill-back could be reached. Even if this option has not been checked, queue length
data is calculated and displayed, but these lengths represent vertical congestions, which
do not spill back. This data can help to identify possible network modeling deficiencies. Also
spill-backs on connectors over several time intervals identify shortcomings in network or
demand modeling which have to be corrected by the user.
We recommend to adjust the standard parameter settings for the termination conditions,
since the early termination of the assignment could return incorrect results.
With extensive models, the storage of paths is not recommended. This will reduce the
memory requirements and furthermore the run time will be improved.
PTV AG
The dynamic stochastic assignment takes time-varying attributes of traversed links, turns,
main turns and connectors into account (t0, tCur, VolCapRatio per time interval, that
result from their temporary attributes, for example, Capacity and v0 or t0).
The dynamic stochastic assignment provides the calculated results, for example volume or
impedance of the connections (routes in time interval) and of their traversed network
objects, which means links, turns, main turns and connectors, for each user-defined time
interval. Since the impedance equals the congested travel time in most applications, time
profiles for the assignment period can be generated this way. For the routes, tolls and
AddValues are additionally issued for each time interval.
419
In contrast, all trips are completed in the case of static assignment procedures with no
indication of the time required, capacities have to be specified according to the length of the
time interval demand data is available for, and the volumes of all trips and the resultant
impedances are superimposed upon each other at the individual network objects. Road-users
subsequently only have to choose from a number of different routes for each journey. The
departure time is irrelevant.
In the case of the dynamic assignment on the other hand, an assignment period T (e.g. 24
hours) is specified and divided up into time slices Ti of equal length (e.g. 15 minutes). Only the
search for (alternative) routes for each journey is made with no reference to a specific time. As
in the case of the static stochastic assignment, several shortest path searches are completed
with network impedances that vary at random. All other operations explicitly include a time
dimension. As for the stochastic assignment, further random searches may be carried out (see
User Manual, Chpt. 5.6.10.2, page 1055).
From the entire demand and its temporal distribution curve, the portion with a desired
departure time is determined for each time slice within this time interval. On the supply side,
there are pairs to choose consisting of route and departure time interval, which, using PuT
assignment terminology, are also called connections. The impedance of a connection is
composed of its network impedance and the difference between the actual and desired
departure time slice (temporal utility). To determine the network impedance, the volume and
the capacity-dependent travel time for each network element are stored separately for every
time slice. The progress time of the trip through the network is decremented along the route,
whereby for each network element the travel time of the time slice(s) in which the network
element is traversed is relevant.
The following illustration 143 shows qualitatively the procedure for calculating the impedances
along the time-path line of the connection.
In this case, S (= faSt) and L (= sLow) represent the capacity-dependent speed of the network
element in the relevant time slice. The correct path of the trip and thus the correct network
impedance of the connection results only when the travel time on each link (B in particular in
this case) is included with respect to the time slice reached at this moment.
420
PTV AG
C
S
0
1
S
S
S
S
S
S
S
S
Links
Time
Actual path
Travel times at departure time
Travel times on reaching specific link
Illustration 143: Example of the impedance calculation of a connection
After assignment to individual connections, the network elements are loaded with the demand
for each time slice as in the case of the impedance calculation, which results in new network
element impedances. It is assumed that the departure times of the individual trips are equally
distributed within the time slice, this means, instead of a single time-path line, a volume range
is decremented (Example illustration 144).
PTV AG
421
5.19.1
5.19.2
422
PTV AG
5.19.3
PTV AG
423
Start of
external
iteration
Search
impedance
Counter for
external
iteration
Connection
search
Termination of
external
iteration
Connection
preselection
Independence
Start of internal
iterartion
Initialisation of
choice
impedance
424
n=0
n= n + 1
stop
yes
m =0
PTV AG
Counter for
internal
iteration
m= m +1
Choice
impedance
Connection
choice
Route volume
U pdate search
impedance
q rm =
q r (m1) ( m 1) + q rm '
m
*
R*new = Ro*ld + Rnew Rold
no
Termination of
external
iteration
yes
n = max. number of external iteration
stop
no
yes
5.20
NCHRP 255
This postprocessor for PrT assignments is an Add-on module used to correct assignment
volumes on links and turns of the forecast by means of a correction factor, which is calculated
on the basis of the differences between traffic counts and an assignment, both representing the
same time slice, as is described in Report 255 (National Cooperative Highway Research
Program).
The procedure comprises the following steps:
1. The count values of the incoming link at the node result from totaling the turn count values
for the corresponding From Link.
PTV AG
425
2. Calculate the difference between the link base count (as input by the user) and the value of
the link base assignment value.
3. Calculate the adjusted link volumes as the future link assigned value + the adjustment
factor.
4. Furness (balance) the new link adjusted volumes to match the counted turn volumes. The
result is turns that add up to the new link volume totals, but that have the percentage split
(or distribution) found in the turn counts. The Furness process is iterative.
5. The postprocessed link and turn volumes are stored in a user-specified link or turn attribute.
5.21
The calculated value is derived from the assignment or the network model.
The observed value may be count data or measured data.
Any numeric input or output attributes of the following network objects can be selected:
Links
Nodes
Turns
Main nodes
Main turns
Lines
Line routes
Screenlines
Time profiles
Paths
Prerequisite is, that the observed values must be >0 for the selected network object type.
You can select which objects you want to include in the assignment analysis. There are three
possibilities:
For the assignment analysis, as an option, you can consider user-defined tolerances for userdefined value ranges of the calculated attribute.
The quality of the correlation can be determined and issued in two ways:
426
PTV AG
For the output, the data model of the network object types above has been supplemented with
the calculated attribute Assignment deviation (AssignDev) of type real. Alike all other Visum
attributes, the attribute can be graphically displayed and issued in lists of the respective
network object.
In addition, VISUM calculates various indicators (per group or collectively) that can be issued
in a list or in a chart.
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
The table 138 shows the calculation rules for the output attributes of the assignment analysis.
To the formulas applies:
Z
U
N
AbsRMSE
Abs RMSE
( ) = (Z i U i )2
i =1
N1 2
Intercept
Intercept
ShareAccGEH
Percent with acc GEH
GEH (i ) =
(Z i U i )2
(Z i + U i ) 2
ShareAccRelErr
Percentage objects within tolerance
Percent with avg rel error abs ( Z U )
i
i
------------------------------ Tolerance ( U )
Ui
NumObs
Number of observations
NumClass
Number of objects in
class
ClassVal
Table 138: Calculation rules for the output attributes of the assignment analysis
PTV AG
427
Corr
AvgAbsErr
( a ) =
1
Abs(Zi U i )
N
AvgObs
1
Mean observed value N
AvgRelErr
Zi
( p ) = Abs(ZZi U i )
R2
Coefficient of determination r2
Cf. Excel function RSQ
RelRMSE
(Z i U i )2
Zi
(N 1)
StdDev
Standard deviation
Slope
Table 138: Calculation rules for the output attributes of the assignment analysis
428
PTV AG
Subjects
6.1
PTV AG
429
In large networks, a distinction can often be made between a main network, which is the most
important one to be analyzed, and a subordinated network, which provides feeder functions for
the main network. Examples for this are national rail networks with subordinated regional or
urban bus networks, which also include cars or taxis for access and egress. For modeling the
subordinated network, there are basically two alternatives.
Traffic zones that are not served by the main network are nevertheless connected to stops
of the main network by long connectors. This alternative means that planners are required
to estimate the route choice in the subordinated network accurately when selecting and
setting attributes for the connectors. The route choice can also change in the case of
supply changes in the main network.
With regard to modeling accuracy, it is instead recommended to also model the
subordinated network as a PuT supply. In addition to the considerable effort required to
obtain the timetable data, memory requirements and computing time for the assignment
are also greater. Especially in the case of short headways in the subordinated network, the
number of connections explodes.
A compromise solution involves modeling the entire main network and performing either a
headway or a timetable-based assignment. The subordinated PuT supply in comparison is
only modeled as a used link network and in the course of the either headway or timetablebased assignment it is treated as in the transport system-based procedure (best path search,
see illustration 146).
S
PuT with timetable
Illustration 146: Different modeling options for main and subordinated networks
For this kind of modeling, the used links and turns in the subordinated network are opened for
transport systems of the special PuT-Aux type and provided with specific run times for these
connections. If PuT auxiliary transport systems are not available for all demand segments (for
example car for P+R access), this is expressed by targeted inclusion in the appropriate modes.
The mode for the demand segment Employed with car contains the PuT auxiliary transport
system P+R, but the demand segment Employed without car does not.
The PuT assignment procedures are mainly used for the following applications.
430
To determine volumes, for example line volumes, link volumes, and the number of
passengers who board, transfer or alight at stops.
To calculate passenger-specific PuT skims, for example journey time, number of transfers,
service frequency.
As a timetable information system which provides information on the departure and arrival
times of individual connections.
PTV AG
6.2
The table 139 contains example data of the PuT.dmd file which is provided in English.
PTV AG
431
$VISION
* VisumInst
* 04/11/07
*
* Table: VERSION
$VERSION:VERSNR;FILETYPE;LANGUAGE;UNIT
4,000;Demand;ENG;KM
* Table: ODMATRIX
$ODMATRIX:NO;CODE;NAME;CONTENT;ROUND;NUMDECPLACES
1;C;Car;;0;0
2;H;HVeh;;0;0
3;P;PuT;;0;0
* Table: MATRIXSINGLELISTITEM
$MATRIXSINGLELISTITEM:MATRIXNO;FROMZONENO;TOZONENO;VALUE
1;100;200;2000.000
2;100;200;200.000
3;100;200;90.000
* Table: TIMESERIESDOMAINTYPE
$TIMESERIESDOMAINTYPE:NO;DESCRIPTION;UNITYSTRING;NUMDECPLACES;MAXVALUE;MINVA
LUE
1;Time series by percentages;%;2;9999999999.000;0.000
2;Time series of matrix numbers;No;0;999999999.000;0.000
* Table: Time series
$TIMESERIES:NO;NAME;TYPENO;UNITX;NUMINTERVALS;LENGTHINTERVAL;USEVALUELIST;VA
LUELISTTYPE; VALUEREFTYPE;DECSEPARATOR;VALUESEPARATOR
1;;1;;86400;1;0;0;2;;
* Table: Time series items
$TIMESERIESITEM:TIMESERIESNO;STARTINTERVALINDEX;ENDINTERVALINDEX;VALUE
1;1;19800;0.000
1;19801;23400;33.000
1;23401;27000;67.000
* Table: Demand time series
$DEMANDTIMESERIES:NO;CODE;NAME;TIMESERIESNO
1;;;1
* Table: Demand descriptions
$DEMANDDESCRIPTION:DSEGCODE;DEMANDTIMESERIESNO;MATRIXNO;STARTDAYINDEX;STARTT
IME
C;0;1;1;12:00 AM:00
H;0;2;1;12:00 AM:00
P;1;3;1;12:00 AM:00
Table 139: Demand matrix and temporal distribution of demand for the example
432
PTV AG
6.00
Bus 1
6.30
Train
Bus 1
7.00
Train
Bus 1
7.30
Train
8.00
A-Village
Origin
Station
B-Village
X-City
Destination
Station
X-City (destination)
Train
Bus 1
B-Village
06:10 a.m.
Timetable Train
06:55 a.m.
07:25 a.m.
Station
06:25 a.m.
07:05 a.m.
07:45 a.m.
X City
06:41 a.m.
07:21 a.m.
08:01 a.m.
Station
06:22 a.m.
07:07 a.m.
07:37 a.m.
B Village
06:42 a.m.
07:27 a.m.
07:57 a.m.
X City
06:55 a.m.
07:40 a.m.
08:10 a.m.
Connections
Departure 6:10 a.m., arrival 6:55 a.m., ride time 45 min., 0 transfer
Departure 6:10 a.m., arrival 6:41 a.m., ride time 31 min., 1 transfer
Departure 6:55 a.m., arrival 7:40 a.m., ride time 45 min., 0 transfer
Departure 7:25 a.m., arrival 8:10 a.m., ride time 45 min., 0 transfer
Departure 7:25 a.m., arrival 8:01 a.m., ride time 36 min., 1 transfer
Table 140: PuT supply of the example with connections from A-Village to X-City
PTV AG
433
6.3
PuT paths
Paths are the central result of an assignment (see "Paths in PrT and PuT" on page 209). In the
timetable-based assignment (see "Timetable-based assignment" on page 477) a PuT path is
described through a sequence of path legs which each represent one of the following activities.
Change of location from one stop point to another by using a specific vehicle journey
Change of location from origin zone via a connector and links to a stop point or from there
to destination zone with a PuT-Walk TSys
Transition from one stop point to another with a PuT-Walk TSys
Change of location by using a PuT-Aux TSys
Because each of the used vehicle journeys is known, the path has a time reference (see
"Network objects of the line hierarchy" on page 58). Each of its path legs starts and ends at a
precise time. This is called a connection.
If the option Save paths as connections has been selected for the assignment (see User
Manual, Chpt. 6.1.1.2, page 1072), these connections become visible in the PuT path leg list.
Alternatively, a path can be described without specifying vehicle journeys in detail. In this case
only the time profile is known, which was used for a change of location via a PuT line (see
"Network objects of the line hierarchy" on page 58). The departure and arrival times of each
path leg are then relative times relating to the beginning of the path, completely analog to the
difference between vehicle journey and time profile. Such a path described by the used time
profiles and relative times is called a route.
Naturally, routes are suitable especially to aggregate display of recurring connections at
regular timetables. Two connections at different headway times which otherwise run the same,
are combined to the same route. This usually requires considerably less memory space.
When executing the timetable-based assignment with option Save paths as routes (see
User Manual, Chpt. 6.1.1.2, page 1072), individual connections are still determined and loaded
internally. These are, however, only saved as aggregated routes after the assignment.
Reference is lost to the individual vehicle journeys as well as their exact departure times. The
PuT path leg list then shows the relative times for departure and arrival, and the optional
relations to the first and after the last vehicle journey item are empty. Because the network
elements are loaded prior to discarding the connections, time-based volumes can still be
determined.
The third option Save paths do not save (see User Manual, Chpt. 6.1.1.2, page 1072)
results in that no path information is saved after ending the assignment. Only the derived
values of the network object volumes and also skim matrices are retained after the assignment.
This way, path-based post-assignment analyses are not possible especially no flow bundle
calculation. PuT path list and PuT path leg list also remain empty, however, time-based volume
values are also possible with this option.
Due to its differing user model, headway-based assignment (see "Headway-based
assignment" on page 453) not even internally determines connections but routes. The option
Save paths as connections can be selected, however, but at headway-based assignment
routes are saved in either case (or nothing). These are formally equal to those routes
determined by the timetable-based assignment and can be output in the same way as PuT
path list or PuT path leg list.
434
PTV AG
The table 141 shows the path legs which result from a timetable-based assignment in example
Example.ver. In this case, the paths were saved as connections.
Origin Destination Path
zone zone
index
100
200
Path leg
index
10
100
200
200
200
6:10:00
a.m.
10
OrigConn
6:10:00
a.m.
10
20
06:10:00
a.m.
20
20
Transfer
06:22:00
a.m.
20
40
40
14,000
10
10
40
18,000
10
100
40
Departure
100
Time profile ID
10
40
16,000
10
DestConn
40
06:41:00
a.m.
06:10:00
a.m.
10
OrigConn
06:10:00
a.m.
40
06:10:00
a.m.
DestConn
06:55:00
a.m.
40
06:55:00
a.m.
10
OrigConn
06:55:00
a.m.
40
06:55:00
a.m.
DestConn
07:40:00
a.m.
40
07:25:00
a.m.
10
OrigConn
07:25:00
a.m.
10
20
07:25:00
a.m.
20
20
Transfer
07:37:00
a.m.
20
40
Table 141: Path legs after a timetable-based assignment (paths saved as connections)
PTV AG
435
Path leg
index
5
100
200
40
17,000
10
1
2
10
40
Time profile ID
Departure
DestConn
08:01:00
a.m.
40
07:25:00
a.m.
10
OrigConn
07:25:00
a.m.
40
07:25:00
a.m.
DestConn
08:10:00
a.m.
Table 141: Path legs after a timetable-based assignment (paths saved as connections)
For the same assignment, table 142 shows the path legs, if the paths were saved as routes.
Origin Destination Path
zone zone
index
100
200
Path leg
index
10
100
200
200
40
Departure
00:00:00
a.m.
10
OrigConn
00:00:00
a.m.
10
20
00:00:00
a.m.
20
20
Transfer
00:12:00
a.m.
20
40
40
49,000
10
100
Time profile ID
10
40
16,000
1
10
DestConn
40
00:31:00
a.m.
00:00:00
a.m.
10
OrigConn
00:00:00
a.m.
40
00:00:00
a.m.
DestConn
00:45:00
a.m.
40
10
00:00:00
a.m.
OrigConn
00:00:00
a.m.
Table 142: Path legs after a timetable-based assignment (paths saved as routes)
436
PTV AG
Path leg
index
Time profile ID
Departure
10
20
00:00:00
a.m.
20
20
Transfer
00:12:00
a.m.
20
40
40
DestConn
00:36:00
a.m.
Table 142: Path legs after a timetable-based assignment (paths saved as routes)
6.4
PuT skims
By means of the Calculate PuT skim matrix procedure or during an assignment (see User
Manual, Chpt. 6.4, page 1142) the skim data can be calculated for the PuT skims of the various
skim categories (see "PuT skim categories" on page 437).
Since there are numerous routes or connections for an OD pair usually, the skims gained per
route or connection are aggregated to relation-based skim data by OD pair. Apart from the
service frequency which results from the number of connections, all skims are provided on the
level of connections as well as on the level of OD pairs.
6.4.1
6.4.1.1
Skims of time
In Visum, skims of time (table 143) are administered in seconds. For skim matrices you can
select the unit minutes or seconds.
Skim
Definition
PTV AG
437
Skim
Definition
Origin wait time (OWT) Wait time at the start stop point (applies to the headway-based assignment only,
as for the timetable-based procedure OWT = 0 is assumed)
Note:
For the timetable-based procedure, an adapted origin wait time can be
calculated (see "Adapted skims of time for the timetable-based assignment" on
page 439).
Weighted origin wait
time
Product from the origin wait time and the weighting factor of the origin wait time
in the settings for the impedance of the headway-based assignment. This skim
is only available in the headway-based assignment.
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 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 by TSys Time spent inside PuT vehicles of a certain public transport system.
(IVTT)
PuT-Aux time (XZ)
Walk time for transfer links between two stop points within a stop area or
between different stop areas of a stop
Time between the departure from the origin zone and the arrival at the
destination zone
JRT = ACT + OWT + IVT + TWT + WKT + EGT
Note:
For the timetable-based procedure, additionally the adapted journey time can
be calculated (see "Adapted skims of time for the timetable-based assignment"
on page 439).
Time between the departure from the origin stop point and the arrival at the
destination stop point
RIT = IVT + TWT + WKT
Note:
For the timetable-based procedure, additionally the adapted journey time can
be calculated (see "Adapted skims of time for the timetable-based assignment"
on page 439).
Perceived journey time Perceived journey time (see "Perceived journey time" on page 446)
(PJT)
PJT = f(ACT, EGT, OWT, TWT, NTR, IVT, WKT, XZ)
Adaptation time (ADT)
Difference DeltaT between desired departure time and actual departure time
Extended adaptation
time (XADT)
438
PTV AG
6.4.1.2
Skims of length
You can select the metric units meters or kilometers (alternatively: imperial feet/miles) for skim
matrices. The table 144 shows all skims of the length provided in Visum. The abbreviations in
parentheses indicate the file extensions which are used by default for skim matrix output in
version files.
Skim
Definition
Length of the access route on the footpath from the origin zone to the
origin stop point
6.4.1.3
Monetary skims
Definition
Fare (FAR)
Fare for the PuT ride between origin and destination zone (see "Fares" on
page 447)
PTV AG
439
6.4.1.4
Skims of frequency
Definition
Number of transfers
(NTR)
Number of transfers between origin and destination stop point (per connection).
-
Service frequency
(SFQ)
Number of operator
changes (NOC)
Number of transfers with different operators of previous and next path leg. -
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. -
6.4.1.5
The table 147 lists the provided skim that results from the values of the selected attribute.
Skim
Definition
Path leg attribute (PLA) Throughout the entire path aggregated value of the selected (direct or indirect)
path leg attribute, for example Line route\AddValue1.
6.4.1.6
Derived skims
Derived skims (table 148) result from a combination of the above listed skims.
Skim
Definition
Impedance in a time
interval (IPD)
Ratio of the journey distance and the journey time between origin and
destination zone [km/h]
Journey speed [km/h] = journey distance [m] / 1,000) / journey time [min] /
60)
Table 148: Derived skims
440
PTV AG
Skim
Definition
Ratio of the direct distance and the journey time between origin and destination
zone [km/h]
Direct distance speed [km/h] = direct distance [m] / 1,000) / journey time
[min] / 60)
In-vehicle distance as
percentage by TSys
(IVTP)
Equivalent journey
time (EJT)
Skim value which results from a user-defined formula according to the set
parameters. The unit of the journey time equivalent is determined by the userdefined formula.
Extended impedance
(XIMP)
Utility (UTL)
pt (c ) =
ut (c )
ut (c)
cC
U t dt
U = tT
dt
tT
Here, dt is the total demand within time interval t.
PTV AG
441
Skim
Definition
Discomfort due to
capacity overload
(DISC)
Time during which a passenger has no seat in the course of this journey.
The skim is calculated as journey time weighted by vehicle journey item. Its
weight is a function of the volume/seat capacity ratio.
For each individual PuT path C, the discomfort E(C) is defined as follows.
P
A a B
S
a
E (C ) = Fa e
aC
Here
a = Index over all vehicle journey items of a PuT path C
Fa = Journey time of the vehicle journey item a (known from its time profile)
6.4.1.7
The illustration 149 and the table 149 illustrate a few skims for the connections of an OD pair.
A-Village
Bus 1
Station
X-City
Train
Bus 1
Connection 2
Bus1
Bus1, Train
300
300
442
PTV AG
Connection 1
Connection 2
45
28
500
500
45
36
53
44
27,500
20,000
18,385
18,385
31.1
27.3
20.8
25.1
6.4.1.8
The table 150 shows which skims can be calculated per PuT assignment procedure.
Skim output by procedure
Default ext.
TSysbased
HWaybased
Timetablebased
JRT
IVT
PuT-Aux time
AXT
OWT
Journey time
Journey time adapted
Ride time
Ride time adapted
In-vehicle time
JRTA
RIT
RITA
OWTA
WOWT
TWT
TWTA
WTWT
XTWT
X
X
X
X
Walk time
WKT
Access time
ACT
Egress time
EGT
PJT
Number of transfers
NTR
PTV AG
443
Default ext.
TSysbased
HWaybased
Timetablebased
Service frequency
SFQ
Direct distance
DID
Journey distance
JRD
Ride distance
RID
Trip distance
IVD
PuTAux distance
AXD
WKD
Access distance
ACD
Egress distance
EGD
Journey speed
JRS
DIS
Fare
FAR
NFZ
NOC
X
X
IVTD
IVTP
IVTT
Impedance
IPD
Utility
UTL
PLA
Adaptation time
ADT
XADT
XIMP
EJT
X
X
DISC
X
X
6.4.1.9
Depending on the chosen search procedure there are different possibilities to aggregate the
skim values (Skim) of the connections to mean skim data (mSkim) by OD pair (table 151):
444
PTV AG
Aggregation functions
HWaybased
TTbased
Unweighted quantile
For 0 z 1 the z-quantile of a finite, classified series of values (x1, ..., xn) is
defined as smallest number y, to which applies that # is {i : xi y } / n z.
Weighted quantile
The connections are weighted with the volume at the calculation of the quantile.
Unweighted mean
Num Conn
Skimi
=1
i
mSkim =
Number of Connections
Weighted mean
NumConn
Skimi Passengersi
i
=1
mSkim =
Passengers
Unweighted mean restricted to paths of sufficiently low impedance
Skim j
mSkim =
j =1
Share of
mSkim =
j =1
Share of
j =1
total demand j
mSkim = skim value for route/connection with minimum perceived journey time
X
X
Table 151: Combination of skim data to the mean skim value per OD pair
Note: For calculation of a weighted mean, by default, the weights of skim matrix calculation
are used. In this case, the demand in the time series intervals is set in relation to the total
demand in the assignment period. If the weights of a percentage time series or the demand
of a matrix time series for an OD relation equals 0, a fixed demand is assumed and the
respective time interval is weighted with its length in relation to the assignment period.
The skim service frequency SFQ does not refer to a particular route or connection, but to an
OD pair.
PTV AG
445
For the timetable-based procedure, the service frequency results from the number of different
arrival times.
Example
For an OD pair, three connections are determined:
Connection
Volume
50 %
20 %
30 %
Number of transfers
6.4.2
50 % quantile
unweighted
weighted
unweighted
weighted
(1 + 3 + 2) / 3
=2
Values: (1, 2, 3)
50 % quantile = 2
Values: (1,1,1,1,1,2,2,2,3,3)
50 % quantile = 1
446
PTV AG
6.4.3
Fares
Visum can be used to calculate fares (see "PuT fare model" on page 582). The fare per
connection results from the used ticket type(s). It includes the specific supplement by transport
system (for ICE, for example). These fares are calculated for each connection. Except for the
impedance definitions of both the headway-based and the timetable-based assignment
procedures, the fares can also be output as skim matrix and can be taken into account for the
revenue calculation which is performed by the PuT operating indicators procedure.
6.4.4
Temporal utility
For the timetable-based assignment, the temporal utility of a connection is included as a further
skim value in the definition of impedance (see "PuT impedance functions" on page 448).
The temporal utility of a connection depends on the following parameters:
In this way it can be modeled that also the temporal position of a connection has an effect on
its attractiveness.
The temporal utility of a connection is highest for that interval in which the connection is placed,
because then T = 0 applies. The higher T, the lower the temporal utility.
The timetable-based method includes the temporal utility in the impedance definition in
different ways either by using a function N = f(DT) or by using T directly. In either case,
parameters are provided for the sensitiveness to early or late departures definition.
For both variants, the following applies.
The shorter the period between the actual and the desired departure time, the higher the
temporal utility of the connection and the lower its impedance.
Time series with hourly intervals
T (6-7) = 7:20 7:00 = 20 min
T (7-8) = 0 min
T (8-9) = 8.00 7.20 = 40 min
6:00
7:00
8:00
9:00
Dep. 7:20
PTV AG
447
6.5
Definition of impedance
6.6
448
PTV AG
The proportional distribution of the PuT is effected similar to the distribution by percentage of
PrT. All origin and destination demand of the zone is distributed onto all connectors of the zone
proportionally to their respective current connector weights. During the assignment, a
temporary virtual zone is generated for each connected node. The virtual zone's total demand
complies with the connector's original share in the total demand of the original zone. The
assignment calculation is based on the virtual zones. After the assignment, the temporary
zones are deleted and the results are allocated to the original zones.
Example
Two zones with the following connectors are given.
The connector weights for origin and destination are set according to table 154.
Connector node
Weight (origin)
Weight (destination)
20
30
80
50
20
40
90
60
10
For the assignment, this leads to the temporary demand matrix displayed in table 155.
Virtual zone
180
20
270
30
450
50
160
40
240
60
Table 155: Temporary demand matrix for the assignment in the example
The value of the temporary OD pair 1 4 is calculated from 1,000 0.2 0.9 = 180.
6.7
PTV AG
449
In most cases, proportional allocation of these indicator values to the link does not make
sense, which is why the definition for those indicators has been standardized:
A link is regarded as being used (completely) by an object of the line hierarchy if the link section
traveled accounts for at least half of the link length ( 0.5). For indicators that refer to sections
between stop points (for example volume), the following applies. To each stop point on a link
the nearest node is allocated (either the FromNode or ToNode of the link). The indicator value
of the section between the last stop point, to which the FromNode is assigned, and the first stop
point, to which the ToNode is assigned, is regarded as the indicator value for the (entire) link.
The illustration 150 shows an indicator value calculation example for such partially traversed
links.
Node
Stop point
A
Links
C
2
D
3
E
4
Line route 1
Service trip 1
Illustration 150: Example for indicator value calculation for partially traversed links
Line route 1 touches the links 2, 3, and 4 (because the section traveled accounts for at least
half of the link), not link 1 however, because the traversed section is < 0.5 on link 1. Vehicle
journey 1 only touches link 3. The volume between the stop points B and C is regarded as the
PuT volume of link 2, while for link 3, volume C D applies and for link 4, the volume between
D and E.
6.8
From the links of this basic network a graph is constructed which is the basis for a best-route
search.
Because individual lines are not distinguished, transfer stops with their respective transfer
times cannot be included in the search. It is possible, however, to include transition times
between different transport systems (transfer penalties for transport system changes, for
example between bus and train).
The transport system-based assignment calculates exactly one route for each pair of origin
zone and destination zone, which consists of one origin connector and one destination
connector for the PuT as well as of links and turns, which are permitted for a public transport
system. Transfers are changes of the transport system which are considered in the form of a
time penalty in the route search.
450
PTV AG
6.8.1
The assignment procedure based on transport systems is recommended for a first draft of a
new line network. The procedure calculates the shortest routes (minimum time required) which
are then charged with the travel demand. The resulting volume flows represent the "desired
line network" of the passengers.
The volumes resulting from the timetable-based assignment and the headway-based
assignment will differ significantly from the results calculated by the transport system-based
assignment. Under no circumstances neither a timetable-based nor a headway-based
calculation should be replaced by the transport system-based procedure.
6.8.2
With a 10-minute transfer penalty, this results in a ride time of 38 minutes. All 90 trips from AVillage to X-City are assigned onto this route.
This results in the volumes shown in illustration 151.
PTV AG
451
A-Village
90
Station
X-City
90
B-Village
Illustration 151: Network volume after transport system-based assignment (parameters file TSys1.par)
From a transfer time of 18 minutes onward, the TSys bus is used instead of the train for the
section between the Station and X-City (illustration 152).
A-Village
90
Train
X-City
90
B-Village
90
Illustration 152: Network volume after transport system-based assignment (parameters file TSys2.par)
6.8.3
6.8.3.1
Route search
452
PTV AG
For links which may be used by several public transport systems with different run times, the
minimum run time is used.
6.8.3.2
Route loading
The total demand of an OD pair is assigned to the route with the lowest impedance.
The transport system-based procedure carries out exactly one best-path search for every OD
pair.
6.9
Headway-based assignment
For the headway-based procedure, each line is described by the line route, the run times
between line stops, and the headway. Actually, it is the time profile which comprises this
information and the headway-based procedure works on this model level (see "Network
objects of the line hierarchy" on page 58). In the following sections the term line is used for the
sake of convenience. This emphasizes that the timetable of the individual vehicle journeys is
not regarded.
Transfer wait times are usually regarded globally, which means that the departures of different
lines are independent of each other. As a standard, a timetable coordination is not taken into
consideration. By explicit modeling, however, it can be expressed that lines operate with the
same headway each on a shared section, or rather a fixed transfer wait time exists between
two lines (see "Matched transfers" on page 475). TSys of the PuT-Aux type are not yet
regarded.
The headway-based assignment procedure includes the three operational steps.
1. Headway calculation (see "Headway calculation" on page 454)
2. Route search and route choice (see "Route search" on page 471 and "Route choice" on
page 472)
3. Route loading
In the combination of search and choice, the headway-based procedure differs from the
timetable-based assignment. In this second step, possible paths between two traffic zones are
detected and simultaneously a distribution is specified between them. The paths do not
represent connections, but routes (see "PuT paths" on page 434), as the calculation is not
done on the time axis, but merely regards travel times and headways. In the third step, the
routes found in the search are loaded with the demand from the demand matrix and stored in
memory (if desired).
6.9.1
PTV AG
The procedure, as is the case with the timetable-based assignment, not only determines
the optimum routes, but also those that are good enough. However, the transfer wait time
goes in only globally here.
A co-ordination of the timetable is regarded only if the co-ordination has been modeled
explicitly (see "Coordination" on page 474).
453
6.9.2
The number of transfers, journey time and the ride time can be estimated with sufficient
accuracy if all lines have short headways.
The bandwidth of various choice models offers the big advantage of being able to configure
the procedure in such a way, that it precisely reflects the available passenger information
provided in the analyzed network. Accordingly, you can apply different models to make an
estimate of the benefit, which can be achieved by investing in passenger information
systems.
Compared to the timetable-based procedure, the headway-based procedure shows a
considerable reduction of computing time for most PuT networks, this is especially the case
for networks with regular headways (fixed-time rhythm). In networks in which many lines
consist of only one trip, however, time savings are low.
Because the headway-based procedure normally does not take the co-ordination of the
timetable into account, the procedure is suited for public transport planning in urban areas,
particularly if the current state (exact timetable is available) is to be compared with
scenarios for which no exact timetables exist yet. This procedure is not suited for PuT
supply planning in rural areas or for long-distance transport, because in these cases long
headways occur, and it is an elementary planning task to provide connections.
Using the headway-based procedure, the fares can be regarded in the impedance
calculation. For that purpose, the full range of the Visum fare model is provided. Due to the
complexity of the fare model, taking fares into account in an assignment might increase the
required computation time. With less complex fare structures, the variant using fare points
should be favored. Note that the fare is not computed for the complete path but per path leg
during an assignment (see "Generalized costs as impedance" on page 456)).
Headway calculation
You can define the headway of a line in three different ways (see User Manual, Chpt. 6.2.3.1,
page 1085).
Each of the three methods can be applied separately by time interval. That way you can model
that the transport supply varies within the assignment period for example, because of the
higher demand during morning peak hours.
454
PTV AG
In the case of networks with short headways and sufficiently broad time intervals, this simplified
approximation is acceptable. Generally speaking, however, this approach is problematic for
two reasons.
On the one hand, the definition is too sensitive to shiftings of individual departures across the
interval limits. This will cause discontinuities in the result. This problem always occurs if the real
headway of a PT line is no divisor of the length of the demand time interval. For a line with a
40-minute headway, for example, and the time interval l = [6:00,7:00), different headways are
calculated for the particular departure times (table 156).
Departure times
Calculated headway
60 minutes
30 minutes
Table 156: Example for headway calculation from mean headway according to timetable
On the other hand, this approach cannot reflect the following fact: For the passenger who
arrives at random, trips spread evenly throughout the time interval generally mean less wait
time than trips that are piled up. The following third definition, therefore, is used as the default
setting for the headway-based procedure.
= ------------
ba i=0 i
Here applies: 0 = ( x 1 a ) , i = ( x i + 1 x i )
and n = ( x n + 1 x n ) ( x n + 1 b )
to the
remaining {1, ..., n-1}. i is in each case the expected wait time in a sub-interval.
If you now look again at the example with the 40-minute headway and the interval
l = [06:00,07:00), you get a much more balanced picture.
Departure times
Calculated headway
43 20
33 20
Table 157: Example for headway calculation from mean wait time according to timetable
Using the example in the first row, the calculation can be briefly explained as follows.
In this case n = 1, x1 = 06:35 AM and x2 = 07:15 AM apply.
PTV AG
455
Therefore follows
2
and
6.00, 7.00
= 2600
------------- = 43,3 minutes.
60
a, b
Compared to the case of the naive approach , this example shows that the calculated
values vary far less when shifting the specific departure times.
6.9.3
+ Origin wait time FacOWT (here, the origin wait time is computed according to a formula)
+ Transfer wait time FacTWT weight attribute of the stop area
+ Number of transfers FacNTR
+ Boarding penalty PuT (time profile attribute)
+ Boarding penalty PuT-Aux (transport system attribute)
+ Mean delay (time profile item attribute)
Here, journey times, costs, etc. are deterministic. The origin wait time and the transfer wait time
result from the previously specified headway of the PuT line which the passenger boards at the
origin stop or at the transfer stop. Within the limits of their headways, they depend - except in
the case of co-ordination (see "Coordination" on page 474) - in a random way on the transfer
lines' relative position to each other.
The run time can be multiplied by a user-selected time profile item attribute in order to model
the vol/cap ratio (for example the availability of seats) or other aspects of usability (for example
the level of comfort) of a line.
Other individual time penalties and weighting factors for boarding events or transfers can be
taken into consideration as follows (see User Manual, Chpt. 6.2.3.4, page 1091).
456
PTV AG
Wait time factors and penalties on the origin wait time from any attribute of stop areas and/
or time profiles
The wait time factor for the transfer wait time from any stop area attribute
A boarding penalty of any time profile attribute (for PuT lines) or transport system attribute
(for transport systems of the PuT-Aux type)
A mean delay from any time profile item attribute
With the time penalties you can for example model, that some lines are favored by the
passengers because of their better quality of traveling, or because they are usually punctual.
Via the wait time factors and penalties you can model that the passengers prefer waiting at
some stops than others.
Via the origin wait time in combination with time profile-based weighting factors you can model
that passengers do not randomly arrive at the stop but have a profound knowledge of the
timetable in the case of long mean headways. In other words, you can restrict the origin wait
time to the maximum value X via the weighting factor, for example: For all time profiles with
headway T > X, enter X / T as the origin wait time weighting factor. In this case, the weighting
factor 1 will be used for the time profiles with headway T < X.
Using PuT-Aux transport systems means no wait times, since the permanent availability of
PuT-Aux TSys is assumed. Using boarding penalties for transport systems of the type PuTAux, you can still model a delay during transition.
Fare
As an alternative to fare points, the fare derived from the Visum fare model can also be used.
There are no restrictions applicable in terms of number or properties of the fare systems or
ticket types.
In contrast to the timetable-based variant, which includes the fare of the complete path as
impedance component in the choice model, the impedance of the headway-based assignment
includes the total of the fares by path leg. To reach precise correspondence to the real fare
model, the property Fare applies to = each path leg separately is required for each of the
used fare systems, i.e. each boarding passenger has to purchase a new ticket. In other cases,
in particular for degressive fares over several path legs, the fare total included in the
impedance can differ from the fare per total path.
The example below illustrates how fares are applied in the headway-based procedure.
The demand from A to B is 100 trips. The supply-side provides two alternative bus
connections. The model consists of 5 fare zones, and for the tickets, a zone-based fare has
been chosen as fare structure. The table lists the fares depending on the number of traversed
fare zones.
PTV AG
457
Fare zones
Fare [CU]
>2
10
Example 1
Either line runs through from A to B, one in the North and one in the South. Either line runs
regular services every 10 minutes. The North line traverses two fare zones, the fare in the
impedance function is 5 CU. The South line traverses five fare zones, the fare is 10 CU. With
an impedance definition of 1 journey time + 2 journey time, the volumes of the south and
north lines are the same.
North
South
20
10
10
Volume
50
50
Note: For the description of the volume distribution process in the headway-based
assignment please refer to the particular section in this manual (see "Example for the
transport system-based assignment" on page 471). Since both the headways and fixed
impedance components of either route are identical, identical volumes are calculated.
Example 2
Now, the North variant consists of two separate lines providing coordinated connections with a
journey time of 10 minutes each. Neither transition times nor transfer penalties are regarded.
458
PTV AG
As the headway-based procedure's impedance calculation calculates the fares by path leg, a
different impedance will be returned compared to the case mentioned above: For the first
section, the fare is 5 CU (2 fare zones), for the second section, the fare is 3 CU (1 fare zone),
thus the fare sums up to 8 CU in the impedance calculation. The volume distribution changes
accordingly:
North
South
JT [min]
20
10
5+3 = 8
10
Volume
92
Remarks on the volume distribution: In the impedance range between 30 and 36, the South
x 36
variant accounts for all shares. In the range between 36 and 40, the probability is 1 --------------- .
10
6
4
For the South variant, the resulting probability is ------ 1 + ------ 0,8 = 0,92 .
10
10
Summing up the path leg fares in the impedance of example 2 corresponds to the situation,
where a ticket has to be bought on each path leg. If a different fare system applied in reality
(because the passenger has the right to use just a single ticket for the trip from origin to
destination, for example), an inaccuracy turns out here. For compensation purposes, "transfer
discounts" can be defined: Use the Transfer fares function which is provided with the Visum
fare model for the definition of discounts that balance the fare amount charged too much in the
case of fare system transfers. To correct the fare taking effect in the impedance formula, the
following transfer fare had to be defined in this example: 5 CU - 8 CU = -3 CU.
Note: The only difference is how fares in the impedance function are taken into account.
Finally, always the real fare is regarded, which is not the path leg fare total. This is particularly
applicable to list outputs and skim calculations. In other words, for assignment analyses the
real fare is returned by passenger trip.
Taking fares into account might significantly increase the computation time required for the
assignment, it actually depends on the complexity of the fare model. Instead of using a fare
model which mainly consists of proportional (e.g. distance-based) fares the usage of fare
points is recommended.
6.9.4
PTV AG
459
The latter applies for example, when dynamic passenger information systems have been
installed at stops. The passengers can then see which of the departing lines in the current
situation offer the least remaining travel time to their destination. As a result, they will for
example not board a line if the information system gives them the information, that shortly after
this line there will be another much faster line.
The individual choice models for the situation of a passenger waiting at a stop are introduced
below. To describe the mathematical basis, we still require a few terms.
Notation
L = {1, ..., n} describes the set of available PuT lines. Each line i L has a certain remaining
C L' = W L' +
i L'
i si
The parameters are random variables because they depend on the random arrival of lines at
the stop.
For the optimal set L* also the following applies: E(CL*) E(CL) for any L L.
6.9.4.1
If the passenger does not have additional information, he has to decide ad hoc whether to
board the arriving line or not. The choice model determines the optimal set of lines, and the
optimal strategy of the passenger is to choose the line in the set that arrives first.
460
PTV AG
In addition to the missing passenger information, the model introduced in this section is most
notably characterized by the fact, that the headway (the temporal gap between two departures
of a line) is not assumed to be a constant, but rather exponentially distributed. The expected
gap value is exactly the same as for constant headways 1 / i, therefore the "Frequency" of the
line. In contrast to constant headways, however, the headway times strongly scatter around
this value.
Fundamental characteristic of the exponential distribution which is taken as a basis is that the
wait time which has already elapsed since the last departure of the line, does not state how
long the passengers have to wait for the next departure. This property is called
"Memorylessness". Thus, the greatest possible irregularity of the timetable is assumed.
The optimal set under these model assumptions is composed as follows. The following is set
first:
i
1+
j sj
j=1
u i = ----------------------------------i
j = 1 j
Then, the optimal set of lines is achieved by L* = Li*, where i* = max{i:si ui-1}.
It can be proved that the i* composed in such a way reduces the expected remaining costs.
A line i thus exactly belongs to the optimal set, if its remaining travel time (without wait time) is
not higher than the expected remaining travel time plus wait time of the combined lines Li-1 =
{1, ..., i-1}. This procedure has the effect, that comparatively few lines are used, because with
this comparison the lines Li-1 are treated in such a way, as if they were perfectly coordinated.
Coordinated here means, that they are arranged so evenly, that they appear as a single line
with frequency =
i1
j = 1 j .
distribution.
The share of the lines i L* are equal to the probability, that they depart first, as can be taken
from the following formula.
i
i = ---------------------
j
j L
Note, that the remaining travel times of the lines do not appear in the share definition. If lines
are adequate enough to be contained in the optimal line set, their shares only depend on their
headways. This property illustrates the heavily simplified construction of this choice model.
1 E ( W L ) = --------------------- j
j L
This choice model should only be used, if the line headways are extremely irregular, in other
words, if the passengers face a high level of uncertainty.
PTV AG
461
6.9.4.2
With the same level of information, however, constant headways, the strategy of a passenger
is in principle the same. From an optimal line set L* = Li* he or she selects the line which
arrives first. The determination of i* now follows the following different approach.
You can recalculate that it is insufficient in this case, to regard the result (L1, L2, ..., Ln) of
potentially optimal line sets and to cancel exactly at that point when for the first time the
following applies: ECLi > ECLi-1. This is caused by the fact, that there can be more than one
local minimum in the sequence (Li). Therefore i = argmin i { EC L } guarantees, that the
i
optimal line set is composed exactly from those lines, which reduce the expected remaining
costs if being included in the selection.
The shares assigned to the individual lines again correspond with the possibility of arriving first.
h
i = i
( 1 j w ) dw
0 j L, j i
h = min { h i } is the minimal occurring headway. This results in the following expected wait
time.
h
E ( W L ) =
j = 1 ( 1 wj ) dw
0
If the timetable in the analyzed network is regular and only slightly irregular, and the
passengers do not have any information on departure times, this choice model is more realistic
than the model considered before.
6.9.4.3
If - in case of constant headways - the passenger makes use of the information on how long he
has been waiting already at the stop, he will be able to reduce his expected remaining costs in contrast to the previously described models. The passenger knows for example, that after
waiting eight minutes, a line with 10 minutes headway has to arrive within the next two minutes.
The passenger can make use of this information and ignore potentially earlier arriving lines,
which are, however, at least two minutes slower.
The passenger has this information independently of the external infrastructure. To assume
this is therefore not a strong assumption.
In this case, the optimal line set L* depends on the elapsed wait time and is therefore no longer
constant. Determining the set is more difficult than in the previous cases. It can be proven that
L* has the following shape.
462
PTV AG
Given are i* n and an orderly sequence of times 0 ti* ... tl. This means that the in time
interval Ij = (tj+1,tj] just Lj = {1, ..., j} forms the optimal line set. tj is here the exact point in time
t, from which onward the remaining journey time of line j is greater than or equal to the
expected remaining costs (including wait time according to t) of the lines Lj-1. In other words, tj
is the unique solution for t in s j = E ( C L
j1
W > t) t .
The optimal strategy is as follows. If the passenger observes an arrival of a line from Ij, after
wait time Lj, he will board that line. Other lines he will ignore.
One can show that this strategy reduces the expected remaining costs. As illustrated in the
following, it corresponds more with the real behavior of passengers than its abstract definition.
Because the passenger knows the headways of all lines, his knowledge on which available
lines are still worth taking, increases the longer he is waiting. Comparable slower lines may still
be reasonable options at the beginning of the wait time. There is a time, however, when the
evaluation topples. At a certain time, the expectancy for the remaining wait time for the faster
j-1 lines is less than the difference between their remaining travel time and the remaining travel
time of the line j. Exactly as of this time is it no longer worth it to take line j even if it arrives
immediately. The times tj mentioned above are exactly those moments when a line j is no
longer included in the optimal line set L* for this reason.
Example
Let us regard the following simple situation of two lines.
Line
Run time
Headway
10
15
13
15
The passenger waits maximum 15 minutes to continue his journey. After t minutes the
expected remaining travel time for line 1 is exactly 10 + (15 - t) / 2 minutes. To determine the
point of time as of which this expected value is less than the run time of line 2, you resolve 10
+ (15 - t) / 2 13 according to t which results in t 9, thus t2 = 9.
In other words, a vehicle of line 2 can be ignored after 9 minutes, because the three minutes
longer run time of line 2 is not made up by the mean remaining wait time for line 1.
6.9.4.4
This model is based on the assumption that a passenger does not only know the times and
headways of all lines, but can (at least at the stop) also get information on precise departure
times. The optimal strategy can thus be formulated as follows.
A passenger boards the line that offers the least remaining costs given the actual
departure times.
PTV AG
463
Unlike in previous cases, the passenger does not simply board the first arriving line of a certain
(possibly time dependent) set. Because all wait times wi are known, the passenger's decision
is not subject to stochastic influences. He or she rather selects exactly that line whose
remaining costs si + wi are at a minimum.
The optimal line set thus consists of all lines, which have the least costs in some timetable
positions.
and
L = L i
The optimal set of lines are those, which are optimal in border cases, since they arrive without
a wait time, whereas all other lines have to be waited for by a complete headway.
The calculation of shares is as follows.
i = P ( C i < C j j )
(60.1)
si + hi
1
= ---hi
P ( C i < C j j
C i = x ) dx
(60.2)
si
si + hi
1
= ---hi
j i P ( C i < C j
C i = x ) dx
(60.3)
si
si + hi
1
= ---hi
j i P ( Cj > x ) dx
si
1
= ---hi
464
sk + 1
P ( Cj > x ) dx
k=i
i
1
= ---hi
(60.4)
sk
sk + 1
x sj
-
1 ----------hj
k=i
sk
(60.5)
j = 1
ji
dx
(60.6)
j = 1
ji
PTV AG
E ( W L ) =
i = 1 ---h-i
( x si )
x sj
-
1 ----------hj
dx
j = 1
ji
To assume passenger information is no extremely strict requirement. Many places already
have information systems which display the next departure times on the basis of real-time
operating data. Alternatively, timetables could be hung up at stops. There are also no limits
regarding other technical resources.
k=i
6.9.5
sk
The passenger is still at the start of the journey (at origin zone).
The passenger is on board a line.
The passenger can choose between transfer stops which may only be reached by a
footpath.
In such cases, the choice has to be modeled in a different way, because it generally is not
based on observations, but on estimates. However, when passengers rely on estimates or not
again depends on the passenger information available in the network. Below it is described
briefly under which conditions observations are not restricted to the departures of the lines at
the current boarding stop.
PTV AG
465
6.9.5.1
With a suitable infrastructure, a stop-based departure display can also be seen by passengers
in arriving lines before alighting. In this case, the choice model Information on departure
times (see "Information on departure times" on page 463) is not just applied to the possible
transfer lines, which are available after alighting. In fact, it already refers to the decision of the
passenger still on board, because by acknowledging the departure times early enough, the
passenger can judge whether continuing the journey on the same line is more profitable than
getting off. This also applies, if information on connections provided at the next stop is
displayed in the vehicles.
Another relevant difference in cases is the question, whether passenger information systems
at a stop only display departure times of those lines which depart from just this stop. In some
places, displays are used which also include the departures of other lines, departing at stops
close-by. An example of this is the display of departures of subway lines in the concourse.
Are both of these features provided, also a passenger who is still on board of a line knows the
next departure times of all potential transfer lines at the current stop and at those which can be
reached by foot from this stop. The model is then applied to the total set of available lines. The
technical realization of such a level of information can for example be a service, which provides
via cell phone the information on the current timetable and - on the basis of operational realtime data - a recommendation for the passenger. A completely different model assumption,
which nevertheless leads to the same level of information, is the passenger's knowledge of the
timetable.
The border case of complete passenger information is provided, if the situation described
above is also assumed, when the passenger is still at the starting point (thus in the origin zone)
of his journey. In order to observe also the departure times of the possible boarding lines from
there, again a mobile information service or complete knowledge of the timetable have to be
assumed.
6.9.5.2
Apart from the case of complete passenger information, there always are also decisions which
are made on the basis of estimates. The simplest example is the choice between several
boarding stops at the start of the journey or at a transfer. If passengers do not have any
information on departure times on board, the decision on continuing the journey or getting off,
in this case depends on the expected remaining journey time after alighting.
Such decisions can be modeled in two ways:
The second case reduces the expected remaining costs, however, does not reflect the
fuzziness of the passengers' behavior. That is why a discrete choice model should be favored
normally. If the flexibility parameter goes towards infinity, the result comes close to the 0/1
decision in favor of the alternative with the lowest expected remaining costs anyway.
466
PTV AG
6.9.5.3
6.9.5.4
We analyze the decision of a passenger, who is on board of line 1 and arrives at stop A. First,
we will look at how the structure of the choice made changes, if the available information
varies.
The analyzed scenarios are the following.
1.
2.
3.
4.
5.
Hierarchical structure
In the first example we are looking at the situation in scenario 1.
PTV AG
467
In contrast to the example above, the passenger identifies the next departure times of line 2
directly after getting off at stop A. The passenger is thus able to determine exactly what the wait
time and the remaining journey time will be, if he continues his journey from there. Compared
to that, the passenger knows only expectations for the boarding stops B and C.
In the third example, let us assume that already on board the line the passenger can find out
which connections are available from stop A. The decision tree then looks as follows.
468
PTV AG
The characteristic of the first decision now changes, because continuing the journey with line
1 and a transfer to line 2 or 3 now represent alternatives on the same level, as all wait times
are known.
Travel times and headways of the lines in the example network are illustrated in table 159.
Line
1
2
Run time
Start -> A
A -> Destination
Headway
5
8
10
15
10
Table 159: Travel times and headways of the lines in the example network
The passenger's situation on board line 1 arriving at stop A is interesting, because there are
several transfer options which assure a shorter remaining journey time. The table 160 shows,
that the passenger can derive a much bigger advantage from these transfer alternatives, the
more information he has on the arising wait times.
PTV AG
469
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
60.1
59.7
32.3
45.4
28.2
9.0
9.0
11.7
13.8
22.7
10.3
6.8
12.1
9.6
9.2
10.3
14.4
25.7
22.4
27.6
10.2
10.2
18.2
8.8
12.4
1839
1838
1820
1736
1700
Table 160: Line shares and the mean costs depending on the information available
The mean costs in the last row refer to the entire route.
The difference between scenario 1 and 2 is very small, because information on departures at
the local stop is only an advantage if thereby one is able to ignore a line with a longer journey
time in favor of a more appropriate line arriving shortly after. In this network, this case only
occurs with a low probability and only at stop B.
If the same information is already provided on board (scenario 3), the shares of the individual
lines already change considerably, the mean costs, however, only a little. The reason being,
that the most attractive transfer lines in this example do not depart from stop A.
Because of this, the expected remaining costs are then reduced when information on
departure times are not only provided for the local lines of a stop, but for all the lines of all stops
nearby (scenario 4). From the resulting relatively large set of possible lines, the passenger can
choose the line with the least remaining journey time. The effect becomes more clear if the
passenger can already make such a decision on board line 1 (Scenario 5). The mean costs
savings in this example equals 139 minutes - which means considerable 14 percent on this
path leg from A to destination.
6.9.6
470
PTV AG
The decisive factor is the assumption that, from the various options available, the passengers
will make their choice for the continuation of their journey at each stop on the basis of this
probability graph regardless of how they reached this stop.
Consequently, search and choice in the headway-based procedure are organized so that,
working backwards from each destination zone, all options are calculated to allow passengers
to move from the stops of the network towards the destination zone. The mean impedances of
the decision points for which a distribution has already been calculated are then used for the
iterative calculation of the distribution for more distant decision points.
In the course of this search, only such routes are maintained (this means only those paths are
loaded in the decision graph), which are positively assessed by the selected choice model. In
the case of passenger information, this means that a path at each traversed decision point is
probably the best option amongst all available alternatives. Similar statements apply for the
other choice models.
Optionally, all dominated paths can be singled out from these. A path is dominated by another
path if it applies to the same OD pair, uses the same sequence of time profiles (in the same
order), has the same start stop and end stop, yet has a longer total journey time (usually due
to the selection of less convenient transfer stops).
6.9.7
Headway
Bus 1
120 / 3 * = 40 min
40 min
Train
120 / 2 ** = 60 min
60 min
Route search
The case is, that passenger information on departure times exists and is also available on
board of the bus line. At route search, the procedure then determines two routes from A-Village
to X-City, if each of the two alternatives is with (even low) positive probability better than the
respective other one.
Probability becomes involved in that the wait time for the train in the case of a transfer is within
a range of between 0 and 60 minutes and no fixed transfer time has been assumed in advance.
PTV AG
471
If no extremely high transfer time penalty is used, some of the passengers will certainly use the
transfer option. This is because the train will leave (with a certain level of probability) only
shortly after the bus arrives and the passengers will thus arrive at their destination more
quickly.
Because the probability of obtaining an unfavorable connection in this case is significantly
higher, however, the majority of the passengers will continue their journey by bus.
The decisive factor is thus not only the mean wait time for the train in the example given, this
is 30 minutes but the complete range of possible wait times. Due to the existing passenger
information, each of the two routes thus receives precisely that portion of the demand that
corresponds to the chance of being the better of the two options.
Route choice
In order to determine a distribution in the example given, specific impedance parameters have
to be used. These are set as follows.
In this way, the impedances listed in table 162 are calculated for a passenger arriving at the
railway station on Bus 1 for the remaining route legs.
Route 1
Route 2
0 min
0 min
Run time
33 min
16 min
0 min
0 2 min = 0 min
1 2 min = 2 min
33 min
From the impedances Imp1 and Imp2, the following percentages P1 and P2 of the OD demand
(in this case: 90 trips) result and thus the absolute number of trips on both routes (M1 or M2).
This occurs as follows.
The decision as to which of the routes is more attractive depends on whether the random
variable Imp2 is greater or smaller than the constant variable Imp1. Because Imp2 is uniformly
distributed in the interval [18, 78[ and Imp1 is equal to 33, the probability for choosing Route 2
is thus 0.25 according to the formula below.
33 18 15
=
= 0.25
78 18 60
This means that 90 0.25 = 22.5 passengers decide to travel by train and 90 0.75 = 67.5
passengers to continue their journey by bus.
472
PTV AG
90
Station
X-City
23
67
B-Village
67
With any variation in the transfer penalty, this portion changes as shown in table 163. For other
impedance parameters, the same applies.
Transfer time penalty
Portion of Route 1
0 min
Portion of Route 2
0.717
0.283
1 min
0.733
0.267
2 min
0.750
0.250
5 min
0.800
0.200
10 min
0.883
0.117
The skim values for the relation from A-Village to X-City are shown in table 164. These values
are the mean skim data of both routes which weighted with the number of passengers are
summarized for the impedance parameters used here.
Route
Set
Pass. TWT
Pass. NTR
67.5
67.5 45 min
67.5 0 min
67,5 45 min
67,5 0
22.5
22,5 28 min
22,5 1
Total
90
3 667.5 min
168.75 min
3 836.25 min
22.5
3,667.5 = 90
= 40.75 min
168.75 / 90 =
1.875 min
3,836.25 = 90
42.625 min
22.5 / 90 = 0.25
Mean
Please pay particular attention to the transfer wait time of 7.5 minutes for Route 2. In this case,
the figure is not 60 / 2 = 30 minutes even though the train's headway is 60 minutes. This is due
to the fact that passengers will only take the train if the transfer wait time is short enough to
be precise, when this time (as seen above) is within a range of zero and 15 minutes. In all other
cases, there is no benefit in transferring. The 7.5 minutes transfer wait time in the choice of
PTV AG
473
Route 2 therefore represents a conditional expectancy value it is the mean wait time for those
passengers for whom Route 2 is in fact the best alternative.
6.9.8
Coordination
In Visum, the coordination can be used for the headway-based assignment. This is realized by
so-called coordination groups.
6.9.8.1
A coordination is defined between two or more lines to indicate that, for the passengers'
benefit, the trips of these lines are equidistant in terms of time on a shared route section. As a
consequence, the relevant line bundle is treated at the shared stops throughout the entire
procedure as a single line that operates with greater frequency. This results in a shorter mean
wait time than is the case with the (by default) assumed stochastic uniform distribution of the
relative position of the lines to each other.
A coordination group is a bundle of time profiles on a conjointly used passage. Two stops mark
the boundaries of the section. The significance of a coordination group lies in the calculation of
the mean wait time in the context of the headway-based assignment. In this assignment
procedure, it is usually assumed that the time interval between departures on different line
routes (strictly speaking: time profiles) is coincidental. With the aid of coordination groups, you
can display that certain line routes run in a rhythm of equal intervals to the advantage of the
passengers just like it is often the case in real life.
Note: In the timetable-based assignment, coordination groups bear no meaning as departure
times can be gathered from the timetable here. In contrast, the headway-based assignment
calculates with average wait times only. Coordination groups come into play when it ought to
be expressed that those wait times are shorter than those arising from a coincidental
arrangement of the line routes.
Please note that splitting up a line into two new lines, each with half the supply, does therefore
not lead automatically to the same result in calculation. It must not be assumed in advance
that a coordination exists. Coordinations have to be explicitly specified. The illustration 158
shows an example.
H e a d w a y H 1 = 2 0 m in
re d
r e d - b lu e
H e a d w a y H = 1 0 m in
b lu e
Headway H
= 2 0 m in
474
PTV AG
Considering only the red-blue line, a passenger arriving randomly has a mean wait time of 5
minutes precisely half the headway.
If this line is split up into a blue and a red portion without defining a co-ordination, a mean wait
time of 6:40 minutes results after the headway calculation. This is the expected value of the
offset to the next departure of one of the two lines and, depending on the relative position of
the two lines to each other, this offset can be somewhere between 0 and 20 minutes.
Defining a coordination indicates that the interval between departures of the red and the blue
line remains constant at 10 minutes. As in the initial situation, this results in a mean wait time
of 5 minutes.
6.9.8.2
Matched transfers
The transfer time between two lines at a stop is normally a combination of the transfer walk
time taken from the transfer walk time matrix (see User Manual, Chpt. 2.24.2, page 399) and
the random wait time for a trip of the successor line. This results from the fundamental model
assumption that passengers a priori have no information on the exact departure times of the
lines, but only know their in-vehicle times and headways.
In some cases, however, it is desirable to model that the transfer time between two lines is not
stochastic, but assumes a fixed value. This is particularly important in networks with longer
headways, in which the existence of coordinated connections is nevertheless assumed.
In this case, for a pair of time profiles at a stop, a so-called matched transfer can be defined.
Transfers from one time profile (see User Manual, Chpt. 2.24.2, page 399) to the other then
require precisely the specified duration each time (see User Manual, Chpt. 6.2.3.2,
page 1087).
6.9.8.3
For a passenger, a single line route with headway of 20 minutes means a mean wait time of 10
minutes. Whether the introduction of a second line route of the same headway means that the
wait time will be reduced to 50% depends on its concrete temporal position. A sequence like
8:00 8:02 8:20 8:22 - ... for example does not yield a noteworthy improvement.
If, however, two such line routes are coordinated, the headway-based assignment assumes
that the departures are of equal intervals and thus timed like this: 8:00 8:10 8:20 8:30 .... As a result, the average wait time is reduced to 5 minutes. Without coordination, all
positions in the timetable are considered equally probable. The expected value for the wait
time is then 6:40 minutes.
Coordination only acts on those stops (on the section marked by the start point and end point)
at which the coordinated time profiles actually stop. If only a subset of the coordinated bundle
stops at a stop, only the time profiles that stop are considered coordinated at that stop.
Note: The coordination of time profiles ends at the ToStop, that is, the arrival times of the time
profile are still coordinated at that stop but the departure times are not.
If there is an overlap between the coordination groups to be defined, only the first coordination
group of each time profile item is considered. In this case, a warning is triggered at the
beginning of the assignment.
PTV AG
475
6.9.8.4
For identical headways, the coordination's mechanisms of action is clearly defined. Since
coordination groups can be defined for arbitrary time profiles in Visum, however, there is not
always a natural definition of the aggregate headway.
The approach implemented so far, which corresponds with the procedure in the program VIPS,
is based on the assumption that the passengers can differentiate between the individual time
profiles in a coordinated bundle and also make their choice against attributes of the respective
time profile.
The new approach, which is realized in the program via the option Assume coordinated time
profiles to be undistinguishable, is based on the following algorithm. Ti are the headways of
the coordinated time profiles.
In a first step, the aggregate headway T for the bundle is set as follows.
T := 1 / (1 / T1 + ... + 1 / Tm)
This is the harmonic mean of the given Ti. The number of services corresponding to this
headway is equal to the sum of the number of services of the individual time profiles.
Example: T1 = 6, T2 = 7.5 (i.e. 10 + 8 services per hour) yields an aggregate of T = 10/3
which also corresponds to 18 services per hour.
For each time profile, the proportion of the total number of services is given by i = T / Ti.
This fraction is also used as the relative share of the demand within the time profile bundle,
i.e. pi := i. The aggregate impedance is again set to C := c1 p1 + + cm pm with ci =
impedances of the time profiles.
Using the standard algorithm (see "Route search" on page 471 and "Route choice" on
page 472), the virtual aggregate time profile m* with headway T and impedance C is
compared with the other time profiles
Model approach
Here, the general assumption is that the time profiles in the coordinated time profile bundles
are not distinguishable. The time profile attributes headway and impedance are irrelevant.
Instead, the headway is calculated with the focus on the number of services.
As a consequence, each time profiles proportion of the total number of services can be used
as demand share per time profile. Passengers that cannot differentiate between the different
time profiles of a time profile bundle will automatically board the first service available.
Therefore, the passenger volume of each contained time profile is proportional to the
alternative's number of services.
Furthermore, the aggregate impedance is defined as the weighted mean of the single time
profiles impedances, this time using the service frequency shares i as weights. This makes
sense because the resulting aggregate is the mean impedance of all services. For the
passenger, this is the expected impedance when boarding the first available service of the TP
bundle.
476
PTV AG
Example
The example illustrates the difference between the already existing approach and the new one:
For the undistinguishable approach, the aggregate headway T is equal to 6/7, i.e. only 46
seconds. The aggregate impedance is C = 22.77. This value is much larger than before since
the high-impedance time profile 1 plays a more significant role now.
6.10
TP
Impedance
Headw
ay
Distinguishable (Standard)
Undistinguishable
24
0.0166
0.7692
20
0.3366
0.1538
16
10
0.6466
0.0769
Timetable-based assignment
A search method is called timetable-based if all services of PuT lines are taken into account
with their precise departure and arrival times.
Timetable-based methods are suitable for assignments and the calculation of indicators, when
a line network plan and a detailed timetable are available for the PuT supply analyzed. They
take the coordination of the timetable into account and thus ensure very precise results of the
indicator data calculation.
The timetable-based method calculates connections for each OD pair. In the Search it is
assumed that the passengers have timetable information available and choose their access
time according to the departure on the first PuT line. During the search, the user can influence
the kind of connections found in different ways by means of search impedance. For the
connection search, two variants (branch & bound search and shortest path search) are offered
that represent the different compromises between the number of alternatives on the one hand
and the memory and computing time requirements on the other.
During preselection of connections, the connections yielded by the search algorithm are reanalyzed by means of general criteria as to whether some of them are of a significantly lower
quality and can thus be deleted.
During the choice, the demand is distributed to the remaining alternatives based on one of the
models described above. The independence of connections can be taken into account if
required.
6.10.1
PTV AG
Using the branch & bound option (see "Connection search using Branch and Bound" on
page 478), the procedure calculates all suitable connections throughout the entire analysis
period. This also includes the calculation of several connections with different impedances
(for example shortest time and minimum transfer connections) for a departure time. In the
case of a monocriterion shortest path search (see "Connection search using shortest path
search" on page 480), only one connection is calculated for each departure time, as this
477
6.10.2
reduces the memory and computing time requirements. The search can be influenced by
means of the search impedance definition.
Branch & Bound search is suitable for the analysis of a period (see "Connection search
using Branch and Bound" on page 478) - for example the whole day or several hours.
When performing a search at a specific time (e.g. in the case of a graphical route search),
the shortest path search is recommended (see "Connection search using shortest path
search" on page 480).
The actual transfer wait time, and thus the coordination of the timetable, is taken into
account.
All indicators in the analyzed time interval can be calculated.
The decision model for the connection choice (see "Connection choice" on page 484)
models the actual decision behavior of the passengers realistically, because a passenger
usually has some information on the PuT supply (connection search) and then makes his
choice from the connections offered (connection choice).
Connection search
Two methods are provided for the connection search: Shortest path search and Branch &
Bound.
478
A search impedance is used in order to evaluate the quality of connections. For all (partial)
connections found in the search, the search impedance is calculated using the following
equation:
SearchIMP = JRT FacJRT + NTR FacNTR + TSys-Imp FacTSys-Imp + VehJ-Imp FacVehJImp
Besides the journey time and the number of transfers, also TSys-specific penalties are as
TSys-Imp among others. That is, how common distance-based fares can already be
considered during the search. The complete Visum fare model will take effect during the
connection choice. However, this is no restriction, since the approximate fare calculation
during the search is sufficient for the distinction between reasonable routes and useless
ones.
Via VehJ-Imp, also the vehicle journey-specific impedance is added. It results from two
freely selectable attributes of the vehicle journey items as boarding supplement and as
general discomfort term. In this way, individual vehicle journeys can be favored or
penalized.
(Partial) connections to a destination or intermediate node are evaluated and compared
with any other (partial) connection to the same point. Then it can efficiently be decided
which branches of the search tree can be continued (branch) and which have to be cut
(bound) (see "Dominance" on page 479 and "Bounding" on page 479).
It is possible to specify an upper limit for the number of transfers in a connection.
PTV AG
Dominance
Pairwise comparisons are helpful for the identification of useless connections.
If a connection is in no respect more appropriate than another connection in the same temporal
position, then this connection is called dominated and will be discarded. This means in detail:
A connection c dominates a connection c, if
To compare two connections without defined temporal position (that means: without path legs
of the 'PuT line' type) the first rule is changed to the following: Journey time (c) journey time
(c).
Example:
Connection 1
Connection 2
Connection 3
Temporal position
6:00 - 7:00
6:00 - 7:10
6:10 - 7:20
Connection 4
5:30 - 7:20
Number of
transfers
SearchImp
4,000
4,200
4,300
5,400
Dominance
---
Dominated by
conn. 1
---
---
Bounding
Besides the temporal position, the following rules are applied to exclude connections which
differ considerably from the optimum in one or several criteria:
A (partial) connection is deleted, if
Search impedance of the connection > minimum search impedance factor + constant, or
Journey time of the connection > minimum journey time factor + constant, or
Number of transfers of the connection > minimum number of transfers + constant.
As a matter of principle, connections which are optimal in one of the three dimensions will not
be deleted in this step, even if they violated the rule of another dimension.
PTV AG
479
Determination of all possible start times for trips which originate in traffic zone i. The start
times result from the departure times of PuT lines at stops which can be reached from zone
i via a connector.
In the example, the start times correspond with the departure times of bus line 1 from AVillage (6.10, 6.55, 7.25), because A-Village is only serviced by one bus line and an access
time of 0 minutes is assumed.
For every start time one of the two following steps is executed.
Either a monocriterion shortest path search is carried out which searches for the "best" path
from traffic zone i to traffic zone j starting at the given time. The search procedure identifies
the path with the lowest impedance as the best path. The impedance of the path is
measured in minutes and is a linear combination of journey time and number of transfers.
It consists of the following time components.
Access time [min]
In-vehicle time [min],
Transfer walk time between two transfer stops [min],
Transfer wait time [min]
Egress time [min]
Number of transfers [-] transfer penalty [min] (adjustable).
This lowest impedance path represents a connection, because the used sequence of lines
and the exact departure and arrival times at boarding stop, transfer stops, and alighting
stop are known.
480
Or the connection with the minimum journey time (so-called bicriterion shortest path
search) is calculated for each permitted number of transfers (for all integer values 0 and
max. number of transfers). If the calculation returns identical journey times for different
numbers of transfers, the program only stores the connection with the lowest number of
transfers (dominance).
PTV AG
6.10.3
Connection preselection
The preselection of connections compares and evaluates all found connections. This includes
the check, whether a connection could be replaced by a more suitable one and thus can be
deleted. Only convenient connections are offered to the passengers for the connection choice.
In order to identify inconvenient connections, the following exclusion rules are applied in turn.
Search impedance of the connection > minimum search impedance factor + constant, or
(no limitations; just branch & bound)
Journey time of the connection > minimum journey time factor + constant
(unless the connection is optimal with respect to the number of transfers)
Number of transfers of the connection > minimum number of transfers + constant
(unless the connection is optimal with respect to the journey time)
6.10.4
Notes
PTV AG
PuT-Aux time
The time spent in a transport system of the PuT-Aux type enters the PJT as a separate
value and can be weighted by any transport system attribute. It is furthermore required as
a skim value.
Modeling Bonus and Malus
The in-vehicle time can be multiplied by an attribute of the vehicle journey items (and the
PuT-Aux time by a TSys attribute respectively) in order to model the vol/cap ratio (for
example the availability of seats) or other aspects of usability (for example the level of
comfort).
481
Number of transfers
The PuT line TSys and the PuT-Aux TSys enter the calculation of the number of transfers
on a par.
Number of operator changes
Operator changes cannot occur due to PuT-Aux path legs.
With A = 0.5 and E = 1, the origin wait time corresponds to half the mean headway.
With A = 1.5 and E = 0.5, a root function is created which assumes that passengers have
better knowledge of timetables in the case of low service frequency.
The origin wait time is the same for all connections of an OD pair. Including them in the PJT is
therefore just like a constant supplement. The OWT output as a skim matrix, however, can be
important for the network analysis.
As an argument, the actual transfer wait time t is set, which is the time that passes between
the arrival of the passenger at the stop point and the departure of the vehicle journey.
The weighted wait time f(t) is thus defined as
f(t) = t, if t t1.
t1 and c result from the boundary conditions f(t1) = t1 and f'(t1) = 1, that is from the
differentiable composition of both parts of the function at position t1.
Essential is: t0 is the transfer wait time considered ideal. For the extended transfer wait
time, this variable may depend on the required walk time and thus needs to be
parameterized as follows:
Factor times walk time plus constant
Due to the polynomial shape of f, the weighted wait time f(t) is the least precisely at the position
t = t0.
Around t0, f(t) increases symmetrically.
With increasing t, function f(t) approaches the linear asymptote t.
482
PTV AG
Example
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
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
TaiEarly = amount of time that connection i departs earlier than desired for departure
interval a ( time series); = zero, if i departs within a or after a.
T
early
desired dep. time actual dep. time if actual dep. time < desired dep. time
else
0
TaiLate = amount of time that connection i departs later than desired for the departure
interval a ( time series); = zero, if i departs within a or before a.
T
late
actual dep. time desired dep. time if ( actual dep. time > desired dep. time )
else
0
PTV AG
483
Departure
05:30 a.m.
Tearly
30
Tlate
30
6:00
06:40 a.m.
7:00
07:10 a.m.
10
10
6.10.4.3 Fare
If a zone-based ticket type is used, PuT-Aux path legs are disregarded. Distance-based ticket
types are evaluated analogously to the TSys of PuT lines, because fare points can also be
assigned to PuT-Aux (see "Revenue calculation using the fare model" on page 636).
6.10.5
Connection choice
The connection choice distributes the demand of a relation onto the found connections. In
order to do this, the connection impedances are calculated; they include the perceived journey
time PJT, the fare and the temporal utility of a connection (see "Impedance and Perceived
journey time PJT of a connection" on page 481). For the distribution models, these
impedances serve as an input for calculating the shares of the connections in the travel
demand (see "Distribution models in the assignment" on page 308). The independence can
also be included in the distribution rule, if required (see "Independence of connections" on
page 485).
early
Fac
early
+ T i
late
Fac
late
Optionally, each skim value which goes in the impedance can be individually Box-Cox
transformed. This does not affect the actual choice model. Any utility function can thus still be
applied to the total impedance even when using the Box-Cox transformation.
The impedance calculation is not linked to the actual connection choice, that is, even when
calculating the Box-Cox transformation, Logit does not necessarily have to be used. Any other
utility function can be selected instead.
The impedance calculation is as follows:
For i = 1, ..., n are xi the different path attributes. Here, the first m of them without restrictions
are to be Box-Cox-transformed (namely each into parameter i). i stands for the respective
coefficient. Then the following applies
m
Ri =
484
i = 1 i fi ( xi ) + i = m + 1 i xi
PTV AG
where
i
x 1
fi ( x ) =
log x
i 0
i = 0
By including this impedance in one of the distribution models Kirchhoff, Logit, Box-Cox or
Lohse (see "Distribution models in the assignment" on page 308), Visum then determines the
utility of a connection in a given time interval and ultimately its percentage of the demand for
this interval. The independence can also be included in the distribution rule, if required (see
"Independence of connections" on page 485).
As before, the proportion of a connection i of the total demand is calculated as follows:
g ( Ri )
p i : = -------------------- g ( Rj )
j
Here, g is the selected utility function (always antitonic). In the case of Logit thus g(x) = e-bx
applies.
Notes: As can be seen from the definition, when using the Box-Cox transformation for xi
generally xi 0 needs to apply. In case of i = 0, even xi > 0 needs to be true. If this rule is
violated during the run time, the assignment is terminated with an error message.
Due to a Box-Cox transformation or caused by negative coefficients, Ri itself can be negative.
In that case, only the Logit utility function can be used, otherwise the assignment is
terminated with an error message.
The temporal proximity of the connections with regard to departure and arrival
xi ( j ) =
PTV AG
485
x ( j)
wi ( j ) := 1 i 1 c min 1,
sx
s y sz
s +
s y := y
s y
where
if
if
yi ( j ) 0
yi ( j ) < 0
s +
s z := z
s z
and
if
if
zi ( j ) 0
zi ( j ) < 0
s > 0 are internal parameters for controlling the influence of the three values. c is a constant that
controls the absolute effect of the second value. It is user-defined within [0.1].
The first value describes the temporal proximity of i and j. If the times are the same, then xi(j)
= 0, so that this value is equals to 1. If the time difference is xi(j) sx, the value becomes zero
and wi(j) = 0 also applies. Thus, sx is the maximum temporal distance in which j can effect i.
The second value lies between 1 (in case of absolute equality in the context of yi(j) = 0 and zi(j)
= 0) and 1 - c (when there is a significant difference between i and j). As with sx, sy+ or sy- is the
maximum temporal advantage or disadvantage of i, in which j can possibly have an impact.
With regard to the fare, the same applies to sz. The default setting leads to the following relation
of sy- = 2sy+ and sz- = 2sz+. As a result of this asymmetry, in the case of two connections with
temporal proximity, the better is favored, because its influence on the worse alternative is
greater than vice versa. In principle, users should always specify Independency coefficients for
high or low quality in the form of IndCoeffQualityHigh (ECQH) < IndCoeffQualityLow (ECQL).
When violating this rule, a warning appears at the start of the assignment (or an error message
in the window).
Overall, the following applies:
sx = min (2 mean wait time of a random passenger between the first and the last departure, maximum
time slot)
sy+ = ECQH mean PJT in the total assignment period
sy- = ECQG mean PJT in the total assignment period
sz+ = ECQH mean fare in the total assignment period
sz- = ECQL mean fare in the total assignment period
Note: Only the temporal positions, the PJT values and the fares are compared; service trip
item data is not evaluated.
If no fares are available (i.e. FPi = 0 for all i), then sz = 1 is set.
The attribute independence of a connection is now defined as follows:
INDi :=
n
wi ( j )
j =1
=
1+
1
n
wi ( j )
j =1, j i
486
PTV AG
This linear dependence on the independence attribute ensures that k simultaneous, identical
alternatives are treated as a single connection. According to the definition of IND, the
independence of each of such k alternatives is precisely 1 / k (if no other connections with
temporal proximity have an effect). As a result, the total of its weights in the distribution formula
is equal to the weight of a single, non-multiplied connection of the same kind.
=4
Logit
= 0.25
Box-Cox
= 1 and = 0.5
Lohse
=4
PJT formula
IMP formula
IND parameter
c=1
Table 166: Procedure parameters for the comparison of the distribution models
Connection data that differs from the respective previous example is highlighted bold in
table 167 to table 171. All assignment shares are given as percentages.
Lohse
Box-Cox
Logit
Kirchhoff
Fare
Box-Cox
Arr
Logit
Dep
PJT
No.
Connection data
10
30
20
3.00
33.3
33.3
33.3
33.3
33.3
33.3
33.3
33.3
30
50
20
3.00
33.3
33.3
33.3
33.3
33.3
33.3
33.3
33.3
50
70
20
3.00
33.3
33.3
33.3
33.3
33.3
33.3
33.3
33.3
PTV AG
487
Lohse
Box-Cox
Logit
Kirchhoff
Fare
Box-Cox
Arr
Logit
Dep
PJT
No.
Connection data
10
30
20
3.00
25
25
25
25
33.3
33.3
33.3
33.3
30
50
20
3.00
25
25
25
25
16.7
16.7
16.7
16.7
30
50
20
3.00
25
25
25
25
16.7
16.7
16.7
16.7
50
70
20
3.00
25
25
25
25
33.3
33.3
33.3
33.3
Lohse
Box-Cox
Logit
Kirchhoff
Box-Cox
Arr
Logit
Dep
PJT
No.
Kirchhoff
Connection data
10
30
20
3.00
25
25
25
25
32.7
32.7
32.7
32.7
30
50
20
3.00
25
25
25
25
17.3
17.3
17.3
17.3
32
52
20
3.00
25
25
25
25
17.3
17.3
17.3
17.3
50
70
20
3.00
25
25
25
25
32.7
32.7
32.7
32.7
Table 169: Example 3 Identical pair of connections with high temporal proximity
Logit
Box-Cox
Lohse
30
Kirchhoff
10
Box-Cox
Arr
Logit
Dep
20
3.00
25.9
26.7
26.2
25.1
31.9
32.6
32.2
31.2
PJT
No.
Kirchhoff
Connection data
30
50
20
3.00
25.9
26.7
26.2
25.1
20.2
20.7
20.4
19.8
32
47
20
3.30
22.3
19.8
21.3
24.6
16.0
14.1
15.2
17.8
50
70
20
3.00
25.9
26.7
26.2
25.1
31.9
32.6
32.2
31.2
Table 170: Example 4 Similar pair of connections with high temporal proximity (connection 3 now
includes transfer)
Lohse
Box-Cox
Logit
Kirchhoff
Fare
Box-Cox
Arr
Logit
Dep
PJT
No.
Kirchhoff
Connection data
10
30
20
3.00
23.5
21.9
22.8
24.6
26.5
24.9
25.8
27.7
30
50
20
3.00
23.5
21.9
22.8
24.6
20.1
18.9
19.6
21.0
Table 171: Example 5 - Differing pair of connections with moderate temporal proximity
488
PTV AG
Connection data
32
44
17
3.30
29.6
34.3
31.5
26.1
26.9
31.4
28.7
23.6
50
70
20
3.00
23.5
21.9
22.8
24.6
26.5
24.9
25.8
27.7
Table 171: Example 5 - Differing pair of connections with moderate temporal proximity
The fact that, without IND being applied the connections 1, 2 and 4 have the same number of
passengers in all cases shows, that the interactions between different alternatives ought to
be taken into account to a higher degree in this case. It becomes apparent that then better
results are achieved with all distribution models.
Dep.
JRTi
TWTi
NTRi
6:10
a.m.
28 min
3 min
28 + 3 2 + 1 2 = 36
6:10
a.m.
45 min
0 min
45 + 0 2 + 0 2 = 45
06:55
a.m.
45 min
0 min
45 + 0 2 + 0 2 = 45
7:25
a.m.
28 min
8 min
28 + 3 2 + 1 2 = 36
7:25
a.m.
45 min
0 min
45 + 0 2 + 0 2 = 45
FacTWT = 2, FacNTR = 2
Table 172: Result of connection search (transfer penalty 10 min, parameter file TIMETAB1.PAR)
The table 173 shows the impedances of the connections. As T depends on the desired
departure time of the passengers, different impedance values result for the various time slices
of travel demand. Thus, the impedances of the first two connections are lower in the first
interval, whereas those of the last three connections are lower in the second interval. The
impedance definition is set in such a way, that the following applies:
Ria = PJTi 1.0 + Tiaearly 1.0 + Tialate 1.0
PTV AG
489
Conn. i
Dep.
Ti1
6:10 a.m.
Ti2
Ri1
Ri2
5:30-6:30
6:30-7:30
5:30-6:30
6:30-7:30
0 min
20 min
36 0 = 36
36 20 = 56
6:10 a.m.
0 min
20 min
45 0 = 45
45 20 = 65
6:55 a.m.
25 min
0 min
45 25 = 70
45 0 = 45
7:25 a.m.
55 min
0 min
46 55 = 101
46 0 = 46
7:25 a.m.
55 min
0 min
45 55 = 100
45 0 = 45
Table 173: Temporal distances T and impedances R of the connections for the two analyzed intervals of
travel demand
Then, a distribution rule (here Kirchhoff with = 3) is used to calculate the shares Pia which are
allocated to the individual connections. The independence is ignored in this formula. As shown
in table 174, all five connections are assigned non-zero percentages of the travel demand per
time interval.
Conn. i
Dep.
Pi1
Pi2
5:30-6:30
6:30-7:30
Vehicle
Vehicle
journeys Mi1
5:30-6:30
journeys Mi2
6:30-7:30
Vehicle
journeys
5:30-7:30
6:10
a.m.
57%
13%
30 0.57 = 17
60 0.13 = 8
25
6:10
a.m.
30%
8%
30 0.30 = 9
60 0.08 = 5
14
6:55
a.m.
7%
27%
30 0.07 = 2
60 0.27 = 16
18
7:25
a.m.
3%
25%
30 0.03 = 1
60 0.25 = 15
16
7:25
a.m.
3%
27%
30 0.03 = 1
60 0.27 = 16
17
100%
100%
30
60
90
490
PTV AG
A_village
90
X_city
Station
41
B_village
49
49
Illustration 159: Network volume for timetable-based assignment (parameter file timetab1.par)
6.10.6
They are considered in the timetable-based assignment and also via the menu Graphic >
Shortest path.
They are convenient for modeling inferior transport supply without timetables. These are for
example
Park & Ride
Local public transport with dense headway within a network that is otherwise timetablebased
Taxis
They are only relevant on links and turns. By defining permissions of PuT-Aux TSys to
these objects, the subnetwork which is enabled per PuT-Aux TSys is defined. This
information is not relevant for connectors, nodes or stop points.
Alike PuT-Walk TSys, PuT-Aux TSys are permitted for PuT modes. In case of assignments of
demand segments of such modes, passengers can use path legs with the PuT-Aux, too,
namely those between two nodes that are connected by links for which the PuT-Aux transport
system is permitted. These nodes need to be accessed by walk links however, or be directly
connected to a zone or stop area.
During the assignment, a change to a PuT-Aux path leg counts as a transfer.
The extended modularized procedure can be used for example, to export and import fares
(see "Opening of the timetable-based assignment: Export/Import of connections" on page 492)
Pre-calculation of path legs
The set of PuT-Aux TSys permitted in an assignment directly affects the path legs to be
calculated because every start node of PuTAux paths represents a potential target of PuT walk
links. This is taken into account when pre-calculating the walk links and PuT-Aux paths.
PTV AG
491
Analogous to walk links, a path leg is created for each PuT Aux path. In any case, the trivial
PuT-Aux transfers at nodes appear as individual path legs in any case. Path legs are sorted
separately by type: PuT-Line, PuT-Walk, and PuT-Aux.
Analogous to the reference to the index of the first walk link path leg for an origin, a reference
to the index of the first PuT-Aux path leg is logged.
For path legs with PuT-Aux TSys, too, journey time, number of transfers and the impedance by
transport system are clearly defined. In particular the link attributes Imp/km, Imp/FarePoint
and Imp/AddVal are available for PuT-Aux TSys.
6.10.7
492
PTV AG
Preprocessing
(3)+(4)
Search
Wege from
Paths
aus
assignmentoder
Umlegung
or
aus Datei
from
file
(2a)
Assessment
(1)
Paths
belastete
with volumes
Wege
from
aus Datei
file
Path
Wegeexport
export without
ohne
volumes
Belastungen
(2b)
Network volumes
The illustration 160 indicates when paths can be read in from file or output to file in the
timetable-based assignment. The following options are provided:
(1) External choice / Connection import
Connections with volumes are imported from file and stored like an assignment result,
therefore as paths and network volumes (see "Use case (1) External choice / Connection
import" on page 493).
(2) Connection export
In order to provide the external choice with data, connections can also be exported. You
can do so with or without volumes and optionally choose fare points, fares or user-defined
attributes (see "Use case (2): Connection export" on page 494).
(3) Using existing connections for the search
Instead of the connection search in Visum, the procedure can also use existing
connections as a basis. These connections can be the result of a previous assignment or
be stored in a connection file. This feature is of major interest if the search parameters have
not been modified, but a choice is to be carried out with different settings (see "Use case
(3) Using existing connections for the search" on page 495).
It is possible, but not necessary, to deactivate the option Calculate assignment for the
connection export. As for a pure skim calculation, neither paths not volumes are stored in this
case. Existing assignments of the selected demand segments are retained.
PTV AG
493
In the chart in illustration 160 this is scheduled above the network loading. The paths contained
in the connection file are converted into the internal data structure and therefore no longer
differ from paths calculated within Visum. Thus, connection import has the same effect as an
assignment.
This means the following:
By default, the program deletes assignment results for demand segments to which
connection import is applied.
From the imported connections, paths are generated in Visum according to the current
setting of the option Save paths (as connections / as routes / do not save) (see User
Manual, Chpt. 6.1.1.2, page 1072).
The procedure setting Save paths as connections includes an option that allows you to
sum up the volumes of existing connections.
At the same time the path volumes read in are transferred into network volumes.
If the volumes of a demand segment that has been selected for the import are to be saved
with another demand segment according to the current general procedure settings, then
this parameter will be reset to the default (Do not save with a different demand segment).
For fare calculations in the context of the external choice, the option with fare points has to
be enabled since the fare is mostly based on the number of fare points per path leg of the
connection.
For connection export without volumes the following assignment parameters are relevant:
All other parameters are only effective if an assignment is actually performed, a skim matrix
stored or a connection export carried out.
494
PTV AG
6.10.7.3 Use case (3) Using existing connections for the search
At the beginning of the assignment you can re-use existing connections instead of a complete
connection search calculation. This will significantly speed-up the assignment and allows for
subsequent usage of external tools for the connection search.
The import can use data from various sources:
Once the import is finished the assignment will continue in the same way as after the internal
connection search. Especially the source does not have an impact on the connection choice
(see "Connection choice" on page 484).
Imported connections have preset times of arrival and departure which depend on the
assignment time interval that was set for their calculation. For the import, you can modify the
assignment time interval. In this case the temporal distance of the connections from the new
assignment time interval is DeltaT in the impedance as usual. In general this ensures, that
there is almost no demand for connections which are far outside. And they do not have a
significant impact on the skim calculation. Please note, that the skim service of frequency,
however, always regards the absolute number of connections not regarding their temporal
position. For this skim, identical assignment time intervals are recommended for the export and
import of connections.
PTV AG
495
496
PTV AG
{
TSys.Code (string)
}
NumTimeProfiles (4 byte-integer)
for each contained TimeProfile in key order:
{
Line.Name (string)
LineRoute.Name (string)
Direction.Code (string)
TimeProfile.Name (string)
}
NumUserDefinedAttributes (4 byte-integer)
for each contained UserDefinedAttribute:
{
ID (string)
ShortName (string)
LongName (string)
Comment (string)
ValueType (4 byte-integer)
HasDefaultValue (1 byte-integer)
DefaultValue (8 byte-real)
MinimumValue (8 byte-real)
MaximumValue (8 byte-real)
NumDecPlaces (4 byte-integer)
MaxStringLength (4 byte-integer)
DefaultStringValue (string)
}
for each contained OD relation in key order:
{
SourceZoneNo (4 byte-integer)
DestZoneNo (4 byte-integer)
for each contained Connection:
{
ConnectionDepartureTime (4 byte-integer)
NumLegs (1 byte-integer)
for each contained ConnectionLeg in logical order:
{
DepartureTime (4 byte-integer)
LegIsPuTLine (1 byte-integer)
if LegIsPuTLine
{
TimeProfileIndex (see above) (4 byte-integer)
FromTimeProfileItem.Index (2 byte-integer)
ToTimeProfileItem.Index (2 byte-integer)
}
else // 2nd case, leg is of type PuTAux
{
TSysIndex (see above) (4 byte-integer)
FromNodeNo (4 byte-integer)
ToNodeNo (4 byte-integer)
}
if ContainsFarePoints (4 byte-integer)
{
NumFarePoints (4 byte-integer)
}
if LevelOfFareInformation = 2
{
if(FaresForEachDemandSegment){
for each contained DemandSegment in key order:
{
LegFare (8 byte-double)
}
}
else {
LegFare (8 byte-real)
}
PTV AG
497
}
}
for each contained DemandSegment in key order:
{
Volume (8 byte-double)
}
if LevelOfFareInformation = 1
{
if(FaresForEachDemandSegment){
for each contained DemandSegment in key order:
{
ConnectionFare (8 byte-double)
}
}
else {
ConnectionFare (8 byte-real)
}
if ContainsConnectorNodes
{
FromNodeNo (4 byte-integer)
ToNodeNo (4 byte-integer)
}
for each contained UserDefinedAttribute:
{
HasValue (1 byte-integer)
if HasValue
{
Value (1 byte-integer/4 byte-integer/8 byte-double/string)
}
}
}
-1 (4 byte-integer)
}
-1
If transfer walk links are used between two PuT path legs, these are not contained in the
file. They result from the beginning and end of the path (zone or stop area) and the TSysSet
of the assignment.
In contrast to the internal connection search it will not be checked whether the PuT vehicle
journey sections used in the connections read from file are active.
498
The attribute values of a connection are saved in the same sequence as the attributes are
defined in the header.
The values permitted for ValueType correspond to those listed in the COM documentation
(cf. 2.1 INetObjCollection: AddUserDefinedAttribute). Formula attributes must not be
defined in the connection file. The corresponding data types are listed in the table below.
PTV AG
Identifier
Numeric value
Data type
ValueType_Int
4 byte-integer
ValueType_Real
8 byte-double
ValueType_String
string
ValueType_Duration
4 byte-integer
ValueType_TimePoint
4 byte-integer
string
ValueType_Filename
ValueType_Bool
1 byte-integer
ValueType_LongLength
12
8 byte-double
ValueType_ShortLength
13
8 byte-double
ValueType_StringLong
62
string
ValueType_LongDuration
165
4 byte-integer
6.10.8
Capacity restriction
By default, the timetable-based assignment determines a connection's attractiveness without
taking the demand into account. Accordingly, the demand is distributed onto possible
connections without consideration of the vol/cap ratios of these connections. Regarding also
the vol/cap ratio can return those connections as attractive alternatives which in the standard
case seemed to be not attractive. Thus, the enhancement with this criterion might change the
set of possible connections.
Basically, neglecting the capacities is a simplification, which unsatisfactorily reflects reality in
highly loaded public transport systems. Capacity restrictions in practice can take effect in
different ways:
PTV AG
Absolute vehicle capacity: The vehicle can hold only as many passengers as preset by its
capacity.
499
Discomfort in the vehicle: Passengers feel rather uncomfortable when travelling in a heavily
loaded vehicle. This effect will increases if all seats are occupied.
Discomfort outside of the vehicle: Passengers feel rather uncomfortable when transferring
at highly frequented stops. Besides unpleasant effects due to overcrowding also delays
may occur.
The timetable-based procedure's capacity restriction aims to model possible discomfort for
passengers in the vehicle. This approach approximately includes the fact that certain quantities
of the passengers have to use different connections if the vehicle capacity is saturated.
Exceeding the vehicle capacity is not prevented, however. Capacity-restricting effects at stops
are not regarded.
500
PTV AG
9. Various measures are calculated and returned which describe the distance from the
balanced state.
10. The termination conditions are verified. The procedure will be cancelled, if one of the
criteria is satisfied, otherwise the calculation will continue with step 5.
Supplementary remarks about the modified procedure:
During the choice, vol/cap ratio-depending impedances are added to the other impedance
components, i.e. they also go into the skim Impedance.
Also connections can be exported in combination with the capacity restriction. If
connections are exported without volumes, the export will start after the second search is
finished. If connections are exported with volumes, the export will start after the final choice.
Skim matrices and other output data will be calculated after the final choice.
Taking the capacity restrictions into account causes further restrictions with regard to three
points:
The optional second search is only possible with the Branch & Bound method.
If volumes are shifted between connections, the calculation of relevant skims will not take
time interval-specific volumes into account. This notably means that neither the skim
Adaptation time nor the skim Extended adaptation time can be calculated and output if
this option has been selected. Since the volumes are not directly derived from the choice
model if volumes are shifted between connections, even the skim Utility cannot be
calculated. For the skim Impedance, the DeltaT portion (which is the difference between
desired departure time interval and actual departure time) cannot be calculated.
Information on the calendar day level is neglected, since just a single vol/cap ratio is
determined per vehicle journey item. In reality, however, vehicle journeys could actually run
on several valid days, and their capacities and volumes might differ. Thus the applied vol/
cap ratio definition represents a simplification of the information provided with the Visum
data model, if a calendar is used.
Volume v ( AP )
A v = -------------------------------Capacity v
The capacity v corresponds to the value of the attribute, which has been selected by the user
for the capacity of a vehicle journey item. The pre-set default amounts across all vehicle
journey sections, which service the vehicle journey item without regard to the calendar day.
Thus the volume of a vehicle journey item sums up from the volumes of all connections using
this item:
PV =
PV
Vwith v V
Path legs covered with PuT-Aux are not regarded for the vol/cap ratio-dependent impedance
calculation.
PTV AG
501
1 S v = ----------------------a
1 + b Av
The user has to set the parameters a and b, and Av is the vol/cap ratio.
The expected standing minutes of a connection V correspond to a volume-dependent
impedance and result from adding the product of standing probability and run time across all
vehicle journey items of the connection:
:W v =
S v run time v
vV
2
Wv = r + Av + Av + A3 , l < A < l
1
v
2
v
Av l2
c,
The parameters a, b, c, l1 and l2 have to be entered by the user, Av is the vol/cap ratio of vehicle
journey item v. Thereof, the parameters r, , and result due to the function which can be
constantly differentiated here l1 and here l2.
Thus, the impedance of a connection V is calculated as follows:
WV =
v V Wv run timev
W V = max ( 0,a A v + b )
a and b are user-defined parameters, Av is the vol/cap ratio of a vehicle journey item v.
502
PTV AG
WV =
v V Wv run timev
Exponential smoothing
According to this formula, the smoothed vol/cap ratio-dependent impedance of connection V in
iteration i is derived from both the calculated impedance and the smoothed impedance of the
previous iteration:
V, i
smoothed
= a W V , i 1 smoothed + ( 1 a ) W V, i
V, i
smoothed
i
1
= ----------- W V, i 1 smoothed + ----------- W V, i
i+1
i+1
P v, i
A v, i = ----------------------- ( = : A v, i out )
Capacity v
The smoothed vol/cap ratio of a vehicle journey item in iteration i is derived from the calculated
and the smoothed vol/cap ratios of the two previous iterations:
formula
A v, i 2
PTV AG
smoothed
describes
A v, i 1
the
and
interpolation
A v, i
smoothed
in
the
event
of
different
signs
for
A v, i .
503
A v, i in = A v, i smoothed
and
A v, i out = A v, i
etc.
If both terms have the same sign, an extrapolation will be performed. Using the same formula
slows down the convergence for the extrapolation, thus the following formula is used in this
case (smoothing with constant factor 0.5):
A v, i smoothed + A v, i
A v, i smoothed = -----------------------------------2
The smoothed vol/cap ratios are then regarded by the impedance calculation within this
iteration and by the final impedance calculation.
For a network with smoothed vol/cap ratios of vehicle journey items it cannot be assumed, that
a path set can be generated which could generate the corresponding volumes.
P V, V'
PvB is the volume of connection V before shifting, W is the set of possible alternative
connections. The function d is defined as follows:
504
PTV AG
abs ( t t V )
d V ( t ) = 1 -------------------------, else
c ESm V
c and are user-defined parameters. This function has the effect, that connections which are
outside of a tolerance in terms of time are not regarded as alternatives. For permitted
connections, however, the readiness to change connections (alternating standby) increases
with an alternative's decreasing temporal distance from the original connection.
The diagram below shows an example of the function d for a connection V with
ESm V
= 5min
and c = 10:
PV =
P V', V
V'
Shifting volumes between connections also means new volumes for all vehicle journey items.
This method does not take the independence of connections into account.
Note: Optional shifting of volumes between adjacent connections is only provided with the DB
impedance function.
PTV AG
505
1
GapEuclidi = ---- ( W V, i smoothed W V, i ) 2
N V
1
GapAbsolute i = ---- W V, i smoothed W V, i
N V
1
GapEuclidi = ---- ( Al v, i smoothed Al v, i ) 2
N V
1
GapAbsolute i = ---- Al v, i smoothed Al v, i
N V
6.11
The calculated value is derived from the assignment or the network model.
The observed value may be count data or measured data.
506
PTV AG
Any numeric input and output attributes of the following network objects can be selected:
Links
Nodes
Turns
Main nodes
Main turns
Lines
Line routes
Screenlines
Time profiles
Paths
Prerequisite is, that the observed values must be >0 for the selected network object type.
You can select which objects you want to include in the assignment analysis. There are three
possibilities:
For the assignment analysis, as an option, you can consider user-defined tolerances for userdefined value ranges of the calculated attribute.
The quality of the correlation can be determined and issued in two ways:
For the output, the data model of the network object types above has been supplemented with
the calculated attribute Assignment deviation (AssignDev) of type real. Alike all other Visum
attributes, the attribute can be graphically displayed and issued in lists of the respective
network object.
In addition, VISUM calculates various indicators (per group or collectively) that can be issued
in a list or in a chart.
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
The table 175 shows the calculation rules for the output attributes of the assignment analysis.
The following applies to the formulas:
Z
U
N
PTV AG
507
AbsRMSE
Abs RMSE
( ) = (Z i U i )2
i =1
N1 2
Intercept
Intercept
GEH (i ) =
(Z i U i )2
(Z i + U i ) 2
------------------------------ Tolerance ( U )
Ui
NumObs
Number of observations
NumClass
Number in class
ClassValue
Corr
MeanAbsE
( a ) =
MeanObs
1
Abs(Zi U i )
N
1
Zi
Table 175: Calculation rules for the output attributes of the assignment analysis
508
PTV AG
MeanRelE
( p ) = Abs(ZZi U i )
R2
Coefficient of determination r2
Cf. Excel function RSQ
RelRMSE
(Z i U i )2
Zi N
(N 1)
StdDev
Standard deviation
Slope
Table 175: Calculation rules for the output attributes of the assignment analysis
6.12
Boarding stop of passenger trip where passenger enters the survey line, which means
where the passenger is interviewed by the survey personnel,
Alighting stop of passenger trip where passenger will leave the survey line,
Origin and destination of the passenger trip.
After reading passenger data from file, it has to be verified and completed, if necessary. Also
the time of departure from either the boarding stop or the origin terminal of the survey line have
to be recorded in a questionnaire.
The Visum add-on Passenger onboard survey contains the following basic functions.
PTV AG
509
Direct assignment
Assignment of the survey data records (calculating network volumes from path volumes),
optionally OD matrices and skim matrices can be generated (see "Assignment of survey
data" on page 519).
Note: Subsequently, indicator data on path level (by survey data record) is automatically
provided in the PuT paths list.
After direct assignment of the survey data, the full range of the Visum functionality for analysis
and display of results is available, e.g. flow bundle display (see "Interactive analyses" on
page 697) or PuT operating indicators (see "PuT operating indicators" on page 605).
6.12.1
Survey line
Succeeding line
Dest. terminal
Line i
Origin terminal
Line i
OriginStop
1st Transfer
Dest. terminal
Line j
Origin terminal
Line j
BoardStop
AlightStop
2nd Transfer
Origin terminal
Line k
Dest. terminal
Line k
DestStop
Attribute
Description
Survey line
Preceding/Succeeding
Path legs traveled by passenger which are before or after the survey line
A path leg is the transfer-free part of a passenger trip on a line, from boarding
to alighting (number of path legs = number of transfers + 1)
510
Origin terminal
Destination terminal
OrigStop
Starting stop (origin) of a passenger trip: first boarding stop entering a PuT line
per PuT path
DestStop
Destination stop of a passenger trip: last alighting stop leaving a PuT line per
PuT path
PTV AG
Attribute
Description
BoardStop
Boarding stop of the survey line: stop at which the passenger enters the survey
line
AlightStop
Alighting stop of the survey line: stop at which the passenger leaves the survey
line
Standard questionnaire
Questionnaire
Line:
Bus 1
Orig.Term:
A village
Departure:
6:10
Route
Preced. 2:
Preced. 1:
Y town
42
Boarding:
Station
20
Alighting:
B village
30
Suceed. 1:
Suceed. 2:
Ticket
One-Way
Season
Group
Number of Persons:
The replies obtained in a passenger survey are noted down in questionnaires. Such a
questionnaire form usually consists of parts.
Features which identify the questionnaire are entered in the header, such as the
interviewer's number, vehicle class and service trip number.
In the main section, codes for the boarding and alighting stops of the survey line are
entered, plus information on any preceding or succeeding lines.
The illustration 163 displays a schematic example for a questionnaire. With this questionnaire,
up to 5 path legs (2 preceding legs + survey line + 2 succeeding legs) can be recorded.
6.12.2
PTV AG
511
1. Visum first reads from a text file a set of survey records which closely resemble the
information in the PuT Path Legs list. For each surveyed trip, the following information is
supplied:
Vehicle journey, boarding and alighting stop point for the surveyed leg of the trip
Origin and destination of the complete trip
Information on the legs taken between origin stop and surveyed boarding stop and
between surveyed alighting stop and destination stop (if present).
2. The second operation tries to complete each survey record by filling in plausible values for
all missing fields.
Numerous plausibility checks are carried out on the survey data, and the user can
specify rules for substituting by plausible values (for example, for the lines or the
departure times of the services), if the stated values do not form part of a valid
connection.
A comprehensive log file tags each survey record with a status describing which
substitutions were performed and how reliable the resulting information is.
A new version of the survey file is written which contains all the additional information
that could be determined automatically.
Users can review the survey records which are flagged as inconsistent and decide
whether to discard or to manually correct them.
The operation Plausibilization of survey records can then be repeated.
3. As step three, survey data that succeeded during plausibilization are directly assigned to
the Visum network.
Volumes of connections, all network object volumes and related indicators are set.
Furthermore a demand matrix can be created containing the surveyed trips.
PuT skim matrices of the connections can be created.
Any of the post-assignment analysis tools can then be applied to the assignment result
generated from survey data.
512
PTV AG
Survey
Records
file
T he user checks the survey data
records that are not plausible and
discards or corrects them m anually.
Subsequently, the plausibilization can
be repeated.
Import
survey
records
Incom plete
survey records
in memory
Survey
Records
file
Log
file
Check and
com plete
survey
records
Com plete
survey records
in memory
Direct
As signment
Assignment
result
in memory
Note: The same functionality can be applied to data extracted from e-ticketing applications, if
the data contain at least check-in information per leg with line route, stop point, and departure
time. In this case, a path leg needs to be marked as surveyed path leg.
6.12.3
6.12.4
PTV AG
513
Note: The boarding and alighting stops stated in the interview data records of the surveyed
line must exist in the checked network. If this is not the case, the record in question is ignored.
If one of these stops is deleted after reading survey data from file, all paths from/to these
stops will get lost.
514
PTV AG
E1
E2
E3
E7
E8
E9
E5
plausible
not plausible
YES
E1
NO
YES
NO
YES
NO
E2
YES
E3
nein
E7
E5
YES
E8
NO
E9
not
plausible
plausible
* In case of multiple vehicle journeys, the one with the minimum sum of run time and wait
time is chosen.
PTV AG
515
V2
V3
V4
V5
V6
ViT plausible
V9
not plausible
YES
V1
NO
Other criteria
for direct validity check?
YES
YES
V3
NO
YES
V5
NO
Find another
preceding path leg
YES
V2
YES
NO
Find another
preceding path leg
YES
ViT NO
V9
not
plausible
plausible
NO
V9
NO
Is option
Connection search
active for remaining
preceding section?
YES
V9
Vm
V9
NO
NO
YES
Is option Direct
connection active?
YES
NO
NO
YES
V4 YES
NO
Vm
YES
Vm
YES
NO
V6
* In case of multiple vehicle journeys, the one with the minimum sum of run time and wait
time is chosen.
516
PTV AG
Plausible
1
A vehicle journey could be found in the surveyed time profile (or surveyed line route or line,
depends on preciseness of input data), which connects boarding stop and alighting stop of the
surveyed path leg and starts within the time tolerance interval defined for the time of departure
from the boarding stop.
A vehicle journey could be found in another time profile (or line route) of the surveyed line,
which connects boarding stop and alighting stop of the surveyed path leg and starts within the
time tolerance interval defined for the time of departure from the boarding stop.
A vehicle journey could be found in a time profile (or line route) of another line, which connects
boarding stop and alighting stop of the surveyed path leg and starts within the time tolerance
interval defined for the time of departure from the boarding stop.
For the surveyed path leg, an indirect connection could be found by timetable-based search
(shortest path search) which departs from the boarding stop within the tolerance interval
defined for the departure time from this stop and includes at least one transfer (and walk links,
if applicable).
Not plausible
7
Implausible, because none of the line routes (which are valid due to current parameter settings)
connects boarding stop and alighting stop and connection search is not permitted either.
Implausible, because the time profiles of the line routes (which are valid due to current
parameter settings) connecting boarding and alighting stop do not include a departure within
the time tolerance interval defined for the time of departure from the boarding stop and
connection search is not permitted either.
Implausible, because no connection from boarding to alighting stop starting in the given time
frame could be found during connection search calculation.
Plausible
1
A vehicle journey could be found in the preceding time profile (or preceding line route or line,
depends on preciseness of input data), which meets the condition defined for the permitted
time span.
A vehicle journey could be found in another time profile (or line route) of the preceding line,
which meets the condition defined for the permitted time span.
A vehicle journey could be found in a time profile (or line route) of another line, which meets the
condition defined for the permitted time span.
A direct vehicle journey from OriginStop to BoardStop with a shorter journey time (Factor
Journey time of Direct connection + constant < Journey time of preceding section) compared to
the plausible (multi-part) preceding section could be found and is used instead.
PTV AG
517
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).
Not plausible
9
Implausible, because no path leg (or sequence of path legs) could be found meeting the given
validity check criteria.
Plausible
1
A vehicle journey could be found in the succeeding time profile (or succeeding line route or
line, depends on preciseness of input data), which meets the condition defined for the
permitted time span.
A vehicle journey could be found in another time profile (or line route) of the succeeding line,
which meets the condition defined for the permitted time span.
A vehicle journey could be found in a time profile (or line route) of another line, which meets
the condition defined for the permitted time span.
A direct vehicle journey from AlightStop to DestStop with a shorter journey time (Factor
Journey time of Direct connection + constant < Journey time of succeeding section) compared
to the plausible (multi-part) succeeding section could be found and is used instead.
Replacing at least one of the succeeding path legs by an indirect connection which was found
by timetable-based connection search (incl. transfer(s) and walk link(s), if applicable).
Not plausible
9
Implausible, because no path leg (or sequence of path legs) could be found meeting the given
validity check criteria.
Not processed
Plausible
1
All of the sections (preceding leg(s), succeeding leg(s) and/or survey leg) are plausible.
Not plausible
9
Implausible because of one (or more) implausible sections (preceding leg(s), succeeding
leg(s) and/or survey leg).
Table 179: Status indicators for the entire survey data record
518
PTV AG
6.12.5
PTV AG
Volume display as bars along links (see "Tabular and graphical display" on page 725)
Flow bundle calculations (see "Flow bundles" on page 697)
Skim matrix calculation on the basis of directly assigned paths (if not already calculated at
the direct assignment) (see "PuT skims" on page 437)
Calculation of PuT operating indicators, for example for the line costing and revenue
calculation (see "PuT operating indicators" on page 605)
519
520
PTV AG
Subjects
7.1
General indicators for bundling line data (for example the number of vehicle journeys per
line route) [Attribute: Number of service trips])
Indicators for the measurement of the operating performance (for example the service
kilometers to be run by an operator)
Indicators for the measurement of the transport performance (for example the passenger
hours for a vehicle journey)
Indicators for the calculation of the operating costs (for example the stop point costs per
line). The cost model permits modeling of vehicle type-based costs as well as infrastructure
costs.
Indicators for the calculation of fare revenues (revenue calculation). Zone-based fares,
distance-based fares as well as further fare structures can be modeled for fare calculation
in Visum.
Indicators of vehicle requirement and of line blocking
PTV AG
521
The second module of the operator model is line blocking. A line block contains all vehicle
journeys which are run successively by one vehicle combination (see User Manual, Chpt. 7.1,
page 1157) or by several similar vehicle combinations. The objective of line blocking is to
assign the total number of trips to vehicles, so that costs are reduced. Also line blocking
provides indicators such as empty kilometers of a line block. In the following, these are
designated as indicators of the vehicle requirement and line blocking. In most cases line
blocking is carried out prior to the calculation of PuT operating indicators in the procedure flow,
because it provides input attributes for cost analyses (determination of the number of vehicles,
which has an effect on the vehicle costs in the PuT operating indicators). The procedure PuT
interlining matrix is provided in addition to the line blocking procedure. It calculates transport
system-specific skim matrices for interlining trips between stop points of a transport system.
7.1.1
There are different levels of detail for breaking down indicators to territories. To calculate
indicators on these levels of detail, apply the procedure PuT operating indicators (see User
Manual, Chpt. 7.3, page 1219). The results of the procedure can be found in the Territories PuT detail list. In detail, the indicators can be calculated for territories on the following levels
(this concerns indicators from the PuT assignment as well as from the procedure PuT
operating indicators and the line blocking procedure):
522
Territory
Territory x Transport system
Territory x Main line
Territory x Line
Territory x Line route
Territory x Time profile
Territory x Vehicle journey
Territory x Transport system x Vehicle combination
Territory x Main line x Vehicle combination
Territory x Line x Vehicle combination
PTV AG
If a Visum model has two territories (west, east) and three transport systems (bus, tram, train),
indicators are calculated for each combination of territory and transport system on the level
territory x transport system.
Territory
TSys
ServiceKm
PassengerKm
East
Bus
2,776.88
17,219.58
East
Train
1,611.57
21,094.72
East
Tram
6,796.78
187,312.42
West
Bus
538.57
9,671.80
West
Train
323.14
5,803.08
West
Tram
5,703.52
214,538.25
Note: Not every indicator is available for all aggregation levels. In the IndicatorAvailability.xls,
under ...Program files\PTV Vision\PTV Visum 13\Doc\Eng, you can find tables specifying the
aggregation levels on which the indicators are available.
7.1.2
7.1.2.1
Using territory-related evaluations, you can calculate indicator data for territories which
represent fare zones, urban districts, municipalities or counties for example. The territory
polygon is decisive for the calculation; and the indicator's share, which applies to the polygon
will be returned (see "Territories" on page 52). The example network of Karlsruhe contains six
territories (illustration 167). In the example, the territories correspond to the PuT fare zones
created in the Visum fare model. This means, that the polygons (territory boundaries) were
modeled in such a way, that they contain exactly those stops of the respective PuT fare zones.
Each PuT fare zone thus corresponds to exactly one territory and the indicators can be
calculated by fare zone. Some examples for possible territory-based analyses are introduced
below.
PTV AG
523
Using the indicators Number of stop points Total, Line network length (directed) and the
Number of service trips, information can be obtained on the line routes and the timetable of the
model for each territory. Within the territory polygon Center there are 182 stop points. The line
network length is calculated per transport system. The directed line length (the total link length
of the links traversed via line routes) of the bus network in the city center is 54 km. In the
analysis period of one day, 3154 vehicle journeys (number of vehicle journeys with at least one
stop within the territory polygon) stop in this territory. Using these indicators as a basis, the first
statements regarding the PuT connectivity of the territories can be made.
Territory
Center
182
54.015
3,154
North East
53
34.993
814
South
14
8.716
350
East
73
90.188
1,776
West
157
66.749
1,779
96
58.474
1,888
Suburbs
524
PTV AG
The performance indicators represent the efforts required for the PuT supply provision in
length units or in time units. The most used indicator is called service kilometers or service
miles, if applicable. These are the main drivers for costs, which arise for the operator of a line
The ratio between the service miles and the revenues, which are generated in a territory, can
provide information on how efficient the performance is in this territory. In the example, this
ratio is stored in the user-defined attribute Revenue_per_ServiceKM. For that purpose, the
value of this formula describing the ratio was stored in the user-defined attribute. In this way,
also territories can be identified, where it is also very appealing for a PuT operator, to provide
transport performance. In the outer regions of the example (suburbs), where fewer passengers
have to be transported, however, longer distances have to be covered, less revenues probably
accumulate than in the center. Such a view is useful, if no costs have been modeled in Visum
and simply tendency statements on the cost-effectiveness in a territory are desired.
Territory
Center
ServiceKm(AP) [km]
16,648
143,945.75
8.65
North East
2,918
8,674.07
2.97
South
1,379
7,416.01
5.38
East
6,615
24,371.61
3.68
6,328
40,159.07
6.35
11,191
4,736.75
0.42
West
Suburbs
Table 182: Territory-based indicator data for transport performance and revenue analysis
7.1.2.2
The indicator data can be refined even more, if the territory is evaluated on different
aggregation levels. Indicators can for example, be calculated like this for each line within a
territory.
In the field of transport performance, the indicator Passenger kilometers of a line within a
territory is often used for analyses. On attainable PuT revenues, the passenger kilometers
permit statements by trend, especially in case there are no data on the exact revenues and
these are therefore not modeled in Visum. The table 183 shows the passenger kilometers and
the number of passenger trips (number of passengers boarding) for line 2 in the territories,
which are traversed (illustration 168). For this evaluation, the aggregation level Territory x
Line was selected (see User Manual, Chpt. 7.3, page 1219). This is how you can determine
how many passenger kilometers of the line apply to the fare zones.
PTV AG
525
Line
PassengerKm(AP) [km]
Center
80,590
30,533
East
21,021
9,479
West
4,356
6,021
7.1.2.3
If you are not interested in the territory-based evaluation of indicators, you can also carry out
evaluations directly at the line hierarchy levels. For a PuT operator it is important to know for
example, what the volume/capacity ratio of the vehicles is along the course of the line routes.
Based on this, the operator can decide to lengthen or shorten a line route. The table 184 shows
the beginning and the end of the line route course of line 002 and the saturation of seats
between stops. Between Siemensallee and Lassallestrae, the average volume/capacity ratio
is only 4 %, so that shortening the line may be a possibility.
526
PTV AG
Index
Line route
name
Direction
code
2_H
>
Node number
105497581
Vol/Cap ratio
Seats [%]
Wolfartsweier Nord
2_H
>
105224474
2_H
>
105224473
2_H
>
105497580
2_H
>
105497579
Durlach Zndhtle
10
10
2_H
>
105226816
10
2_H
>
105226814
10
2_H
>
105226812
10
2_H
>
105222467
10
10
2_H
>
105497578
...
...
...
...
11
...
...
106
2_H
>
107
2_H
>
100521
Kussmaulstrasse
41
100522
Hertzstrasse
26
21
108
2_H
>
100523
Feierabendweg
109
2_H
>
100524
Neureuter Strasse
110
2_H
>
105496077
111
2_H
>
100525
Siemensallee
112
2_H
>
100526
Lassallestr
Table 184: Analysis of the Vol/Cap ratio of seats on the line route level
The service kilometers are often taken into account for the distribution of the calculated
operating costs between an infrastructural operator and the provider of the PuT supply. In this
example, Line S3 uses the infrastructure of the Deutsche Bahn (German Rail). In the Lines list,
the service kilometers can be displayed per line.
Line name
Transport system
R92
TRAIN
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
PTV AG
527
Visum supports you when making a decision on the line bundle to be run by a bus operator
("To which operator, which of the lines are allocated?"). For each line, typical indicators such
as costs, total revenue, revenue per passenger trip, total cost coverage and cost coverage per
passenger trip are calculated. The table shows the values for the analysis horizon of one year.
Lines with a cost coverage deficit have a negative amount of coverage. In terms of balancing
the high-profit lines and low-profit lines as fair as possible, this data can be used to form line
bundles, for which PuT operators then can apply in the framework of a tender.
Line
name
Transport
system
Costs [CU]
21
BUS
433,831.31
22
BUS
254,736.07
314,551.88
0.53
23
BUS
487,624.88
214,824.83
0.55
30
BUS
515,029.02
1,818,301.46
0.63
1,303,272.44
0.45
353.05
31
BUS
705,276.05
872,187.83
0.59
166,911.78
0.11
123.67
32
BUS
452,384.95
425,354.17
0.44
-27,030.78
-0.03
94.02
42
BUS
361,669.22
868,201.73
0.52
506,532.51
0.30
240.05
43
BUS
276,488.08
215,746.49
0.50
-60,741.59
-0.14
78.03
44
BUS
333,456.14
54,659.89
0.53
-278,796.26
-2.69
16.39
45
BUS
429,574.91
330,818.45
0.61
-98,756.46
-0.18
77.01
46
BUS
188,345.74
261,343.71
0.51
72,997.98
0.14
138.76
47
BUS
339,342.42
189,913.11
0.71
-149,429.31
-0.56
55.97
50
BUS
509,071.08
988,980.88
0.58
479,909.80
0.28
194.27
773,477.34
0.56
339,646.03
0.25
178.29
59,815.80
0.10
123.48
-272,800.05
-0.70
44.06
51
BUS
88,748.77
195,342.70
0.57
106,593.93
0.31
220.11
52
BUS
328,666.85
335,666.87
0.52
7,000.01
0.01
102.13
55
BUS
0.00
0.00
0.00
0.00
0.00
0.00
60
BUS
337,039.94
2,004,260.28
0.51
1,667,220.34
0.43
594.67
62
BUS
0.00
0.00
0.00
0.00
0.00
0.00
70
BUS
717,616.46
1,375,946.79
0.53
658,330.33
0.25
191.74
71
BUS
83,309.71
171,403.50
0.52
88,093.79
0.27
205.74
73
BUS
384,722.03
1,809,097.37
0.52
1,424,375.34
0.41
470.23
74
BUS
265,425.27
1,151,942.68
0.53
886,517.42
0.40
434.00
75
BUS
52,673.44
243,368.34
0.47
190,694.90
0.37
462.03
107
BUS
231,821.70
77,805.81
0.52
-154,015.89
-1.04
33.56
108
BUS
59,030.88
0.00
0.00
-59,030.88
0.00
0.00
123
BUS
397,079.54
40,164.47
0.99
-356,915.07
-8.76
10.11
151
BUS
216,990.34
41,625.77
25,569.00
-175,364.57
-7.16
19.18
222
BUS
244,624.05
23,291.90
2.16
-221,332.15
-20.56
9.52
551
BUS
142,190.73
306,929.17
0.59
164,738.44
0.32
215.86
528
PTV AG
7.1.2.4
Splitting up the revenues from fares to various operators of a transport association often
regards the service kilometers or the seat kilometers as a basis. Visum returns this data by
operator. For the three operators in the Karlsruhe example, the following values apply.
Operator name
12,071
1,092,238
DB German Rail
23,906
2,165,751
9,096
454,811
7.1.2.5
If you are working with analysis time intervals (see User Manual, Chpt. 4.2, page 948), you can
evaluate most indicators broken down in time slices (see "PuT operating indicators" on
page 605). This means, that the share of an indicator value which falls in a time interval, is
calculated. In the example KA_dyn.ver, this is used to determine the service kilometers for 1hour-intervals. In this way, the bus operator can determine operational performance peaks and
has an indicator for the evaluation, how evenly the vehicle fleet is utilized in the course of the
day. The example shows time intervals of one hour from 5:00 a.m. to 10:00 p.m. For the bus
operator, the operator-related evaluation via all time intervals returns the following service
kilometer values.
Operator name: KBB Bus Operator
ServiceKm (05:00 a.m.)
227.0
622.2
689.9
602.4
487.2
443.0
461.7
537.2
604.5
541.9
608.7
710.2
695.7
626.8
406.1
Table 188: Evaluation of service kilometers per time interval for the bus operator
PTV AG
529
263.1
203.1
Table 188: Evaluation of service kilometers per time interval for the bus operator
If the operator additionally compares the passenger kilometers, the statements by trend can be
derived, for example the efficiency level by time interval. The time intervals 9 to 12 p.m. and
after 6 p.m. show very low values for this indicator. Thus, in opposition to a relatively high
transport supply performance (ServiceKm) there is a relatively low passenger demand.
Time interval
05:00 a.m.
Passenger kilometers
[km]
227.0
3,101.9
Passenger kilometers
--------------------------------------------------------- [ - ]
Service kilometers
13.7
06:00
622.2
14,034.9
22.6
07:00 a.m.
689.9
24,411.3
35.4
08:00
602.4
15,663.0
26.0
09:00 a.m.
487.2
4,785.9
9.8
10:00 a.m.
443.0
5,518.6
12.5
11:00 a.m.
461.7
7,902.9
17.1
12:00 a.m.
537.2
7,785.6
14.5
1:00 p.m.
604.5
13,961.9
23.1
2:00 p.m.
541.9
14,275.4
26.3
3:00 p.m.
608.7
12,241.2
20.1
4:00 p.m.
710.2
11,603.5
16.3
5:00 p.m.
695.7
7,215.4
10.4
6:00 p.m.
626.8
4,747.2
7.6
7:00 p.m.
406.1
1,731.9
4.3
8:00 p.m.
263.1
672.1
2.6
9:00 p.m.
203.1
258.4
1.3
7.2
530
PTV AG
0..1
Operator
Standard Op.
0..1
Line
0..n
VehComb
StdVehComb
0..1
0..1
Time profile
VehUnit
0..1
StdVehComb
1..n
Operator
Vehicle journey
VJ section
Transport system
VehComb
Legend
Standard Op.
StdVehComb
0..n
VehComb
VehUnit
7.3
An operator can be allocated as the standard operator to a complete line. When creating a
new vehicle journey for this line later, the standard operator will be pre-set.
Apart from that, you can select an operator for particular vehicle journeys for example in
the timetable editor.
A vehicle combination can be allocated as the standard vehicle combination to a complete
line or an entire time profile. When creating a new vehicle journey later, the standard
vehicle combination will be pre-set.
Apart from that, you can select a vehicle combination for particular vehicle journey sections
for example in the timetable editor.
One or more units of a vehicle unit make up a vehicle combination. In this way the trains
can be more accurately modeled, because they can be made up of different coaches. The
making-up means creating or editing a vehicle combination.
PTV AG
531
4. Definition of a cost model (hourly costs, kilometer costs, vehicle costs, stop point costs, link
costs, operator costs) (see User Manual, Chpt. 7.2, page 1215).
5. Parameterization and calculation of the PuT line blocking procedure (see User Manual,
Chpt. 7.1, page 1157).
6. Definition of the reference frameworks for evaluations
Definition of territories (see User Manual, Chpt. 2.22.1, page 369) and selection of the
aggregation level for evaluations by territory (see User Manual, Chpt. 7.3.2,
page 1220).
Definition of analysis time intervals for evaluations by time slice (see User Manual,
Chpt. 4.2, page 948).
Definition of operators (see User Manual, Chpt. 2.27.1, page 438) and allocation to
vehicle journeys.
Definition of the projection factor (see User Manual, Chpt. 2.42, page 645).
7. Calculation of the Territory indicators procedure (see User Manual, Chpt. 4.4.3, page 970).
8. Calculation of the PuT operating indicators procedure for the desired indicator classes (see
User Manual, Chpt. 7.3, page 1219).
7.4
Line blocking
Subjects
7.4.1
532
PTV AG
Fundamental terms
The basis of the line blocking efforts is the timetable with the vehicle journeys, which are to be
run by the blocks (Visum creates the blocks on the level of vehicle journey sections). Blocks
are created by linking individual trips to trip chains, which can each be serviced by a vehicle
combination. In the simplest case, a vehicle journey is concatenated at its last stop with a
subsequent service which starts at the same stop. If such a linkage is not possible nor useful,
an Empty Trip can transfer the vehicle combination to another stop point. Only the empty trips
with a real change of location between two stop points count as interlining. If a vehicle changes
from one stop point to the depot, at the same stop point or vice versa, this is referred to as pullin or pull-out. This difference is important when selecting the option Interlining permissible (see
User Manual, Chpt. 7.1.3.2, page 1169). For pull-in or pull-out without change of location,
neither empty trips nor empty kilometers accumulate.
As displayed in the illustration 170, the following times are included.
Interlining times
Time required for interlining trips between two vehicle journeys which end/start at different
stop points.
Layover
Layover time at a stop until next vehicle journey departure time.
In Visum, those unproductive empty times without passenger transport can be calculated by
means of the line blocking calculation and will then be considered during cost calculation for
lines. The same applies to empty kilometers or empty miles.
Once line blocking has been calculated, the empty times and empty kilometers/miles of each
line block are known and can be displayed in the Line Blocks list.
Pull-In
Service
Stand
Service
Stand
Service
Stand
Interlining
Service
Pull-Out
Stop1
7:00
8:00
Stop2
Stop3
6:00
9:00
10:00
11:00
Illustration 170: Example line block with pull-out trip, interlining trip and pull-in trip
PTV AG
533
No.
Action
FromStop
ToStop
Dep
Arr
Pull-Out
Stop3
06:00
a.m.
06:30
a.m.
Stop1
06:30
a.m.
07:15
a.m.
Interlining
Stop1
Stop2
07:15
a.m.
Layover
Stop2
Stop2
Layover
Time
Length
30 min
10 km
45 min
30 km
07:30
a.m.
15 min
10 km
07:30
a.m.
08:00
a.m.
30 min
0 km
Stop1
08:00
a.m.
08:15
a.m.
15 min
10 km
Stop1
Stop1
08:15
a.m.
08:30
a.m.
15 min
0 km
Stop3
08:30
a.m.
09:15
a.m.
45 min
30 km
Layover
Stop3
Stop3
09:15
a.m.
09:30
a.m.
15 min
0 km
Stop1
09:30
a.m.
10:15
a.m.
45 min
30 km
10
Pull-In
10:15
a.m.
10:45
a.m.
30 min
10 km
Stop1
Line
BUS1-1>
BUS1-2>
BUS1-1>
BUS1-1>
Table 190: Example line block with pull-out trip, interlining trip and pull-in trip
Optimization problem
For the optimization task of line blocking, there is always a conflict between the number of
empty trips (or more so the sum of empty kilometers covered on the empty trips) and the
number of vehicles to be used. By creating empty trips, the number of required vehicles can
usually be reduced, however, costs accumulate for the additional empty trips (illustration 171
bottom). On the other hand, empty trips can be saved when implementing more vehicles
(illustration 171 top). Depending on how costs are assessed by the user regarding empty trips
on the one hand and additional vehicles on the other side, line blocking can return various
optimum solutions. In addition to these two basic parameters, Visum offers more indicators
which can be integrated into the cost function. The detailed cost function which is minimized in
this context can be found in the line blocking procedure description (see "Construction of the
graph" on page 564). The solution principle of line blocking in Visum, which includes creating
a graph and the solution as a flow problem, is also described here.
534
PTV AG
PTV AG
The solution as a graph flow problem now makes it possible to include long-lasting
downtimes of vehicle combinations for example in depots - in the process. There is no
maximum dwell time, as a vehicle is permitted to stay in the depot or anywhere else for any
desired period. The dwell time can now be evaluated by a cost rate freely defined by the
user and can thus be included in the objective function of the optimization problem (see
"Construction of the graph" on page 564).
The estimate of the number of vehicles required to run the blocks is more precise.
If closed blocks are created, the empty trips can be determined which are required to
return those vehicles shifted from one location to another, to their starting point. The
non-consideration of the time required to return the vehicles would lead to an
underestimation of the empty kilometers and empty times.
535
7.4.2
The duration of blocks is limited by the assignment period that can be one or several
calendar days. This allows the program to calculate the correct number of vehicles.
Minimum layover times have a major impact on possible transfers. As common in
practice, you may use minimum layover times to interpret the restrictions during the
assignment period as soft. You can thus balance the effects of minimum layover time
and vehicle deployment.
Blocks can be reedited manually. For that purpose, you can also create user-defined block
item types. This is how you can manually include maintenance tasks or washing cars in
block planning, for example.
You can change various parameters per block version in order to easily compare several
line blocking scenarios.
At any time, a line block is consistent with its vehicle journey sections. Possible
inconsistency only applies to reduced pre and post preparation times or empty trips in the
case of changes to the network after line blocking.
Blocks are only subject to the demand of correctness when they are being used, they do
not necessarily have to be free of errors. This means: In many cases, you can edit the basic
network whereupon existing line blocks are not discarded. Only when evaluating them in
other procedures, line blocks have to be free of errors - for example as a basis for vehicle
requirement, empty kilometers and empty trips computation for the calculation of vehicledependent costs by means of the PuT operating indicators procedure (illustration 197).
Check line block (see "Line block check" on page 560) thus helps finding and correcting
potential errors.
Several additional issues may be considered during line blocking. This includes the
intended duration of the line blocks (number of blocking days), distribution of the layover
times, scheduling of repeated stationary events (maintenance) and the consideration of the
direction of travel.
536
PTV AG
7.4.2.1
Illustration 172: Line network of the example with three bus lines (red, blue and yellow)
PTV AG
537
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.
Block no.
Mean operating km
NoLineInterchange
1h 30min
55
NoLineInterchange
1h 30min
55
NoLineInterchange
21min
26
NoLineInterchange
56min
40
LineInterchange_Expensive 2
1h 51min
81
LineInterchange_Expensive 1
56min
40
LineInterchange_Cheap
2h 32min
111
LineInterchange_Cheap
2h 32min
111
Below, the resulting blocks are illustrated graphically and in tabular form.
538
PTV AG
Blocking Block
day
item
type
Layover
Vehicle
journey
Layover
Vehicle
journey
Line
name
Vehicle
journey
no.
Start
time
00:00:00
a.m.
X City
07:20:00 X City
a.m.
07:20:00
a.m.
X City
08:05:00 A Village
a.m.
08:05:00
a.m.
A Village
08:40:00 A Village
a.m.
08:40:00
a.m.
A Village
09:25:00 X City
a.m.
Layover
09:25:00
a.m.
X City
00:00:00 X City
a.m.
Layover
00:00:00
a.m.
A Village
06:59:00 A Village
a.m.
Vehicle
journey
07:10:00
a.m.
A Village
07:55:00 X City
a.m.
Layover
07:55:00
a.m.
X City
08:50:00 X City
a.m.
Vehicle
journey
08:50:00
a.m.
X City
09:35:00 A Village
a.m.
BUS1
BUS1
BUS1
BUS1
PTV AG
539
Block Index
no.
Blocking Block
day
item
type
Line
name
Vehicle
journey
no.
Start
time
Layover
09:35:00
a.m.
A Village
00:00:00 A Village
a.m.
Layover
00:00:00
a.m.
X City
08:05:00 X City
a.m.
Vehicle
journey
22
08:05:00
a.m.
X City
08:26:00 A Village
a.m.
Layover
08:26:00
a.m.
A Village
00:00:00 A Village
a.m.
Layover
00:00:00
a.m.
A Village
08:15:00 A Village
a.m.
Vehicle
journey
21
08:15:00
a.m.
A Village
08:36:00 X City
a.m.
Layover
08:36:00
a.m.
X City
00:00:00 X City
a.m.
Layover
00:00:00
a.m.
A Village
06:25:00 A Village
a.m.
Vehicle
journey
31
06:25:00
a.m.
A Village
06:53:00 B Village
a.m.
Layover
06:53:00
a.m.
B Village
10:00:00 B Village
a.m.
Vehicle
journey
32
10:00:00
a.m.
B Village
10:28:00 A Village
a.m.
Layover
10:28:00
a.m.
A Village
00:00:00 A Village
a.m.
BUS2
BUS2
BUS3
BUS3
540
PTV AG
Illustration 175: Covering the timetable through blocks without empty trips
Block Index
no.
Blocking Block
Line
day
item type name
Vehicle
journey
no.
Start
time
Layover
00:00:00 A Village
a.m.
06:25:00 A Village
a.m.
Vehicle
journey
07:10:00 A Village
a.m.
07:55:00 X City
a.m.
Layover
07:55:00 X City
a.m.
08:05:00 X City
a.m.
Vehicle
journey
22
08:05:00 X City
a.m.
08:26:00 A Village
a.m.
Layover
08:26:00 A Village
a.m.
08:40:00 A Village
a.m.
Vehicle
journey
08:40:00 A Village
a.m.
09:25:00 X City
a.m.
Layover
09:25:00 X City
a.m.
00:00:00 X City
a.m.
Layover
00:00:00 X City
a.m.
07:20:00 X City
a.m.
BUS1
BUS2
BUS1
PTV AG
541
Block Index
no.
Blocking Block
Line
day
item type name
Vehicle
journey
no.
Start
time
Vehicle
journey
07:20:00 X City
a.m.
08:05:00 A Village
a.m.
10
Layover
08:05:00 A Village
a.m.
08:15:00 A Village
a.m.
11
Vehicle
journey
21
08:15:00 A Village
a.m.
08:36:00 X City
a.m.
12
Layover
08:36:00 X City
a.m.
08:50:00 X City
a.m.
13
Vehicle
journey
08:50:00 X City
a.m.
09:35:00 A Village
a.m.
14
Layover
09:35:00 A Village
a.m.
00:00:00 A Village
a.m.
Layover
00:00:00 A Village
a.m.
06:25:00 A Village
a.m.
Vehicle
journey
31
06:25:00 A Village
a.m.
06:53:00 B Village
a.m.
Layover
06:53:00 B Village
a.m.
10:00:00 B Village
a.m.
Vehicle
journey
32
10:00:00 B Village
a.m.
10:28:00 A Village
a.m.
Layover
10:28:00 A Village
a.m.
00:00:00 A Village
a.m.
BUS1
BUS2
BUS1
BUS3
BUS3
542
PTV AG
Illustration 176: Covering the timetable through line comprehensive blocks with empty trips
Note: The empty trips in illustration 176 run from B Village to X City following the first trip of
the day, in reverse direction before starting the last trip of the day. They are not graphically
displayed.
Block Index
no.
Blocking Block
day
item
type
Layover
Vehicle
journey
Layover
Vehicle
journey
Layover
Vehicle
journey
Line
name
BUS1
BUS2
BUS1
ToStopPoint
name
00:00:00
a.m.
A Village
06:25:00
a.m.
A Village
07:10:00
a.m.
A Village
07:55:00
a.m.
X City
07:55:00
a.m.
X City
08:05:00
a.m.
X City
22
08:05:00
a.m.
X City
08:26:00
a.m.
A Village
08:26:00
a.m.
A Village
08:40:00
a.m.
A Village
08:40:00
a.m.
A Village
09:25:00
a.m.
X City
PTV AG
543
Block Index
no.
Blocking Block
day
item
type
Line
name
ToStopPoint
name
Empty
trip
09:25:00
a.m.
X City
09:38:00
a.m.
B Village
Layover
09:38:00
a.m.
B Village
10:00:00
a.m.
B Village
Vehicle
journey
32
10:00:00
a.m.
B Village
10:28:00
a.m.
A Village
10
Layover
10:28:00
a.m.
A Village
00:00:00
a.m.
A Village
Layover
00:00:00
a.m.
A Village
06:25:00
a.m.
A Village
Vehicle
journey
31
06:25:00
a.m.
A Village
06:53:00
a.m.
B Village
Empty
trip
06:53:00
a.m.
B Village
07:06:00
a.m.
X City
Layover
07:06:00
a.m.
X City
07:20:00
a.m.
X City
Vehicle
journey
07:20:00
a.m.
X City
08:05:00
a.m.
A Village
Layover
08:05:00
a.m.
A Village
08:15:00
a.m.
A Village
Vehicle
journey
21
08:15:00
a.m.
A Village
08:36:00
a.m.
X City
Layover
08:36:00
a.m.
X City
08:50:00
a.m.
X City
Vehicle
journey
08:50:00
a.m.
X City
09:35:00
a.m.
A Village
10
Layover
09:35:00
a.m.
A Village
00:00:00
a.m.
A Village
BUS3
BUS3
BUS1
BUS2
BUS1
7.4.2.2
Independent of the selected calendar type, open and closed blocks can be generated. Open
blocks start on the first day of the line blocking time interval (or later) and end by the latest on
the last day. For closed blocks, the last day is again followed by the first day of the line blocking
time interval, so that each end of a sequence of block items is connected with a start. This ring
closure is analog to timetable-based PuT assignment and is used to include the costs for
creating the initial situation into the model. The creation of closed blocks assures that the
created line block schedule "in perpetuo" can be traversed. The following example with an
extremely unsymmetrical timetable makes this clear.
544
PTV AG
If open blocks are created in this example, then one vehicle is sufficient, because the trip from
A Village to X City plus the empty trip in the opposing direction will require 66 minutes and the
departure of this cycle in A village is every 2 hours. The vehicle can therefore reach the starting
point before the start of the next trip.
When creating closed blocks however, two vehicles are required. The reason for this lies in the
last trip, which is scheduled for 26:05 and thus still belongs to the previous day. Only one hour
lies between the departure of this vehicle journey and the subsequent first trip on next day, so
that the vehicle cannot return to the starting point in the meantime. When creating open blocks,
this transition to the following day is not regarded, which may result in underestimating the
vehicle demand.
Apart from the pure vehicle demand, the open block solution of course has one empty trip less.
If costs are evaluated for empty trips, this solution also simulates a less expensive situation. In
each case it has to be decided, whether the empty trip which is required to form the ring closure
has to be included in the model or not.
Note: Open blocks can be created, if the model represents the planning situation for a certain
single day or period. If the line blocking time interval however, represents a longer cycle
which is to be repeated (for example a standard day), closed blocks should be created, to
correctly determine the costs for restoring the initial state in the model.
PTV AG
545
Block no.
Number of
blocking
days
Mean operating km
OpenBlocks
12h 51min
616
Self-ContainedBlocks 2
6h 36min
321
Table 195: Open block and closed block for the unsymmetrical example (illustration 177)
Block Index Blocking Block item Line
no.
day
type
name
Vehicle
journey
no.
Start
time
Vehicle
journey
16
03:05:00 A Village
a.m.
03:50:00 X City
a.m.
Empty trip
03:50:00 X City
a.m.
04:11:00 A Village
a.m.
Layover
04:11:00 A Village
a.m.
05:05:00 A Village
a.m.
Vehicle
journey
18
05:05:00 A Village
a.m.
05:50:00 X City
a.m.
Empty trip
05:50:00 X City
a.m.
06:11:00 A Village
a.m.
Layover
06:11:00 A Village
a.m.
07:05:00 A Village
a.m.
...
...
...
...
...
...
...
...
31
Vehicle
journey
BUS1
36
11:05:00 A Village
p.m.
11:50:00 X City
p.m.
32
Empty trip
11:50:00 X City
p.m.
00:11:00 A Village
a.m.
33
Layover
00:11:00 A Village
a.m.
02:05:00 A Village
a.m.
34
Vehicle
journey
37
02:05:00 A Village
a.m.
02:50:00 X City
a.m.
Layover
00:11:00 A Village
a.m.
02:05:00 A Village
a.m.
Vehicle
journey
37
02:05:00 A Village
a.m.
02:50:00 X City
a.m.
Empty trip
02:50:00 X City
a.m.
03:11:00 A Village
a.m.
Layover
03:11:00 A Village
a.m.
00:00:00 A Village
a.m.
Layover
00:00:00 A Village
a.m.
03:05:00 A Village
a.m.
BUS1
BUS1
BUS1
BUS1
FromStop
Point
name
...
...
Table 196: Block items of both blocks in the example Block items in the recurring rhythm were omitted
for a better overview. Block 1 is open, block 2 is closed.
546
PTV AG
Vehicle
journey
no.
Start
time
Vehicle
journey
16
03:05:00 A Village
a.m.
03:50:00 X City
Empty trip
03:50:00 X City
a.m.
04:11:00 A Village
a.m.
Layover
04:11:00 A Village
a.m.
05:05:00 A Village
a.m.
Vehicle
journey
18
05:05:00 A Village
a.m.
05:50:00 X City
a.m.
10
Empty trip
05:50:00 X City
a.m.
06:11:00 A Village
a.m.
11
Layover
06:11:00 A Village
a.m.
07:05:00 A Village
a.m.
...
...
...
...
...
...
...
...
36
Vehicle
journey
BUS1
36
11:05:00 A Village
p.m.
11:50:00 X City
p.m.
37
Empty trip
11:50:00 X City
p.m.
00:11:00 A Village
a.m.
BUS1
BUS1
FromStop
Point
name
...
...
Table 196: Block items of both blocks in the example Block items in the recurring rhythm were omitted
for a better overview. Block 1 is open, block 2 is closed.
7.4.3
Data model
This section describes the data for the following key points:
Block version
Block
Block item and block item type
Attributes of the line blocking cost function
Downtimes in depots and at stop points
Line block check
Coverage check
7.4.3.1
Block version
In Visum multiple line blocking results can be stored in parallel. These are stored in so-called
block versions. In this way, alternative plans with different parameter settings can be compared
easily to one another. For example, a block version where interlining is allowed and another
one where this is not allowed, can be maintained in the model. Procedures such as the
calculation of PuT operating indicators always refer to the current active block version.
Important parameters of the Line blocking procedure are attributes of a block version, so that
the parameter settings are still known afterwards, and especially the check line block can use
them for comparisons with the same parameters after changes. The block version attributes
are described in table 197.
PTV AG
547
Attribute
Description
First day of the line blocking time interval. The line blocking time interval
has to lie inside of the calendar period.
Valid from
Valid to
Interlining permissible
Specifies, whether the line blocking and check line block procedures
should create empty trips (see "Line block check" on page 560).
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 short turns should be permitted for line blocking and
check line block. This means that the layover time is allowed to differ
from the pre- and post-preparation times. The short turn properties are
set in the attributes for the maximum dwell time, the reduced prepreparation time and the reduced post-preparation time.
Specifies the stop point attribute, where the values of the maximum dwell
time is contained.
Specifies the vehicle journey section attribute, where the values of the
reduced pre-preparation time is contained.
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 a certain vehicle unit for all blocks of the
block version
548
PTV AG
7.4.3.2
Block
A block means, constant application of N vehicles throughout the entire line blocking time
interval. N is the number of blocking days. It does neither depend on the line blocking time
interval nor on the length of the calendar. The attribute Number of blocking days reflects the
vehicle demand which arises for a block. In illustration 178, a train travels from Hamburg to
Vienna on blocking day 1. On blocking day 2 the same train is not available again to travel the
same route, but has to travel in the opposite direction from Vienna to Hamburg first. It is
therefore necessary to implement a second train, thus the vehicle demand is two vehicles.
Description
Vehicle combination
number
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
Empty trip transport system Specifies which transport system should be used within check line block
code
when calculating the empty trip. The value is applied from the procedure
parameters for line blocking. It can also be inserted directly for manual
planning.
Not checked
Specifies, whether an incorrect vehicle was used in the block (see "Line
block check" on page 560).
PTV AG
549
Attribute
Description
Specifies, whether a blocking day without block items exists (see "Line
block check" on page 560).
Specifies, whether a time fault exists (see "Line block check" on page 560).
Specifies, whether one of the thresholds for the length or the threshold for
the duration of a user-defined block item was exceeded (see "Line block
check" on page 560).
Specifies, whether a valid forced chaining which was not adhered to, exists
(see "Line block check" on page 560).
Specifies, whether a running direction fault exists (see "Line block check"
on page 560).
Specifies, whether the running direction is relevant for the check of this line
block. Otherwise, the line block check cannot detect a running direction
fault. If the running direction is not relevant (buses, for example), this
portion of the line block check can be disabled via this option (see "Line
block check" on page 560).
Specifies at which stop point the block starts. For closed blocks, this
complies with the To stop point.
Specifies at which stop point the block ends. For closed blocks, this
complies with the From stop point.
Starting day index of the block referring to the line blocking time interval of
the block version. For closed blocks, the value is always 1.
Start time
Start time of the block, therefore start time of the first block item. For closed
blocks this is usually midnight, unless a vehicle journey block item exceeds
24 hours on the last day.
Ending day index of the block referring to the line blocking time interval of
the block version. For closed blocks, the value is always equal to the
number of days in the line blocking time interval.
End time
Ending time of the block, therefore end time of the last block item. For
closed blocks this is usually midnight, unless a vehicle journey block item
exceeds 24 hours on the last day.
Empty time
Empty time / (Number of blocking days Number of line blocking time interval
days)
550
PTV AG
Attribute
Description
Empty trip time / (Number of blocking days Number of line blocking time interval
days)
Out-of-depot time
Mean operating time per blocking day and calendar day (cumulative
operating time divided by the number of blocking days and the number of
days of the line blocking time interval).
Operating kilometers /
miles
Mean operating kilometers / Operating kilometers / (Number of blocking days Number of line blocking time
miles
interval days)
Service time
Service time / (Number of blocking days Number of line blocking time interval
days)
Time outside depot / (Number of blocking days Number of line blocking time
interval days)
Block time
Number of lines
Number of vehicle journey block times, which are run by the block.
Cost distance
Kilometer costs of the block, which result from the traversed service and
empty kilometers (illustration 197).
Cost vehicle
Vehicle costs, which result from the number of required vehicles and the
fixed costs for a vehicle unit (illustration 197).
Cost vehicle referring to the Cost vehicle projected to the line blocking time interval
line blocking time interval
Cost Time
Hourly costs, which result from the time required for vehicle journeys and
empty trips.
Hourly block costs which arise from the vehicle journeys and empty trips, as
well as from downtimes within or outside of a depot accumulated time
periods.
PTV AG
551
Attribute
Description
Depot with the longest dwell time. For ambiguity, the depot with the
smallest number.
7.4.3.3
Each block is made up of individual sections, which are called block items. Each block item has
a start and an end, and a start stop and an end stop. The table 199 shows the attributes of a
block item and their meanings.
Attribute
Description
Blocking day
Specifies, to which blocking day the block item has been assigned.
Block item type number / Number and name of the block item type of the block item. By default, the four
name
block item types vehicle journey, empty trip, layover time and depot are
defined.
Line name
Line which is run by this block item. The attribute only displays a value, if the
block item is a vehicle journey.
Line route which is traversed by this block item. The attribute only displays a
value, if the block item is a vehicle journey.
Direction code
Direction of the line route which is traversed by this block item. The attribute
only displays a value, if the block item is a vehicle journey.
Time profile which is used by this block item. The attribute only displays a
value, if the block item is a vehicle journey.
Vehicle journey which is run by this block item. The attribute only displays a
value, if the block item is a vehicle journey.
Vehicle journey section which is traversed by this block item. The attribute
only displays a value, if the block item is a vehicle journey.
Specifies the calendar day for the start of the block item referring to the start
day of the line blocking time interval (attribute start day index of the block
version).
Start time
Specifies the calendar day for the end of the block item referring to the start
day of the line blocking time interval (attribute start day index of the block
version).
End time
From stop point number / Stop point where the block item starts. Complies with To stop point, if it is a
name
block item of type layover or layover time.
To stop point number /
name
Stop point where the block item ends. Complies with From stop point, if it is a
block item of type layover or layover time.
Duration
Time period of the block item. For block items with a user-defined block item
type (for example maintenance) this duration can be edited manually.
552
PTV AG
Attribute
Description
Length
Distance of the block item. For block items with a user-defined block item type
and block items of type empty trip, you can edit the length manually.
Is in depot
Distance until a block item of the same type appears in this block again. Only
available for block items of a user-defined block item type.
Period until a block item of the same type appears in this block again. Only
available for block items of a user-defined block item type.
Departure minute
Only the minute value of the attribute start time is displayed (for example,
start time: 07:20:00, departure minute: 20).
Arrival minute
Only the minute value of the attribute end time is displayed (for example, end
time: 07:20:00, arrival minute: 20).
Chain number
Number of the chain. A chain represents a complete run through the block,
throughout the entire line blocking time interval. There are as many chains as
blocking days, and the N-th chain starts on the first day of the line blocking
time interval on blocking day N.
Starts in forward
direction
Is change of running
direction
Specifies whether the activity which is described by this line block item
includes a change of the running direction. Is only regarded for user-defined
line block items.
Each block item is of a certain type (block item type). By default, there are the block item types
vehicle journey, empty trip, stand (layover/depot) and layover time in Visum. You can also
create user-defined types and manually integrate them into your blocks (for example,
maintenance or washing vehicles). The table 200 shows the attributes of block item types.
Attribute
Description
Created by the
system
Default duration
Default value for the time period of block items of this type (default setting when
creating such a block item).
Default length
Default value for the length of block items of this type (default setting when creating
such a block item).
Time limit
Maximum value for the duration between two block items of this type. If a value >0
is specified here, the time elapsed between the occurrence two items of this type
may not exceed this threshold. If this is not the case, the check line block function
will return a limit fault (see "Line block check" on page 560).
PTV AG
553
Attribute
Description
Length limit
Maximum value for the distance being traversed by a block between two block
items of this type. If a value >0 is specified here, the distance traversed between
the occurrence two items of this type may not exceed this threshold. If this is not
the case, the line block check will return a limit fault (see "Line block check" on
page 560).
7.4.3.4
To find the optimum line block, a cost function is minimized during line blocking (see "Line
blocking description without vehicle interchange" on page 563). The attributes found in
table 201 are regarded by this cost function.
Note: Up to and including Visum 10 the different cost rates at vehicle units and vehicle
combinations were not used in line blocking. Because of this, existing networks do not
contain this data. For the new line blocking model this means that for each activity costs = 0
accumulate, independent of prefactors. This thus leads to an unnecessary use of vehicles
and empty trips. When changing from the old model, make sure that - at least for vehicle
costs and empty trips - positive costs rates are set.
Attribute
Object
Description
Vehicle requirement
Activity in the block (= Total number of vehicles required for the block version.
vehicle journey, layover
in depot, layover at
stop point, pre and post
preparation time,
empty trip)
Vehicle combination
Service time
Activity
Vehicle combination
Service kilometers
Activity
Empty time
Activity
Vehicle combination
Empty kilometers
Activity
554
PTV AG
Attribute
Object
Description
Layovers
Activity
Vehicle combination
Layover in Depot
Activity
7.4.3.5
At stop points you can specify for each vehicle combination, whether the stop point should be
used as a depot by the vehicle combination. A capacity and a minimum downtime time can be
specified for each vehicle combination. The capacity is restricted to the number of vehicle
combinations, which are allowed to stop at the same time at the stop point (as a depot), as long
as the capacity > 0; for capacity = 0 the depot capacity is unlimited. Depots are therefore stop
points with downtime function. The downtime in the depot is evaluated with a cost rate that is
different (usually lower) from the cost rate for the downtime at a stop point, though both
downtimes belong to the block item type layover. A difference is made between the same stop
point in its role as a depot and as a stop point.
Attribute
Description
Is Depot
Specifies that the stop point is a depot. A stop point is a depot, if either
at least one vehicle combination is permissible or the entry Default
values is permissible.
Depot Capacity
PTV AG
555
Table 203: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in table 201 refer
to this)
Cost Rate Layover Hour
Cost Rate 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)
Total cost rate for downtimes at depots (= cost rate per depot hour + cost
rate per depot hour from vehicle units)
Table 204: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates in
table 201 refer to this)
7.4.3.6
Empty trips
Empty trips are used for interlining a vehicle, if the end stop point of the vehicle journey section
to be carried out, does not correspond with the start stop point of the vehicle journey section
following in the block. The generation of empty trips is carried out according to the same
principles, in the check line block and in both procedures of line blocking, and has direct effect
on the data model.
The generation of empty trips via the attribute Create empty trips can basically be deactivated
at the block version. Line blockings for this block version, as well as the check line block for line
blocks in this block version, can therefore not calculate empty trips. If end and start stop point
of consecutive block items do not correspond with each other, this is characterized as a
location break.
If the generation of empty trips is generally allowed, Visum tries calculating an empty trip to
change of location. This is always carried out with regard to the empty trip transport system of
the block. For the line block check, this is the specified empty trip transport system (input
attribute). No blocks exist a priori for line blocking. Dependent on the parameter settings for
each configuration (see "Partitioning" on page 563) of a block which could occur, an empty trip
transport system is predefined and saved to the actual generated blocks. This ensures, that
with a later check the same empty trip transport system is used.
With the block version attribute Use system routes it can be specified further, how the empty
trip calculation should be carried out:
556
PTV AG
With the selection of the suitable option, the generated empty trips can be controlled in detail.
7.4.3.7
In many cases, the running direction of a vehicle carrying out a vehicle journey does not have
to be regarded separately. This is the case if all vehicle journeys are carried out in the 'ahead'
mode (one-way vehicle, especially all buses and some trams) or if the running direction is
irrelevant (railcar operation in rapid transit). Anyhow, in some cases it is requested, that the
running direction of the vehicle combination is always the same, for example, because the
station wagon of a train is expected to stop at a fixed position at the platform or because the
vehicle dynamics of push-pull trains depends on the running direction.
Thus it is optionally possible to take the running direction into account for line block checks and
manual line blocking Visum. For this purpose, for each turn in the network it has to be specified
if this turn means a change of the running direction. Useful data can be provided by turn
standards (see "Nodes and turns" on page 37) based of turn types.
Thus, each movement in the network inherits information on running direction changes. Along
a line route which means in the course of a vehicle journey a running direction change occurs
especially where a turn with the property Is change of running direction is traversed. If a line
block takes the running direction into account (attribute Regard running direction), these
changes of the running direction will be visualized in the line block display.
PTV AG
557
Illustration 179: Display of a change of the running direction in the course of vehicle journey block items.
The line route makes a U-turn in the station "TFS"
Accordingly, the empty trip block items obtain information from the network whether running
direction changes occur in their course. If the empty trip is based on a system route, the
running direction changes are located in the same manner as for vehicle journeys and will
similarly be visualized in the line block display. If there is no system route, then the route
search determines whether an even or an odd number of direction changes appears; only this
is relevant to line blocking. Thus, empty trip block items with an odd number of running
direction changes are centre-subdivided in the view.
For user-defined block items the information whether running direction changes are included is
explicitly stored with the attribute Is change of running direction. Hence, also a rotary
journey (U-turn or triangle-shaped) can explicitly be modeled as user-defined block item.
If the running direction has to be regarded for a line block, the line block check will verify the
item end - item start changeovers in the sequence of line block items and define the running
direction at the beginning of the activity for each block item. A direction fault is recorded if a
vehicle journey section is run in either direction by this line block on different calendar days. For
a closed line block, a direction fault is additionally recorded if the running direction changes
after the closed line block has been completed.
The line blocking procedure cannot directly evaluate the change of running direction
information. Thus it cannot intentionally generate line blocks without direction faults. In the line
blocking procedure, the parameter Regard running direction works as follows:
558
PTV AG
Regard running direction: Subsequently to the line blocking procedure, the line blocks are
checked for direction faults. If applicable, the appropriate fault status is set.
Do not regard running direction: For the line blocks, the attribute Regard running
direction is set to 'false'.
Attribute
Description
Is change of running
direction
If attribute default values from the turn standard are allocated to a turn, the
original turn attribute values will be replaced by the allocated standard values for
the selected attributes. This makes the standard value allocation easier. To all
turns of the U-turn type, for example, the property Is change of running
direction can be allocated.
Description
Is change of running
direction
The value of this attribute indicates, whether traversing this turn means a
change of the running direction. This applies to line routes and system routes as
well as to the change of direction determination for empty trips during the line
block check. Furthermore, this attribute is evaluated for the item end - item start
changeovers in the sequence of line block items within a line block.
Description
Is change of running
direction
Is true, if the line route item is located at a node, where the line route course
traverses a turn with the property Is change of running direction.
7.4.3.8
Forced chainings
For line blocking it is determined from the start, which incoming trip has to be connected to
which outgoing trip. Especially in rail services, such pre-connections are often produced due to
the short time between the connected trips. The reason being, that changing the vehicle pool
between arrival and departure is not possible. Desired through-connections between trips are
a source for such forced connections.
Forced chaining is a relation of a vehicle journey section to a follow-up vehicle journey section
on a calendar day. Forced chaining means that this transfer in the line blocking result has to be
adhered to. Line blocking therefore has to treat the thus connected vehicle journey sections
(these can be transitive whole chains) like a sole performance. Forced chainings can be
different for each calendar day. They therefore connect occurrences of vehicle journey
sections.
By definition a maximum of 24h to 1s. is allowed to lie between the arrival of the vehicle journey
section and the departure of the successor. The calendar of the successor is therefore clearly
determined by the arrival time, consequently by the calendar day of the origin vehicle journey
section. Forced chaining is valid, if the origin vehicle journey section is even operating on the
calendar day of the forced chaining, if in the described time interval, an occurrence of the
destination vehicle journey section starts after the occurrence of the origin vehicle journey
section, and if in addition the vehicle combinations of the origin vehicle journey section and the
destination vehicle journey section coincide (block does not have vehicle interchange) or the
PTV AG
559
respective vehicle combination sets have a non-empty intersection (block has vehicle
interchange).
Forced chainings are optionally considered in line blocking. In this case, as long as none of the
following conditions applies, the generated blocks meet the predefined valid forced chainings:
The same destination vehicle journey section was defined as a destination for the same
calendar day in different forced chainings. The forced chaining first found is then taken, i.e.
the one with the smaller key at the origin vehicle journey section.
The end stop point of the origin vehicle journey section does not coincide with the start stop
point of the destination vehicle journey section, and the time between is not enough for an
empty trip or empty trips are not allowed to be generated. The block then has a forced
chaining fault.
7.4.3.9
In the previous Visum version of line blocking, the blocks always had to be correct, which
means that they were not allowed to have time or location breaks. The result was, that the
blocks were deleted when making important changes in the network (for example at vehicle
journeys). This cannot be tolerated, especially when blocks were edited manually and
therefore cannot simply be restored by carrying out line blocking again. In the block data model
now available in Visum, the consistency of line blocks with the network is assured and in return
the constant correctness of the block itself is no longer required. Instead, you have the
possibility of performing a check line block to calculate the status which codes the information
on consistency (called error flags below) for each block. These error flags provide you with
information on whether the blocks are error free and if not, in which respect there are
inconsistencies. All together there are eight error flags.
The state model in illustration 180 shows the possible states of a block and how the eight flags
are set.
560
PTV AG
Line
Blocking
New Block
Unchecked
No Fault
Block
Check
Veh. Fault
Limit Fault
Direction Fault
Minor Faults
Layover Time Fault
Forced Chaining Fault
Adjustment to
altered data
Adjustment to
altered data
Adjustment to
altered data
Major Faults
Time Fault
Location
Fault
Adjustment to
altered data
Edit Block
Illustration 180: State model for line blocks
The blocks react if the network database changes. Changes to the block version, the block
items and the vehicle journey sections are taken into consideration. Furthermore, blocks react
to changes made to the basic network parameters, especially to calendar settings.
PTV AG
Location fault
Two successive trips in a block do not match, because the successive trip does not start at
the same stop point, where the preceding trip ends.
Time fault
Two successive trips in a block overlap with regard to time. This means, that the preceding
trip arrives later than the successive trip departs.
Layover time fault
Two successive trips overlap each other in time only if for arriving trips the post-preparation
time and for departing trips the pre-preparation time is included in a block. This means, that
the planned layover time is not sufficient. In practice such an error can be ignored
sometimes, but has to be checked manually. If both trips are connected by forced chaining,
adherence to the pre- and post preparation time is not checked for this transfer, because
the forced chaining has priority.
Vehicle fault
The block includes vehicle journey sections to which a vehicle combination was allocated
which does not match the block. This error can occur for example, if line blocking has
calculated a block for a standard bus and later on the user manually assigns a low-floor bus
to one of the trip sections. The attribute Has vehicle interchange is used for the evaluation
of this error. This decides whether the comparison regards either vehicle journey section
attribute vehicle combination or vehicle combination set.
561
A block that contains the flag unchecked or time fault or location fault is not allowed to be
regarded by subsequent evaluations (for example in the PuT operating indicators procedure).
The other six flags however, do not restrict usability. This is necessary to be able to also
transfer plans from other systems and to be able to use it for the line performance and line
costing calculations in the procedure PuT operational indicators (see "Description of the PuT
interlining matrix procedure" on page 581), which often contain such errors (partially
deliberately).
562
When using reduced layover times, it could occur that no error flag is displayed, although
the block contains a layover time error (LayoverTimeFault). This is the case, if the value of
one of the three attributes describing the reduced layover time was subsequently edited or
the selection of one of these attributes changed. These user-definable attributes of stop
points and vehicle journey sections are: reduced pre-preparation time, reduced postpreparation time and maximum dwell time. The reason for this being, that these three
attributes can be specified dynamically by the user (in particular, also indirect or userdefined attributes can be used). Due to calculation times, it is not efficiently possible to
react to changes in these attributes and to automatically set the error flag. That is why you
have to carry out the forced version of the check line block, to make sure that all layover
time undershoots (layover time fault) are determined in the checked blocks, if subsequent
changes have been made. If no reduced layover times are used (block version property),
this problem can not occur.
PTV AG
7.4.4
7.4.4.1
Partitioning
Line blocking regards the vehicle journey sections of the model for planning, the generated
blocks thus successively traverse vehicle journey sections. For planning, either all or all active
vehicle journey sections, or - orthogonally thereto - either all sections or only those not yet
being bound in the target block version can be regarded (see User Manual, Chpt. 7.1.3.2,
page 1169). Prior to the graph construction, the problem is broken down into subproblems, socalled partitions, which are to be solved separately. A partition consists of all vehicle journey
sections to which the same vehicle combination has been assigned. The decomposition into
these subproblems is possible, because a block is always run by exactly one vehicle
combination and there is therefore no vehicle change within the block. Also the vehicle journey
sections which do not have a vehicle combination, together form a partition. For each partition,
all further procedure steps are carried out separately. Thus, a separate graph is constructed
and solved for each partition and each result will be decomposed into blocks.
PTV AG
563
As an option, line blocking can be partitioned further according to operator, transport system,
and line (see User Manual, Chpt. 7.1.3.2, page 1169). If for example the same operator is
required for the next vehicle journey, operators are partitioned additionally. In this case each
partial problem and thus each resulting block only contains vehicle journey sections of a
vehicle combination and of an operator. Operator changes can therefore not be made within a
block. Within the procedure, a separate graph is set up for each combination of vehicle
combination and operator, and the other procedural steps are carried out for each of these
graphs. The illustration 181 shows an example of partitioning. These are vehicle journey
sections run by three vehicle combinations: articulated bus, standard bus, and tram. The
articulated bus vehicle journey sections are run by operator 1 and 2, whereas the tram vehicle
journey sections are run by operator 1 only. If line blocking is additionally partitioned according
to operators, five graphs will be built, for which the flow problem has to be solved separately
and the decomposition into blocks needs to be carried out separately.
VehComb
Articulated Bus
Standard Bus
Tram
Operator
Operator1
Operator 2
Operator 1
Operator 2
Operator 1
Graph
Graph 1
Graph 2
Graph 3
Graph 4
Graph 5
Illustration 181: Example for partitioning according to vehicle combination and operator
Note: Capacity restrictions in depots can only be considered, if the graph is not partitioned
further than by vehicle combination, if therefore none of the options Same operator for next
vehicle journey, Same transport system for next vehicle journey or Same line for next vehicle
journey has been selected. The reason for this being, that the capacities in depots are each
defined per vehicle combination. If a more detailed partitioning is carried out for example
according to operators, the procedure does not have the possibility of distributing the
capacity, even further to the level Vehicle combination x Operator.
7.4.4.2
564
PTV AG
depot ( = C)
time
Illustration 182: Inserting the nodes and edges for vehicle journey sections
2. For each permissible depot for the vehicle combination as well as for each stop point, which
is the start of a vehicle journey section of the current partition (empty trips between stop
points), enter an arrival event for the time of arrival and an edge for the empty trip from the
departure event of the trip to the arrival event at the stop point or depot (so-called unreal or
"fake" arrival events are thus created). Depots are thus special stop points. In the graph,
the events at stop points and in depots are distinguished which means, that in the graph
there is one node for the stop point and another one for the depot, although the depot is
represented by the same stop point in the network.
PTV AG
565
depot ( = C)
time
Illustration 183: Inserting the edges for entering the depots and for empty trips between stop points
3. Analogously, insert also a departure event and an edge from there to the departure event
of the trip, however, only for each permissible depot, not for other stop points (these mean
moving out of the depots, so-called fake departure events are created in this way).
566
PTV AG
vehicle journey
depot ( = C)
time
Note: If interlining is prohibited (see User Manual, Chpt. 7.1.3.2, page 1169), only edges from
and to that depot are inserted, which is represented by the same stop point in the network.
Thus, interlining is not possible in this case, the vehicle combination can however, enter a
depot and subsequently return to the same stop point for the start of the next trip.
4. Insert an additional edge (the so-called Timeline or Waiting edge) between each pair of
succeeding events of a stop point or depot. Using this edge, it is possible to model waiting
(downtimes) at a stop point or in a depot. Timeline edges thus make it possible, that a block
can be continued with a new trip at the same stop point.
For line blocking you can select whether you want to create open or closed blocks. With the
generation of closed blocks, each timeline, therefore each sequence of timeline edges for
a stop point or a depot, generates a closed ring. Vehicle journey edges and empty trip
edges can also cross the transition from the last to the first day of the blocking time interval.
A block has as many blocking days as it makes "rounds" through the calendar period, until
it has reached its starting point again.
Only for open line blocking it can be claimed, that blocks start and end in depots.
Connecting edges are then inserted before the first node and after the last node of a
timeline, from an auxiliary node to all depots. Inflow and outflow only takes place via this
auxiliary node. In this case it may occur, that no flow can be determined. This happens
when the total capacity of all depots is smaller than the number of vehicles required to
cover all actions. In such a case, line blocking is canceled with an error message.
Also in the introductory example (see "Open and closed blocks" on page 544) you can find
a note concerning open and closed line blocks.
PTV AG
567
5. The graph is now simplified, by combining nodes with the same accessibility and by
deleting equivalent empty trip edges (which provide access to the same departure). The
graph after the edge reduction can be seen in illustration 185.
"real" arrival or departure event
vehicle journey
timeline edge
depot ( = C)
time
Illustration 185: Example graph after inserting the timeline edges and edge reduction
6. For the formulation as a flow problem, it is necessary to define a lower capacity limit and an
upper capacity limit to the edges (which is the number of vehicles which can maximally or
minimally flow via an edge). The following applies:
The lower limit of the capacity on the vehicle journey sections is 1 (because it is
mandatory that each vehicle journey section is really traversed).
All other edges have a lower capacity limit of 0 (because traversing is not mandatory,
for example for empty trips).
The upper limit for the vehicle journey section edges is also 1 (because each vehicle
journey section should only be traversed exactly no more than once).
Empty trip edges as an upper limit have the number of empty trips, which they represent
(this is only greater than 1, if in the framework of edge reduction, edges were
combined).
Edges along the timelines, if we are talking about a depot, use the depot capacity as
upper limit. For all other timelines the upper limit is not restricted.
7. To be able to determine a cost-efficient flow, the edges with costs have to be evaluated in
the last step. These are described by a cost function analog to the perceived journey time
for PuT assignments (see "Perceived journey time" on page 481). This cost function is
made up of summands, which each multiply one property of the edge (therefore the activity
described by the edges) by a factor and a cost rate. The cost function is as follows:
568
PTV AG
Cost
Note: The coefficients also have an effect on the cost rate for "no vehicle combination".
Which cost components have an effect on an edge, depends on the edge type. The cost
components for the individual edge types are the following.
As an interim result, an evaluated graph is available, for which a flow with minimum costs is
determined in the following step.
PTV AG
569
7.4.4.3
With the graph constructed above including the evaluation, the cost minimum flow is now
determined. The target cost function can thus be parameterized as described in the previous
procedure step. The user can thus especially control modeling of the basic conflict between
minimizing empty trips and minimizing vehicle demand, which is described in the introduction.
The illustration 186 schematically shows such a cost minimum flow, where multiple flow units
(vehicle combinations) are indicated on an edge with lines piled on top of each other. To make
it easier, neither costs nor capacities are noted here. The illustration however shows, that all
vehicle journey sections are traversed by exactly one vehicle combination. The graph also
shows, which empty trips even have to be traversed at a minimum cost flow (i.e. all edges
crossed by the flow). Altogether there are two empty trips one from C to A and one from B
to C. The evaluation line cuts three edges, that is why the vehicle demand is 3.
"real" arrival or departure event
trip to depot
evaluation line
optimum flow
timeline edge
depot ( = C)
time
As a result of this step, a cost-efficient flow exists, the vehicle demand is known and which are
the necessary empty trips. Not known yet however, are the blocks themselves, therefore at
which stop points blocks start and end, and the routes of the blocks in the optimal flow.
570
PTV AG
7.4.4.4
The cost-efficient flow in the graph from the previous step can be displayed as blocks in
different ways. Regarding the costs, each of these solutions is of equal quality and thus
optimal. The decomposition step has to break up the flow into chains in the graph, by allocating
an outgoing flow unit at each node. Each generated chain thus corresponds to one block. The
illustration 187 and the illustration 188 show two possible examples, how the cost-efficient flow
can be decomposed into blocks.
"real" arrival or departure event
block 1
vehicle journey
trip to depot
block 3
timeline edge
depot ( = C)
time
PTV AG
571
block 1
vehicle journey
trip to depot
block 3
timeline edge
depot ( = C)
time
This independent optimization problem can be resolved according to different criteria. In Visum
there are two criteria, which can also be combined with each other:
572
The structure of the changeovers between vehicle journey sections in the block can be
influenced by the following options:
Differentiated duration of standstills: The distribution of the standstill times is as
irregular as possible, in other words, there are more short and long standstills than
average standstill times. The aim of this is to obtain long standstills which can be used
as maintenance time slots.
Even duration of standstills: The distribution of the standstill times is as even as
possible. Such blocks are exceptionally resistant to disturbances.
Line purity: It is attempted to only run trips of the same line in a block or at least avoid
line changes within a block as often as possible.
No specific requirements: In this dimension, no requirements are set concerning the
result.
Even blocks: For assignment periods of more than one day, the program aims at
calculating line blocks that look as similar as possible for all calendar days.
If closed blocks are generated, the duration of the blocks can also be influenced with the
options
Preferably, build long blocks: Blocks have as many blocking days as possible. This
means that the single vehicles traverse multiple line paths. In the most extreme case,
all vehicle journeys of a partition are covered by a single line block.
Preferably, build short blocks: Blocks have as few blocking days as possible.
PTV AG
7.4.5
Selection according to costs: Different costs are involved with the selection of a vehicle
combination, which flow into the objective function.
Selection according to capacity: For the selection, a comparison between the trip volume
(Assignment results or count data) can be carried out on the one hand and the (seat)
capacity of the vehicle combination on the other hand. Not the covered demand provided
by the capacity, is included in the objective function.
Selection according to availability: The number of available vehicles can be predefined on
the unit level. The selection is made, so that this restriction is adhered to. The number of
vehicles used in addition to the ones available are included into the objective function.
Line blocking with vehicle interchange thus goes beyond the application area of line blocking
without vehicle interchange (see "Line blocking description without vehicle interchange" on
page 563) and also covers the following application areas.
Planning the vehicle use depending on the demand, at the same time considering blockrelated restrictions.
Reduction of the calculated vehicle requirement by making the vehicle use more flexible,
with the (possibility of) replacing a vehicle combination with another, for example because
of technical restrictions.
Consideration of different vehicle combination-specific minimum layover times
The procedure is based on the line blocking without vehicle interchange and integrates this as
a procedural step into its entire process. Compared to this one it is not about an analytical
procedure, but an iterative search procedure which in general finds very good solutions, but
never an optimal one regarding the objective function.
As another distinctive feature, several complete and equal solutions of the given line blocking
task (parameter number of solutions per iteration), exist for each time of the procedure.
These are changed iteratively and evaluated. If there is no improvement of the objective
function value (convergence) or if the defined maximum number of iterations has been
reached, the procedure is stopped and the best solution is provided.
The procedure includes the following steps.
1. Initial selection of the vehicle combination from the specified vehicle combination set for
each vehicle journey section and each solution.
2. Line blocking without vehicle interchange for this selection for each solution
3. Evaluation of the solution and convergence check.
4. Determining and merging selections, which have lead to good solution properties, and new
start from step 2.), until convergence applies or the maximum number of iterations has
been achieved.
PTV AG
573
Because the line blocking is carried out as in the procedure without vehicle interchange (see
"Line blocking description without vehicle interchange" on page 563), for defined selection of
the vehicle combinations, the following additional components are necessary to understand
the procedure:
7.4.5.1
The selection of vehicle combinations which can be used from the set specified for each
vehicle journey section, is the central component of the procedure. The challenge as a search
procedure is to produce as many different selections and to avoid such selections which lead
to poor solutions. This task can be compared with the connection search per Branch&Bound
within the timetable-based assignment.
In the initial step of the procedure there are no solutions yet. Heuristic procedures play a bigger
role for the selection. In all other iterations the selection is always made on the basis of a
solution from the preceding iteration, so that this solution can be further developed. But here
parts of the solution are also discarded and rebuilt. The selection is carried out initially, to
create the start solutions for the first iteration according to the following criteria:
574
For an individual occurrence of a vehicle journey section the selection is carried out
randomly
according to the volume of the vehicle journey and capacity of the vehicle combination
- i.e. a selection which probably leads to good coverage of the demand,
according to the specified number of vehicles, considering the vehicles already used,
by edges without selection or already selected edges - therefore a selection which
probably leads to an equal volume,
according to the neighboring vehicle journey without selection - i.e. a selection which
probably lead to productive blocks.
Based on individual occurrences of vehicle journey sections, for which a selection has
already been made, analog choices are made as far as possible
for all vehicle journeys of a line,
for all other occurrences of the same vehicle journey section,
for individual neighbors or entire chains neighboring below each other,
for the compliance of the flow conditions particular favorable occurrence of vehicle
journey sections.
The selection can be applied from the attribute Vehicle combination number of the
vehicle journey section, alternatively for all vehicle journey sections from the specifications
for the line blocking without vehicle interchange, if the vehicle combination in the set is
included in the permitted vehicle combinations set. Without vehicle interchange, the line
blocking solution thus becomes a starting solution.
If a reference solution is specified and the proximity is required, the selection can be
applied from this reference solution.
PTV AG
In all later iterations, each solution is generated from an existing solution. The relative
inefficient parts of the solution are determined, who's selection is discarded and based on the
new ones retained, analog choices made according to the same criteria as in the initial stage.
In addition the following principles are available for the solution change:
Replace empty trips of a vehicle combination, so that for this vehicle combination a suitable
temporal and local vehicle journey is selected, for which another vehicle combination has
so far been selected.
Change the choice simultaneously for entire blocks, so that the configuration regarding the
costs is convenient.
Change the choice simultaneously for entire blocks, so that the configuration regarding the
OD demand coverage is convenient.
Change the choice simultaneously for entire blocks, so that the configuration regarding
retaining the available number of vehicles is convenient.
7.4.5.2
Line blocking with vehicle interchange uses an objective function for evaluating the quality of a
solution. The objective function measures solution properties, where there is room for
improvement. It comprises the objective function of line blocking without vehicle interchange
(see "Construction of the graph" on page 564) as a component.
The following solution properties are evaluated:
Costs: Objective function of line blocking without vehicle interchange. This especially
comprises the number of vehicles per vehicle combination as well as the service km and
empty km and service times and empty times, as well as the layovers within and outside of
a depot
Number of vehicle units: Exceeding the predefined number of available vehicle units
Consideration of volumes: Too low capacities (total or seats) regarding the OD demand
Line purity, local definition: Number of transfers between the different lines
Line purity, global definition: Number of different lines in a block
Number of vehicle combinations per line: Number of different vehicle combinations used on
the same line
Regularity: Number of vehicle journey sections, who's vehicle journey section occurrence
lies in at least two different blocks or blocking days
Difference from reference solution (only when a reference solution has been specified):
Difference to this reference solution in form of deviating transfers between vehicle journey
sections
The following function is used as an objective function (OF), which is based on the comparison
between the calculated and the estimated values for each of the objective function
components:
OF =
c i of i
------------------------------------------------i c comparison
j
i
j
where
PTV AG
575
ci
ofi
comparisoni
Calculation
Cost
The objective function component costs evaluate the solution according to the
same criteria as the line blocking without vehicle interchange.
It therefore applies
The sum is calculated over all vehicle units, across the number of used but not
available vehicles per vehicle unit
The comparison value comparisonvehicle is 1 (Note: This is how you achieve very
strong penalization, because this criterion must apply "strongly", if it is even used)
Consideration of
volumes
For the calculation, for each vehicle journey item i first the difference between its
volume and its capacity (cap) is calculated as follows
volVJI ( cap factor vc ) ,volVJI ( cap factor vc ) > 0 and VJI is active
i =
volVJI ( cap factor vc ),vol VJI ( cap factor vc ) 0 , else
i
x vol = ---------------------------------------------------------------------------------------
number of VJI of the vehicle journey
using option Peak volume
i
x vol = -------------------------------------------------------
max of i over all VJI
The value of volume is the total calculated for all vehicle journeys:
of volume =
xvol
VJ
The value of this objective function component, which applies for the random
solution, used for cost estimation, is used as a comparison value.
Table 208: Objective function components for line blocking with vehicle interchange
576
PTV AG
Component
Calculation
The number of line changes between successive vehicle journeys in the block are
measured. The benchmark is the number of occurrences of vehicle journey
sections in total (therefore the number of all changeovers between successive
vehicle journey block items).
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
Distance to
starting solution
The number of changeovers from vehicle journey section to vehicle journey section,
which differ from the comparison solution, is measured.
The comparison value is the number of all changeovers from vehicle journey
section to vehicle journey section in the comparison solution.
Table 208: Objective function components for line blocking with vehicle interchange
Note: Objective function components, which are not relevant for the specific planning task,
can be switched off by setting the respective coefficient to 0. This is recommended, because
optimization up until the solutions, considering the hidden properties, is thus suppressed.
Finding good solutions regarding the remaining criteria is accelerated accordingly.
7.4.5.3
The line blocking procedure with vehicle interchange can be controlled via several parameters.
The procedure is iterative, by first generating a number of solutions, which are then improved
step by step. If there is no improvement within a specified number of iterations, convergence
has been reached and the procedure is ended.
As a heuristic procedure, coincidence plays a decisive role, especially as there are many
equivalent solutions. By using a random number generator, the procedure is deterministic in
the sense, that each calculation with the same data and parameters achieve the same result.
You can however modify the procedure by changing the parameter Random seed and thus for
otherwise identical data calculate alternative solutions.
These are the following parameters for controlling the procedure run:
PTV AG
Parameters
Use reference
solution
Maximum number of
iterations
577
Parameters
Number of iterations
without improvement
Number of solutions
per iteration
Number of simultaneous existing solutions per iteration. The more freedom the
planning task offers, the greater this value should be. The minimum permissible
value is 10, generally however 20 to 100.
Random seed
By changing this value, the random item of the procedure can be influenced to
achieve, with otherwise same data and parameters, a different procedure und
thus a different result.
7.4.5.4
Between two vehicle journeys, different vehicles require efforts of a different extent. There are
various reasons:
Changing the running direction for a long train requires more time than changing it for a
short train. This is because it takes longer to get to the other driver's cabin at the end of the
train.
The length in time required by boarding and alighting passengers at scheduled stops
depends on the configuration of the vehicle doors.
Various final and cleaning services are required, also supply and disposal services.
Due to the various minimum layover times of different vehicle combinations, certain
changeovers between vehicle journeys are only possible for some of the provided vehicle
combinations, whereas the time slot is insufficient for others. Thus, these differences should be
regarded for the efficient vehicle use, and a vehicle should be chosen where it can be used
best.
Line blocking with vehicle interchange can take the different minimum layover times into
account. For that purpose, the attributes Use specific pre preparation time and Use specific
post preparation time have to be set to true for the concerned vehicle journey sections. Then,
via the attributes Specific pre preparation time und Specific post preparation time - each
with sub-attribute vehicle combination - the values for the pre and post preparation times can
be set for each vehicle combination. This data is automatically regarded by the procedure line
blocking with vehicle interchange. Even the line block check will take the different pre and post
preparation time values into account for the vehicle combination of the line block which will
then be determined.
7.4.6
578
PTV AG
block via drag&drop. It is thus possible, to reedit the blocks, generated with one of the two line
blocking procedures, or completely manually generate blocks. All other block-related functions
such as check line block, coverage check and definition of forced chainings can be initiated
from the line block view.
Illustration 189: Example for block display of a block with 5 blocking days
The line block display is included in the timetable editor. There you can find detailed
information on display and editing (see User Manual, Chpt. 7.1.5, page 1183).
7.4.7
7.4.7.1
Vehicle requirement
The vehicle demand can be returned in the length proportional and in the time proportional
mode. It is output for the objects of the line hierarchy as well as for territories precisely broken
down to boundaries. Fr the following network objects, both sets of indicators can be calculated
for the analysis period, the analysis horizon and by analysis time interval.
PTV AG
Vehicle journeys
Time profiles
Line routes
Lines
Main lines
Operators
Transport systems
Territories
Territory PuT detail
579
Indicator
Description
Number of Vehicles
(in proportion to
length)
Length of the vehicle journey section divided by the total length of all vehicle
journey block items in the block, multiplied by the number of blocking days of the
block.
Number of vehicles
(in proportion to
time)
Length of the vehicle journey section divided by the total length of all vehicle
journey block items in the block, multiplied by the number of blocking days of the
block.
The allocation of the indicator value for the precise calculation by territory is performed as
follows.
The time proportion of a vehicle journey section in the total time of all vehicle journey
sections of the block (called NumBlocksVJS below) is determined.
For each link that - after a temporal intersection of the vehicle journey section with analysis
period or time interval - is identified as traversed, the proportional number of vehicles is
determined according to the time proportion of the link at the VJS NumBlocksVJS. This
value is then summed up in the line hierarchy and hence called NumBlocksVJSOnLink.
For the precise calculation by territory, VISUM multiplies the length proportion of the link
in a territory NumBlocksVJSOnLink per link. Here, VISUM always uses the lengthoriented proportion since the precise link calculation by territory is always based on this
criterion. The "error" resulting from this is minimal however, because it only affects links
that lead across a territory border. The proportion of all other links is 1.0.
Note: To get a result for the indicators number of vehicles (length proportional) and number
of vehicles (time proportional), you have to first calculate the line blocking procedure and then
the procedure PuT operating indicators.
7.4.7.2
As line costing is based on vehicle journeys, empty times and empty kilometers of a line block
have to be allocated to the vehicle journeys served by the block. Based on this, costs can be
calculated by the PuT operating indicators procedure.
The example below illustrates the impact of the four variants provided for distribution of empty
times and empty distances to service trips. The operating time is calculated from empty time
and service time. Similarly, the operating distance results from empty distance and service
distance. Operating time and operating distance are required for cost calculation.
580
Vehicle journey
ServTime
ServKm
EmptyKm
OpKm
1st
6:30 7:15
0:45:00
0:05:00
0.50
30 km
0 km
30 km
2nd
8:00 8:15
0:15:00
0:05:00
0.20
10 km
0 km
10 km
PTV AG
3rd
8:30 9:15
0:45:00
0:05:00
0.50
30 km
0 km
30 km
4th
9:30 10:15
0:45:00
0:05:00
0.50
30 km
0 km
30 km
2:30:00
0.20
2:50:00
100 km
0 km
100 km
Total
ServTime
ServKm
EmptyKm
OpKm
1st
6:30 7:15
0:45:00
0:33:45
1:18:45
30 km
7.5 km
37.5 km
2nd
8:00 8:15
0:15:00
0:33:45
0:48:45
10 km
7.5 km
37.5 km
3rd
8:30 9:15
0:45:00
0:33:45
1:18:45
30 km
7.5 km
37.5 km
4th
9:30 10:15
0:45:00
0:33:45
1:18:45
30 km
7.5 km
37.5 km
2:30:00
2:15:00
4:45:00
100 km
30 km
130 km
Sum
ServTime
ServKm
EmptyKm
OpKm
1st
6:30 7:15
0:45:00
0:40:30
30 km
9 km
39 km
2nd
8:00 8:15
0:15:00
0:13:30
0:28:30
10 km
3 km
13 km
3rd
8:30 9:15
0:45:00
0:40:30
1:25:30
30 km
9 km
39 km
4th
9:30 10:15
Sum
1:25:30
0:45:00
0:40:30
1:25:30
30 km
9 km
39 km
2:30:00
2:15:00
4:45:00
100 km
30 km
130 km
ServTime
ServKm
EmptyKm
OpKm
1st
6:30 7:15
0:45:00
0:52:30
1:37:30
30 km
15 km
45 km
2nd
8:00 8:15
0:15:00
0:30:00
0:45:00
10 km
5 km
15 km
3rd
8:30 9:15
0:45:00
0:15:00
1:00:00
30 km
0 km
30 km
4th
9:30 10:15
0:45:00
0:37:30
1:22:30
30 km
10 km
40 km
2:30:00
2:15:00
4:45:00
100 km
30 km
130 km
Summe
Table 210: Example illustrating different variants of distribution of empty time and empty kilometers on
individual vehicle journeys.
7.4.8
PTV AG
581
and which is permissible for the transport system. Transitive search via the system routes is
not carried out. For each relation it is thus possible, to individually overwrite the O-D value,
determined from the network.
In the line blocking procedure (see User Manual, Chpt. 7.1.3, page 1168), the interlining matrix
is used to determine the duration and length for each empty trip between stop points. The PuT
interlining matrix procedure is also provided as a separate procedure, so that the output
matrices can be imported in external timetable or crew scheduling systems, as interlining
matrices for line blocking.
The table 211 shows an example of a PuT interlining matrix, where the values of the shortest
path (determined on the basis of the attribute t-PuTSys) between all relations between two
stop points are listed. If in a cell the value is 999999, this means, that there is no path between
the two stop points.
SP20
SP21
SP22
SP24
SP50
SP56
SP71
SP74
SP86
SP20
16
36
61
34
73
121
108
999999
SP21
16
20
45
50
89
137
124
999999
SP22
36
20
25
70
109
157
144
999999
SP24
61
45
25
95
134
182
169
999999
SP50
34
50
70
95
39
87
74
999999
SP56
73
89
109
134
39
48
35
999999
SP71
999999
999999
999999
999999
999999
999999
999999
999999
SP74
108
124
144
169
74
35
13
999999
SP86
121
137
157
182
87
48
999999
13
Table 211: PuT interlining matrix with t-PuTSys between stop points
7.5
Distance fare: The fare is conform with the distance covered, which is measured by fare
points.
Zone-based fare: The fare is conform with the number of traversed fare zones.
From-to zone-based fare: The fare is only dependent on initial fare zone and target fare
zone, this is therefore a matrix fare.
Short-distance fare: A special fare for paths, which do not exceed the specified threshold
regarding distance, run time and/or the number of stops.
The four fare structures are described in detail as follows (see "Base fare calculation" on
page 586).
582
PTV AG
The illustration 190 offers an overview of the network objects which belong to the fare modeling
in Visum.
For each demand segment you can determine which ticket types are used in a fare system.
In particular for each demand segment, several ticket types may exist for each fare system.
With the allocation of lines (and PuT-Aux transport systems) to fare systems, each path leg of
a PuT connection belongs to one or more fare systems.
Fare systems are generally independent. The total fare for a connection is normally the sum of
the fares to be paid for the individual fare systems. With specific transfer fares you can
however model, that a change between fare systems costs extra or a reduction is given (see
"Transport system-specific supplements" on page 591).
PTV AG
583
Generally speaking the crucial question is when creating a fare system, which ticket types are
allowed to be used for which connections and how much freedom does the passenger have
when selecting a ticket.
The applicability of the different ticket types plays an important role. If the defined conditions
in the ticket type have been breached, the ticket cannot be used and another ticket has to be
used. In the example, the short-distance ticket is invalid if the maximum run time of 10 minutes
has been exceeded and the airport ticket only applies for paths from and to the airport.
Distance-based or zone-based ticket types can be modeled so that they are only valid on
certain connections. You can thus define where the applicability limits of the ticket lie.
Ticket types have ranks, which can be used to express a hierarchical order within a fare
system. In combination with the previously described applicability of tickets, a logic thus
applies for determining tickets to be used, for a given connection or its path leg(s): Amongst all
applicable ticket types it is the one with the highest rank.
In the example shown, the special airport ticket must have the highest rank, because it has to
be used for all connections, whose start or target is the airport. For all other connections the
airport ticket cannot be used after construction, which is why the ticket type with the second
highest rank is regarded, in this case the short-distance ticket. This applies if the connection
fulfills the requirements of the short-distance ticket. If not, the normal zone-based fare with the
lowest rank is applied.
Do you want to illustrate that the passenger has the free choice between several ticket types,
then allocate the same rank. The most inexpensive ticket with the highest rank is selected
amongst all applicable tickets.
PTV AG
Because you can allocate ranks both on the ticket type level and the fare system level to model
specific fare conditions, all together great flexibility is achieved for fare modeling.
Subjects
7.5.1
Ticket types
Fare systems
Fare calculation
Application of fares
Ticket types
A ticket is valid for a path leg of a PuT connection, for several path legs of a connection or even
the entire connection. Validity depends on the properties of the fare system (see ""Fare
reference" of a fare system" on page 595). This section first talks about applicability,
calculation logic and other ticket type properties. To make it easier, this chapter does not
always explicitly point out that a ticket type, if necessary, only applies to individual path legs of
a connection, but talks about connections or paths.
A ticket type describes how the fare should be calculated. The fare components of a ticket type
include the base fare and TSys-specific supplements:
Fare component
Description
Base fare
The base fare is calculated from the fare structure of the ticket type. Four fare
structures can be selected:
Distance-based fare
Zone-based fare
From-to zone-based fare
Short-distance fare
Transport systemspecific
supplements
Supplements are defined separately per ticket type for each PuT transport
system and include the following components:
Distance-based supplements
Like distance-based fares, these are based on fare points.
Fixed supplements
These can be charged per path leg or once per transport system or only for the
TSys with the highest rank.
Essential characteristic of a ticket type is the fare structure, which defines the calculation
method for the base fare:
PTV AG
The distance-based fare is based on distance-based fare items: The base fare is calculated
based on the number of traversed fare points.
The zone-based fare is based on the zone-based fare items: The base fare is calculated
based on the number of fare zones traversed.
The From-to zone-based fare is based on From-To zone-based fare items: The base fare
is the entry of the pair, initial fare zone and target fare zone from the connection of a fare
matrix, which is indicated by (From-fare zone, To-fare zone).
The short-distance fare is based on short-distance fare items: The base fare applies for
tickets whose length, duration and number of stops does not exceed the defined
thresholds.
585
7.5.1.1
The calculation of the base fare is based on the fare structure of the ticket type, of which there
are four different occurrences:
Fare constant 10 CU for trips from 1 fare point through 5 fare points,
Fare constant 16 CU for trips from 6 fare points through 10 fare points,
linear increase of the fare from 16 CU to 24 CU between the range of 10 fare points and
20 fare points,
Fare constant 24 CU for trips through 30 fare points,
Ticket cannot be used fro trips with more than 30 fare points.
Expressed in a graph:
586
PTV AG
In Visum you model this fare as the following distance-based fare stages:
Number of fare points
5
Interpolate
Fare [CU]
No
10
10
No
16
20
Yes
24
30
No
24
> 30
---
[Empty field]
PTV AG
587
Fare zones do not all have to be equivalent, but can be included with a cardinality into the
count. To do so, select a numeric, integer attribute and allocate the required values. A city
center zone counts twice in many fare systems for example. It then has to receive cardinality
two.
Initial fare zones and end fare zones of a path can explicitly be excluded from the application
of cardinality.
You can specify the method of counting fare zones which have been traversed on a path
several times. Either each traversed fare zone is counted exactly once, or each entering into
a fare zone causes it to be counted again.
Illustration 192: Example for a zone-based fare with three overlapping fare zones and six stops.
The fare zones in this example have different cardinalities - fare zone 2 is to be counted twice:
Fare zone
Cardinality
1
The following base fare is charged for the respective fare zones:
588
PTV AG
2.00
3.00
3.50
>3
4.00
The result being, the traversed fare zones and thus also the fare for all the paths in the example
network:
Path
Base fare
[CU]
Stop 1 - Stop 2
2.00
Stop 1 - Stop 3
2.00
Stop 1 - Stop 6
1 and 3
3.00
Stop 1 - Stop 4
1 and 2
3.50
1 and 2
3.50
1 and 2 or 1 and 3
3.00
1 and 2 and 3
4.00
PTV AG
589
to fare zone
2.00
3.50
(*) 3.00
3.50
3.00
3.50
3.00
3.50
2.00
A comparison with the zone-based fare defined above gives the following differences:
The fare does no longer depend on the exact course of the path; a comparison between
direct and indirect path from stop 1 to stop 6 is no longer possible here, see cell (*).
However, different fares can be determined for paths with an identical number of fare
zones if required - these fares can even be asymmetrical. For example, trips from fare
zone 3 to fare zone 1 could cost 2.80 CU instead of the standard fare for two fare zones.
Only the entry at position (3, 1) would have to be changed. This could not be expressed
in a zone-based fare.
to FZ
Fare [CU]
2.00
3.00
2.00
3.00
3.00
3.50
The last entry is a wildcard for all fare zone pairs which were not mentioned explicitly before.
You can also express, that the ticket type is not applicable for certain pairs of fare zones:
from FZ
to FZ
Fare [CU]
All
2.70
All
[Empty field]
According to this definition, the ticket cannot be used for all trips to the new fare zone 4 - but
for trips in the opposite direction, for the fare of 2.70 CU.
590
PTV AG
A short-distance ticket is applicable, as soon as the threshold values of at least one of its fare
items are fulfilled. The fare is defined as the minimum fares of all fare items, whose threshold
values are met.
unlimited
max. distance
unlimited
Fare
0.50 CU
Fare item 2: as above, but only for trips with a maximum of 5 min run time. The fare is then only
0.30 CU.
max. run time
5 min
max. distance
unlimited
Fare
0.30 CU
The fare for fare item 2 can in principle also be selected higher than the fare for fare item 1.
This however, would not be reasonable because for trips up to the next stop with maximum 5
minutes run time, both threshold values are satisfied, i.e. the fare is the minimum of both fares.
This minimum would then be 0.50 CU, the second fare item therefore ineffective. This is an
example for the following aspect:
7.5.1.2
Each ticket type has its own supplement regulations. These include PuT transport system
distance supplements and fixed supplements, whereas for the latter a transport system rank
can also be set. Furthermore, you can define a minimum fare for each transport system.
Supplements are imposed for each application independently. This also applies, when the
same ticket type is bought several times on one connection.
You can define supplements for all PuT transport systems of the network in each ticket type.
Of course, only the settings for those transport systems, whose lines are connected with the
fare system of the ticket type are effective, which means for passengers are able to use the
ticket type in the first place.
PTV AG
591
Minimum fare
The minimum fare for each transport system is charged instead of the calculated total fare for
the ticket type, in case
the transport system appears on the path legs covered by the ticket and
the total fare is less than the minimum fare.
The minimum fare is therefore not a component which can be added, but a minimum value for
the total fare which has to be charged. Because the regulation applies to all transport systems,
the most expensive minimum fare of all occurring transport systems, is the lower limit for the
total fare of the ticket type.
Below you will find a simple example on minimum fares (see "Example: Calculation of fixed
supplements" on page 592).
Fixed supplements
Fixed supplements are constant additional charges which are added to the base fare of the
ticket type. Each PuT transport system has its own fixed supplement. For which of the path
legs covered by the ticket type, a fixed supplement can be imposed, is a central feature of the
ticket type. Select one of the following options:
In the first case, exactly one fixed supplement is incurred for each occurring transport system
- independent of how many path legs are being used with lines of the transport system.
In the second case, the ranks of the transport systems from the supplement regulations of the
ticket type, play a role. Using the ranks, you can express that a certain transport system (e.g.
ICE) discharges the passenger from paying fixed supplements for other transport systems
(e.g. IC). If several transport systems have the same rank, on the path legs covered by the
ticket type, the maximum fixed supplement of the top-ranking transport system applies. Ranks
do not influence distance-based supplements.
In the third case, a fixed supplement is imposed for each path leg anew, for the transport
system used.
The difference between the three options for imposing fixed supplements can be made clearer
with the following example:
Rank Distance-based
supplement
IC
4.00
0.00
No
ICE
0.00
7.00
Yes
RE
0.00
0.00
No
592
Fare [CU]
50
0.50
100
1.00
PTV AG
Fare [CU]
200
2.00
300
3.00
400
4.00
500
5.00
600
06:00
> 600
7.00
The considered calculation contains four path legs: IC, RE, IC and ICE. The following tables
show the calculation of the fare for the three different options for imposing fixed supplements:
1. Supplement once per transport system:
Path legs of the
connection
Fare points
IC
50
Fixed
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
4.00
0.00
0.00
RE
200
0.00
0.00
0.00
IC
100
(*) 0.00
0.00
0.00
0.00
(**) 0.50
(***) 7.00
4.00
0.50
ICE
50
Sum
400
4.00
Total fare
8.50
(*) 0.00 CU, because the IC supplement was already imposed on the first path leg.
(**) 0.50 CU both for additive and proportional calculation of the distance supplement
(see "Distance-based supplements" on page 594).
(***) The minimum fare of 7.00 CU no longer has an effect, because the regular fare of
8.50 CU is higher.
2. Supplement only for the top-ranking transport system:
Path legs of the
connection
Total fare
Fare points
Fixed
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
IC
50
(*) 0.00
0.00
0.00
RE
200
0.00
0.00
0.00
IC
100
(*) 0.00
0.00
0.00
ICE
50
0.00
0.50
7.00
Sum
400
0.00
0.50
4.00
(**) 7.00
(*) Only the fixed supplement of the top-ranking transport system (ICE) is obtained,
even if in this case it is 0.
(**) The ICE minimum fare is imposed, because the ICE is used and the regular fare of
4.50 CU is lower than the ICE minimum fare.
3. Supplement per path leg:
PTV AG
593
Fare points
Fixed
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
IC
50
4.00
0.00
0.00
RE
200
0.00
0.00
0.00
IC
100
(*) 4.00
0.00
0.00
ICE
50
0.00
0.50
(**) 7.00
Sum
400
8.00
0.50
4.00
Total fare
12.50
Distance-based supplements
Each PuT transport system has its own fare stage for distance-based supplements. They are
calculated exactly like distance-based base fares, therefore based on the number of fare
points. The number of fare points for each transport system, is only summed up across those
path legs which belong to lines of the transport system. Distance-based supplements are also
added to the base fare of the ticket type.
There are two variants, on how distance-based supplements can be read from the fare table of
the distance stages:
proportional calculation
additive calculation
This setting is a ticket type property. For proportional calculation, the distance supplement valid
for the sum of fare points over all path legs is taken from the fare table and then multiplied with
the relative proportion of fare points of this transport system. The additive calculation is easier
- the distance supplements for the number of fare points of the transport system are directly
imposed for each transport system.
The following calculation example compares the two options:
On a connection, 100 fare points are traversed using ICE and 50 using IC. The distance-based
supplements are as follows:
Number of fare points (FP)
IC supplement [CU]
<= 50
3.00
2.00
<= 100
4.00
3.00
<= 150
5.00
3.50
594
PTV AG
50 FP
100 FP
= ------------------ 5, 00 CU + ------------------ 3, 50 CU = 4, 50 CU
150 FP
150 FP
Distance supplement for additive calculation:
Supplement ICE ( FPICE ) + Supplement IC ( FP IC ) = 4, 00 CU + 2, 00 CU = 6, 00 CU
7.5.2
Fare systems
A fare system is a set of lines which have the same fare logic. In principle the passenger can
therefore use these lines with one ticket. A fare system could for example be an individual
operator or a transport association.
One or more ticket types are allocated to each fare system for each PuT demand segment.
The fare system rank plays a role when lines belong to several fare systems, as can be seen
in several examples subsequently (see "Procedure for ambiguous fare systems" on page 600).
7.5.2.1
The most important fare system property is determining how far an individual ticket is valid.
This may be an individual path leg, i.e. a new ticket has to be bought for each boarding. A
second possibility would be that a ticket is valid for successive path legs within a fare system,
and a new ticket only has to be bought when leaving the fare system and entering it again.
Thirdly, a ticket may be valid for all path legs of a connection, which belong to the same fare
PTV AG
595
system - even if path legs of other fare systems lie in between. All three cases are practicerelated.
The central fare system attribute Fare reference is used to model this aspect and can assume
one of the following values:
Each path leg separately: A ticket has to be bought for each path leg of the fare
system.
Each group of contiguous path legs: A ticket has to be bought for each group of
contiguous path legs of a fare system.
All path legs together: For all path legs together, i.e. for the whole trip, one ticket is
sufficient for this fare system.
Path legs which belong to another fare system, can never be used with the same ticket.
Even if the fare structure has been simplified, this example clearly shows, how the total fare
changes subject to the fare-reference. Due to the fare reference, the following fares apply for
the connection:
Fare refers to...
Path leg TSys
Fare system
Each group of
contiguous path legs
1 Bus
City
60
(Short-distance)
100
2 Tram
City
100
3 Train
Rail
200
200
200
4 Bus
City
100
100
no extra fare
460
400
300
Fare sum
In the first case the passenger pays for each path leg in the fare zone "City" individually
and only for the first path leg is he allowed to use the short-distance ticket, because all
other path legs have an operating time of more than 10 minutes.
In the second case the successive path legs 1 and 2 can be used with the same ticket.
Only in the third case do you only pay once for the entire fare zone "City".
The third path leg is ignored, because the "Train" belongs to a separate fare system.
The example of start and transfer fares are supplemented:
596
PTV AG
FS City
FS Rail
Initial fare
100
200
50
-20
80
Both fare systems therefore require an initial fare as a base value at trip start. Transfers within
the same fare system cost 50 CU as additional charge for "City", for "Rail" no extra costs are
charged. For a transfer from "Rail" to "City" an additional amount of 80 CU is charged, vice
versa however, there is a discount of 20 for a transfer from "City" to "Rail".
The table below displays the initial and transfer fares, which are added to the base fares listed
above:
Fare refers to...
Path leg TSys
Fare system
1 Bus
City
100
Each group of
contiguous path legs
100
2 Tram
City
50
3 Train
Rail
-20
-20
-20
4 Bus
City
80
80
no extra fare
Sum of initial
and transfer
fares
210
160
80
Fare sum
(see above)
460
400
300
Total fare
670
560
380
Even if the example is simple, you can see what great influence the "Fare-reference" has on
the fare calculation and thus on the fare itself. It is therefore very important to define it
according to the real fare conditions of the modeled network.
7.5.2.2
In reality the ticket can not always be selected freely even if in principle several ticket types
can be applied because there is usually a predefined order. This order is modeled in Visum
by the rank of ticket types. It defines the hierarchy of the ticket types within the fare system.
Taking the above example let's look at the case of an individual fare system, which has three
different ticket types:
1. Fare condition descriptions:
PTV AG
597
Normal fare
The fare of the ticket type depends on the number of traversed fare zones as
follows:
1 fare zone: 2.00 CU
2 fare zones: 3.00 CU
3 fare zones: 3.50 CU
4 or more fare zones: 4.00 CU
Airport ticket
All trips into or out of the special zone Airport are subject to a exception. They
constantly cost 3.75 CU, independent of the fare zone at the other end point
of the path.
Short-distance
fare
For all trips up to ten minutes run time, a short-distance ticket can be used for
the fare of 1.00 CU. These do not include trips from or to the airport.
2. Modeling in Visum:
To model these fare conditions, the three ticket types have the following properties:
The airport ticket has the highest rank (for example 1), because it has to be used in all
cases where it can be applied (for all trips from and to the airport)
The airport ticket is a From-to zone-based fare, because the fare only depends on initial
fare zone and target fare zone of the connection. In this fare matrix however, only those
relations whose start or destination fare zone is the airport, are occupied. Other entries
do not exist, which shows the restricted applicability.
The short-distance ticket has the next higher rank (for example 2), because for all trips
outside of the airport, it is always bought when it is applicable. A maximum duration of
10 minutes is stipulated. There are however no threshold values for trip distance or
number of stops.
The normal (zone-based) fare has the lowest rank (for example 3). In principle the ticket
can always be used, because the number of traversed zones provides a definite fare.
The lower rank however, forces this ticket not to be used in the special cases airport trip
or short-distance, but one of the other two.
598
PTV AG
7.5.2.3
In the standard case, all fare systems are independent, so that the total fare for a connection
is the sum of fares per fare system. Transfer fares allow modeling of interactions. Like the initial
fare, they are added to the ticket type's basic fare for the fare system.
The initial fare is only imposed for the first path leg and depends on the fare system of the first
path leg. The transfer fare is calculated for each transfer, where a new ticket has to be bought.
It depends on the fare systems of the lines, where the transfer is made.
Both components can be negative for modeling deductions. The resulting total fare of a
connection is however greater or equal to zero.
Example:
Initial and transfer fares (see ""Fare reference" of a fare system" on page 595)
7.5.2.4
Fare weights
For the fare computation it is assumed that passengers have full knowledge of all fare systems.
Thus, the minimum fare will be selected, if several fares applied to the connection taking the
fare system ranks into account. Fare weights can be used to model restrictions to the
assumption above. This is achieved by computing a 'perceived' fare for the alternatives on the
basis of the fare weight. The perceived fare will only be regarded for the selection of the real
fare.
Example:
Trip from C Town to A Town, part 3 (see "Procedure for ambiguous fare systems" on
page 600)
7.5.3
Fare calculation
The total fare of a PuT connection is generally equal to the sum of fares for the individual fare
systems, which occur on this path. Interactions can only be considered through transfer fares
(see "Transport system-specific supplements" on page 591).
Decisive is "those which occur on this path". If the fare system per path leg is clear, i.e. each
used line (or the PuT supplement transport systems) belongs to exactly one fare system, fare
calculation is split into separate blocks and the calculation within a block is carried out as
described before (see "Ticket selection in a fare system" on page 597).
This is also the case for the above example on "fare-reference", because the fare for the train
line is completely independent of the fare calculation for the other three path legs (see
"Example: Fare system properties "Fare reference"" on page 596). In such a simple situation,
there is only one possible fare system combination, in step 1 of the algorithm on fare
calculation (see "Algorithm on fare calculation" on page 603).
The general case of several possible fare systems per path leg, however, requires an
extension of the previously described modeling.
PTV AG
599
7.5.3.1
If lines belong to several fare systems, many possibilities will potentially occur for the selection
of fare systems (and therefore tickets) on a connection. The following examples show typical
situations, where such multiple-allocation is necessary.
To systematically compare and determine all possibilities, fare systems also receive ranks,
which expresses a specified order. First however, an example which does not need any ranks:
Example: Fare calculation for ambiguous fare systems, trip to C Town, part 1
Let's consider the following path legs:
From
To
Line (TSys)
Fare system
Bus 42 (Bus)
City
B Town
Regional train
City or Rail
B Town
C Town
Intercity
Rail
It is assumed, that on the middle path leg both City and Rail ticket types can be used, in
particular all stops up to and including B Town belong to fare zones of the fare system City.
The total path can therefore be used in two different ways (fare systems City-City-Rail or fare
systems City-Rail-Rail), and the passenger selects the inexpensive one of the two.
Note: In each of the two variants the regional train ticket may also apply for the path leg directly
before or after the used line exactly then when the "fare-reference" of your fare system (City
or Rail) is "Each group of contiguous path legs" or even "All path legs together". This aspect is
however, not subject of the example
If no ranks are assigned to the fare systems, all fare systems have the default rank 1, and there
is no hierarchical order. All possibilities have to therefore be examined and the most
inexpensive used, which is what this example wants.
Example: Fare calculation for ambiguous fare systems, trip only to B Town
Let's now look at the case, that the trip already ends in B Town:
From
To
Line (TSys)
Bus 42 (Bus)
City (#1)
B Town
Regional train
The validity range of the fare system City is not left and we assume, that the regional train in
this case, is only allowed to be used with tickets from this fare system. This even applies, if it
were more inexpensive to buy a Rail ticket from the main station.
To model this ranking in Visum, the fare system City must have a higher rank (for example 1),
than the fare system Rail (for example 2). Within the fare calculation the fare systems are
regarded in descending rank order and the highest ranking used, which is applicable. Because
for the rank 1 fare system a valid ticket already exists in this example, the rank 2 variant is not
even reviewed.
600
PTV AG
Example: Fare calculation for ambiguous fare systems, trip to C Town, part 2
What does this definition of ranks now imply for the previous example, where explicitly both
fare systems could be applied for the regional train line?
From
To
Line (TSys)
Bus 42 (Bus)
City (#1)
B Town
Regional train
B Town
C Town
Intercity
Rail (#2)
Compared to the case, that the trip ends in B Town, it is not possible to use the entire
connection within the prior-ranking fare system City, because the intercity to C Town is not
included. A rank 2 fare system is therefore inevitable on this path. This is the starting point for
a definition of ranks of fare system combinations, which enable maximum flexibility when
modeling such fare conditions.
Note: The rank of a combination of fare systems T = {t1, t2,, tn} is defined as the maximum
rank of one of its fare systems: Rank(T) := maxiRank(ti).
With this specification one obtains an order on the set of all fare system combinations.
This means in the course of fare calculation, Visum regards all of them and selects the most
inexpensive total fare. Only if there are no valid combinations for a rank, will the combinations
of the next lowest rank be considered.
The global fall-back fare is only applied if no valid combination exists. This can be assigned
with a value such as -1, to easily identify paths without valid ticket(s) after an assignment. If
fares incur an assignment in the impedance definition, please note that a higher fall-back fare
(e.g. 99999) prevents paths without a valid ticket(s) from being found and loaded.
In the example, fare system combinations City-City-Rail and City-Rail-Rail are possible. Their
ranks are the same, because max {1, 1, 2} = 2 and max {1, 2, 2} = 2. That is why none of the
two are prior-ranking; the passenger in the regional train is therefore not fixed to the fare
system City.
By allocating rank 1 for fare system City and rank 2 for fare system Rail, it was overall achieved
that the regional train within the City network can only be used with City tickets, but for trips
across the network boundaries, it can also be used within the Rail fare system.
Example: Fare calculation for ambiguous fare systems, trip from C Town to A
Town bus terminal, part 3
As in the previous example, for the trip in the opposite direction the same combinations of the
same rank are returned from which the fare with the most favorable total fare is chosen. It is
assumed, that a combination costs 35 (Rail) plus 5 (City-City), i.e. 40 , whereas the other
variant costs 40 (Rail-Rail) plus 2 (City), i.e. 42 . On the basis of the previous assumptions
it follows, that the fare for Rail-City-City is chosen. This choice presumes the pedestrians' full
knowledge of all available fares. In reality, however, this is not always the case. Particularly it
can be assumed, that visitors and other groups do not have detailed knowledge of regional
fares like the City fare in our example, whereas the supra-regional Rail fare is well-known. To
model, for example, that a passenger uses a certain fare system (which is Rail in the example)
for a trip section which is as long as possible, the fare is weighted for the selection on the fare
PTV AG
601
system level. This weight helps to determine a "perceived" fare, which is the basis for the
selected fare. In other words, fare weights of 1 for the fare system Rail and 10 for City will
change the choice, thus the fare Rail-Rail-City will be favorable (perceived fare is 40+20=60
compared to 85 for Rail-City-City).
Example: Fare calculation for ambiguous fare systems, trip to C Town, part 4
Let's now look at the variant, that the regional train itself goes to C Town:
From
To
Line (TSys)
Bus 42 (Bus)
City (#1)
C Town
Regional train
In this case it looks as if exactly like for trips to B Town the exclusive use of the City fare
system is forced. However, this only applies if the City ticket can be bought up to C Town, if
therefore all stops including C Town lie within fare zones which belong to the zone-based fare
of the City fare system. If this is not the case, the attempt to use the connection with fare
systems of rank 1 fails, and fare system Rail is applied on the second path leg.
This makes it clear, that the affiliation of a line not automatically indicates, whether it can be
used on its entire itinerary with tickets of this fare system. An even clearer example is the
following:
For trips on the regional train line within a fare system, ticket types of this fare system are
mandatory. This also applies, if parts of the fare system area are traversed, which cover a
different fare system. For trips across the boundaries of a fare system, however, ticket types of
the fare system Rail long-distance definitely have to be used.
This regulation still leaves the open question, which ticket type to buy, if one entirely travels in
the covered section of two fare systems. The following regulation applies in this situation: In the
covered sections of fare system 2 with fare system 1 and with fare system 3, the latter has
precedence.
2. Resulting modeling of the ticket type in Visum:
602
PTV AG
Because the line can at least be partially used in all five fare systems, it has to be allocated to
all fare systems. To express the precedence of fare systems 1 and 3 against fare system 2 in
the covered sections of the fare zones, both must have a higher rank (for example 1), than fare
system 2 (for example 2). The rank of fare system 4 is not important, it can be set to 3. The non
zone-based fare system 5 (Rail long-distance) must have the lowest rank (for example 5),
because each of the four zone fare systems have precedence, if a trip takes place within it.
These ranks have a desired effect on the selection of the ticket type(s) through the following
model:
Each zone-based fare system has a specific fare zone type, for example 1, 2, 3 and 4, and
corresponding ticket types with fare structure zone-based fare. The spatial overlap of zone fare
systems arises in the overlap of their fare zones. All stops served by the line, thus lie exactly in
one fare zone or in two fare zones of different types.
This is how you achieve, that each of the zone-based ticket types can only be used, if all
traversed stops lie within fare zones which belong to the fare system of the ticket. Two ticket
types can only be used in the covered range of the fare systems and there the fare system
ranks provide specified preference. The fare system "Rail long-distance" is used as a fall-back,
because a valid ticket can be bought for this one in any case.
7.5.3.2
The succession of all decisions which lead to the selection of the ticket(s) used on a path, can
be formulated as an algorithm. This particularly clarifies the meaning of the ranks for fare
systems and tickets.
Each path consists of a sequence of path legs. Each path leg has one PuT line which is
connected to one or more fare systems (or a PuT-Aux transport system which is also allocated
to fare systems). The algorithm on fare calculation is as follows:
1. Determining fare systems:
Go through all possible fare system combinations for the different path legs, i.e. in
descending ranking order (whereas Rank of the combination = Maximum rank of the fare
systems in the combination). Calculate the fare for each combination according to step 2.
Select the lowest fare from the fare system combinations of the same weighted rank.
Compared to the fare, for the weighted fare, the fare weight for each fare system is
considered. If all fare systems of a rank are invalid, consider the combinations of the next
rank. If there is no valid fare system combination, the global fall-back fare applies.
2. Analysis of a fare system combination:
If fixed fare systems are provided for all path legs, iterate over all fare systems used and
calculate their fares according to step 3. If all calculations lead to a valid fare, the sum is a
valid fare for the total path. If not, this fare system combination is invalid.
3. Consideration of a fare system on all path legs allocated to it:
According to the fare system attribute Fare reference, determine for which subsets of the
fare system path legs separate ticket types have to be used. Iterate over all these path leg
subsets and calculate their fares according to step 4. If all calculations supply a valid fare,
the sum is a valid fare for the fare system. If not, fare calculation for this fare system fails.
4. Consideration of a fare system of a path leg subset:
PTV AG
603
For a fare system and a predefined path leg subset, iterate over all ticket types which are
used by the fare system, in descending order. Calculate the fare for each ticket type
according to step 5. From the ticket types of the same rank, select the one with the lowest
fare. If all ticket types of a rank cannot be used, consider the ticket types of the next rank.
If there is no applicable ticket type, the fare system is not permitted on this path leg subset.
5. Consideration of a ticket type on a path leg subset:
Calculate the base fare according to the fare structure of the ticket type (Distance-based
fare, Zone-based fare, From-to zone-based fare, Short-distance fare). If the fare table does
not contain a valid entry, the ticket type cannot be applied. Add up the initial fare for the first
path leg of the path. Add up the transfer fare according to the fare system which was used
on the preceding path leg.
If distance-based supplements have been activated for the ticket type, calculate and add
the distance-based supplement for the counted number of fare points. If the supplement
table does not contain an appropriate entry, the ticket type cannot be applied. Determine
and add up the fixed supplement. Compare the total fare with the minimum fares of all
occurring transport systems and raise it if necessary.
7.5.4
Application of fares
With a fare model, fares can be taken into account in both the headway-based assignment and
the timetable-based assignment procedures. Alternatively, you can model a linear
dependence in terms of fare points measuring the traversed distance for the headway-based
assignment.
The following skim matrices can be derived from both PuT assignment types:
Fare
Number of traversed fare zones
Please note that the skim "Number of fare zones" only counts those fare zones, which are
relevant for determining the fare. If a ticket has priority (or is cheaper with the same rank),
which has a different fare structure other than a "zone-based fare", fare zones on path legs of
this ticket do not play a role and are not counted for the skim. This is necessary, because
several fare zone systems, separated by type, may exist next to each other and each ticket
type applies to fare zones of one type at the most. "The" number of fare zones does not exist.
After an assignment you can access the ticket type used for each path leg, via the "PuT path
legs" list and analyze both the fare and the revenue for each path leg.
The difference between fare and revenue is, that fares always refer to the Visum fare model,
revenues however can be calculated alternatively as a fixed revenue per passenger trip or as
a revenue per fare point.
Fares from the fare model can also be used as input data for Revenue calculation within the
PuT operating indicators (see "Revenue calculation using the fare model" on page 636).
604
PTV AG
7.6
General indicators
Indicators for the measurement of transport supply
Indicators for the measurement of transport performance
Indicators for the calculation of operating costs
Indicators for the calculation of fare revenues
Indicators for vehicle requirement and line blocking (see "Line blocking" on page 532).
The indicators are described in the indicator categories. The following file lists the network
objects you can calculate indicators for: IndicatorAvailability.xls, in the directory ...Program
files\PTV Vision\PTV Visum 13\Doc\Eng of your Visum installation.
Dependent on the indicator, different procedures have to be carried out, to calculate the
indicator values. Some indicators are already available after a PuT assignment, others after
the procedure PuT operating Indicators has been executed with certain settings. Furthermore,
it also depends on whether indicators are calculated on the line hierarchy or for territories. The
IndicatorSource.xls file, in the directory ...Program files\PTV Vision\PTV Visum 13\Doc\Eng of
your Visum installation, contains an overview of the indicators, the procedures used to
calculate them, and the calculation settings required. Basically, the following procedures are
relevant for the calculation:
The indicators are basically calculated for analysis period, analysis horizon and analysis time
intervals (provided that analysis time intervals are defined). There are however exceptions,
where there is no calculation for analysis time intervals. This is characterized in the indicator
table (IndicatorAvailability.xls) as follows:
7.6.1
PTV AG
605
Illustration 193: Example network with two lines and volume data
Transport Supply
The transport system of the demonstration example consists of two lines with two line routes
per line (outward and return line routes), but partially shortened trips.
Line
Orig.
Stop
Dest.
Stop
Length
[km]
First
dep.
tCur
[min]
Last
dep.
Run
time
[min]
Number
of trips
Valid day
BUS >
10
40
27.5
06:07
a.m.
00:40
06:07
p.m.
00:45
19
daily
BUS <
40
10
27.5
06:02
a.m.
00:40
06:02
p.m.
00:45
19
daily
BUS >
30
40
7.5
05:37
a.m.
00:40
05:37
p.m.
00:13
19
weekdays
BUS <
40
30
7.5
06:29
a.m.
00:40
06:29
p.m.
00:13
19
weekdays
TRAIN >
20
40
10.0
06:29
a.m.
00:40
06:29
p.m.
00:16
19
daily
TRAIN <
40
20
10.0
06:09
a.m.
00:40
06:09
p.m.
00:16
19
daily
606
PTV AG
daily
365
365
weekdays
260
260
Projection factor
PuT
365
Vehicles used
Vehicle type
Seat capacity
Total capacity
Standard bus
35
90
35
50
Train
200
400
Fare model
The fare model includes two fare zones, which have been assigned the following stops.
Number
Name
FZ100
FZ200
10
A Village
20
C Village
30
B Village
40
X City
X
X
Stop 30 (B village) is located exactly between fare zones FZ100 and FZ200, and is therefore
assigned to both fare zones.
PTV AG
607
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
Additionally, a supplement of 3.00 CU (currency units: for example, Euro, Pound, Dollar) is
required for each rail ticket.
Transport demand
The table 219 displays the number of passengers between the zones.
FromZone
ToZone
Line1
Line2
A Village
X City
Bus1
Train
Demand
2000
X City
A Village
Train
Bus1
2000
A Village
C Village
Bus1
C Village
A Village
Bus1
200
C Village
X City
Train
5000
X City
C Village
Train
5000
B Village
X City
Bus1
2000
X City
B Village
Bus1
200
2000
Sum
18400
Cost rates
Link costs
Track charge of 100 CU/km on railway track between stop 20 and stop 40, plus
depreciation charge of 100000 CU. All other links have a utilization fee of 10 CU/Km and
running costs of 20 CU in the analysis horizon.
Vehicle costs
Standard bus
Train
Service
Empty
Service
Empty
Service
Empty
300.00
200.00
300.00
200.00
700.00
500.00
5.00
5.00
5.00
5.00
10.00
10.00
7,000.00
7,000.00
20,000.00
608
PTV AG
7.6.2
Description
Line network
length (directed)
Sum of link lengths of the links traversed by line routes. Traverses a line route a link
more than once, it is only counted once.
Line network
length
(undirected)
Compared to the directed line network length, for links which are traversed in both
directions, only the undirected values (this means, the mean value from the lengths of
both directions) is counted. If the link is only traversed in one direction, the undirected
length corresponds to the directed length.
Network length
(directed)
Total length of links open to transport system. The length of both directions is included
in the calculation.
Network length
(undirected)
Compared to directed network length, for links the average link length (this means the
mean value from the lengths of both directions) is counted for both open directions.
Number of lines
The meaning of this indicator depends on the network object for which it is calculated.
Main lines take the number of lines into consideration, which belong to the main line.
PuT operators take the number of lines into consideration, which are operated by
the PuT operator.
Blocks take the number of lines into consideration, which are traversed on a block.
Links take the number of lines into consideration, which traverse a link.
Transport systems take the number of lines into consideration, which use this
transport system.
For zones / main zones, a line is regarded, if the zone is connected to a node with
a stop point, which is traversed by the line. No line trip has to serve the stop point
Stops take the number of lines into consideration, which traverse this stop. No line
trip has to serve the stop
Stop points take the number of lines into consideration, which traverse this stop
point. No line trip has to serve a stop point.
Additionally returns the number of lines for each transport system. Otherwise, the
indicator is analog to the number of lines.
Number of line routes of a line or number of line routes run by a vehicle combination
during a block.
Number of stop
points total
Number of stop
points 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.
PTV AG
609
Indicator
Description
Stops served
The meaning of this indicator depends on the network object for which it is calculated.
Territory PuT detail regards the number of served stops being located within a
territory polygon. Stops are not served, if none of the time profiles includes a stop at
one of the stop's stop points. Multiple stops within a stop are only counted once
Lines take the number of stops into consideration, which are traversed by a line.
This is independent of whether a stop at the respective stop point is intended in the
time profile or not
Line routes regard the number of served stops, which are traversed by the line
route. This means, that stops are not served, if no time profile contains a stop at one
of the stop's stop points
Time profiles take the number of stops into consideration, for which a stop is
intended for its stop points, in the TP
Vehicle journeys take the number of stops into consideration, where a vehicle
journey stops
Transport systems take the number of stops into consideration, which a transport
system traverses. This is independent of whether a stop (boarding or alighting) is
intended in the respective time profiles
Stop events
Number of stop events at stops within the territory polygon. All stop events at the stops
are counted. A trip is thus counted several times, if a trip stops at several stop points
within the stop. If a stop point lies in another territory than the respective stop, the stop
still counts for the stop in the territory. The number of stop events in the territory counts
for each vehicle journey and is aggregated for the other levels, if necessary. Different
from the indicator "Stop points served" trips are required. Otherwise stop events do
not count.
Start stop events Number of vehicle journeys, which start at a stop in the territory.
End stop events
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.
610
PTV AG
Indicator
Description
Number of PuT
departures
The meaning of this indicator depends on the network object for which it is calculated.
The indicator is especially interesting for time interval-related analyses, to determine
the departures within a certain time interval for example.
For main lines / lines it returns the number of vehicle journeys run by this line.
For line routes it returns the number of vehicle journeys run by this line route
For time profiles it returns the number of vehicle journeys using this time profile
For PuT operators it returns the number of vehicle journeys operated by this PuT
operator
For transport systems it returns the number of vehicle journeys operated with this
transport system
For stops it returns the number of vehicle journeys which stop for boarding. Stop
events at several stop points within the stop are counted repeatedly. If a stop is
traversed several times within a vehicle journey, the departures are also counted
repeatedly
For stop points it returns the number of vehicle journeys which stop for boarding.
Number of
In contrast to Number of PuT departures, the number of departures is returned by
departures-TSys transport system. Calculation is otherwise analog.
Number of PuT
arrivals
Number of vehicle journeys, which stop for alighting at the stop or the stop point.
Multiple stop events are counted several times for a stop.
Number of
arrivals-TSys
PTV AG
611
Indicator
Description
Number of
service trips
uncoupled
The meaning of the indicator depends on the network object for which it is calculated:
For a vehicle journey it is the number, how often this vehicle journey has been
carried out in the particular time slot (AH, AP, TI)
For vehicle journey items it is returned, how often this vehicle journey traverses the
respective vehicle journey item (crucial are start and end stop points of the vehicle
journey). It is irrelevant whether boarding or alighting is permitted
For time profiles, the number of vehicle journeys is returned which use the time
profile in the particular time slot
For time profile items, the number of vehicle journeys is returned which traverse the
time profile item in the particular time slot (crucial are start stop point and end stop
point of the vehicle journey). It is irrelevant whether boarding or alighting is
permitted
For main lines/lines/line routes, the number of vehicle journeys in the time slot is
returned
For the line route course, the number of vehicle journey services traversing the line
route item is returned (start and end stop point of the trip are decisive, it is irrelevant
whether boarding or alighting is permitted)
For territory analyses, the number of vehicle journeys which are carried out in the
territory in the time slot is returned. A vehicle journey is added to the territory, if at
least one stop of the vehicle journey lies within the territory The stop point location
is not crucial, but the stop location.
For PuT operators, the number of vehicle journey services in the time slot of the
operator's vehicle journeys is returned
For line blocks, the number of occurrences of vehicle journeys in the line block is
returned
For links, the number of services in the time slot of vehicle journeys which traverse
a link is returned. A link is regarded as if being traversed, if the vehicle journey
traverses more than 50 % of the link's length
For a transport system, the number of vehicle journey services in the time slot of
vehicle journeys using this transport system is returned
For zones, a vehicle journey counts for a zone, if the zone is connected via a node
which is the access node to a stop area, and if the vehicle journey stops at one of
the stop points of the same stop for passenger boardings/alighting
For a stop the number of vehicle journeys is returned which stop at the stop for
passenger boarding/alighting in the particular time slot. Multiple stop events at stop
points of the stop are counted several times
For a stop point the number of vehicle journeys is returned which stop at the stop
point for passenger boarding/alighting in the particular time slot
612
PTV AG
Indicator
Description
Number of
service trips
Number of
service trips
(vehicle
combination)
For PuTDetail evaluations this indicator only differs from the Number of service trips
uncoupled, if there are vehicle journeys with several vehicle journey sections and
these differ in terms of the vehicle combination. In contrast to Number of service
trips uncoupled the number of service trips is distributed to the vehicle journey
sections in this case. If vehicle journey sections differ only in terms of the valid days,
the values Number of service trips (vehicle combination) and Number of service
trips uncoupled will match. Therefore, the evaluation of this indicator is useful for
territory analyses only for levels in combination with xVehComb.
Number of
service tripsTSys
PTV AG
613
Indicator
Description
Is coupled
(Respective) time profile is coupled with another time profile (1) or not coupled (0).
Effectively
coupled
An effective coupling means the following: a vehicle journey, which is coupled with
another vehicle journey via its corresponding time profile, is really carried out (in other
words: at least one vehicle journey service is required for each of the coupled time
profiles, these vehicle journeys have to be active and require a valid 'valid day'. For a
valid valid day, the valid day is within the analysis period and both coupled vehicle
journeys are carried out on the same day).
Number of departures for analysis period = number of vehicle journeys, which depart on
Jan 02, 2006
For the bus, the number of departures (AP) = 76 (Trips no. 96 to 172)
For the train, the number of departures (AP) = 38 (Trips no. 58 to 95)
Number of departures for analysis horizon = Num Departures (AP) projection factor of
valid day
For the bus, the number of departures is calculated (AH) = 38 365 + 38 260 = 23750
For the train, the number of departures is calculated (AH) = 38 365 = 13870
Number of departures for analysis time period TI1 = Number of vehicle journeys, whose
departure time lies between 8 a.m. and 9 a.m.
For the bus, the number of departures results from (TI1) = 7 (Trip no. 99, 100, 119, 120,
138, 139, 157)
For the train, the number of departures results from (TI1) = 3 (Trip no. 61, 80, 81)
Number of service trips analysis time interval TI1 = number of vehicle journeys between
08:00 AM and 09:00 AM.
For the bus, the resulting number of service trips (TI) = 10 (Trip no. 98, 99, 100, 118, 119,
120, 138, 139, 156, 157)
For the train, the resulting number of service trips (TI) = 4 (Trip no. 60, 61, 80, 81)
614
PTV AG
7.6.3
Description
Service kilometers Kilometers traversed by vehicle journeys. Trip length via all vehicle journeys and
number of departures.
Section service
kilometers
Service time
Time required by vehicle journeys. Trip length via all vehicle journeys and number of
departures.
Section service
time
Compared to service time, the duration of each individual vehicle journey section is
added (as long as it lies within the analysis period). Also the dwell time between
adjacent vehicle journey sections is included.
Empty kilometers
Section empty
kilometers
Empty 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
Section operating
kilometers
Out-of-depot time
Section operating
time
Compared to operating time, the duration of each vehicle journey section is added
(as long as it lies within the analysis period).
Stop time
In contrast to a stop time, the stop times of overlapping vehicle journey sections are
counted multiple times.
Seat capacity
Sums up the number of seats of the vehicle combinations over all vehicle journey
sections of the object, for which the indicator is determined (e.g. lines). This attribute
is only available for the elements of the line hierarchy and for PuT operators and
transport systems.
Seat Kilometers
Seat Hours
PTV AG
615
Indicator
Description
Total capacity
Sums up the total seating and standing capacity of the vehicle combinations over all
vehicle journey sections of the object, for which the indicator is determined (for
example, lines). This attribute is only available for the elements of the line hierarchy
and for PuT operators and transport systems.
Total Capacity
Kilometers
Total Capacity Km = Section Service Km Total seating and standing capacity of the vehicle
combinations
Summed up over all vehicle journey sections.
Total Capacity
Hours
Total Capacity Hours = Section Service Time Total seating and standing capacity of the
vehicle combinations
Summed up over all vehicle journey sections.
Length
Length covered by the time profile items in the territory (attribute is only available via
Territory - PuT Detail, for level Territory x Time profile (x Vehicle combination) and
Territory X Vehicle journey (x Vehicle combination)).
Run time
Travel time used to cover the time profile items in the territory, (attribute is only
available via Territory - PuT Detail, for level Territory x Time profile (x Vehicle
combination)).
Mean Speed
Capacity PuT
Seats
Number of seats of vehicle combinations, which traverse this link, summed up over
all vehicle journey sections (Attribute is only available for links).
Capacity PuT total Total seating and standing capacity of the vehicle combinations, which traverse this
link, summed up over all vehicle journey sections and the number of departures
(Attribute is only available for links).
Number of
Vehicles (in
proportion to
length)
The number of vehicles which are - according to the current block version - required
for the reference object, (line, line route, etc.). The indicator value corresponds to the
number of blocks, which cover the vehicle journey sections of the reference object.
If a block covers vehicle journey sections of several objects, for the vehicle only the
proportion of the vehicle journey sections of the reference object is added to the line
length of all vehicle journey sections.
Number of
As above, but the addition to the reference object is instead carried out with the
vehicles (in
share of vehicle journey sections of the reference object in the service time of all
proportion to time) vehicle journey sections.
Service km for the analysis period = Number of trips (AP) Trip length.
For the bus it applies that ServiceKm (AP) = 38 27.5 km + 38 7.5km = 1,045 km +
285 km = 1,330 km
For the train it applies that ServiceKm (AP) = 38 10 km = 380 km
Service km for the analysis horizon = Service km (AP) Projection factor of the valid day
For the bus it applies that ServiceKm (AH) = 1045 km 365 + 285 km 260 = 455525 km
For the train it applies that ServiceKm (AH) = 380 km 365 = 138700 km
616
Service km for the analysis time interval TI1 results from summing up the km data from all
trip sections, whose respective line route items depart in this time slice
PTV AG
For the bus it applies that ServiceKm (TI1) = 113.75 km. The calculation is made clearer by
illustration 194.
For the train it applies that ServiceKm (TI1) = 3 10 km = 30 km (Trip numbers 61, 80, 81)
Seat km for the analysis period = ServiceKm (AP) Number of seats summed up over all
trip sections.
For the bus it applies that SeatKm (AP) = 1330 km 35 = 46550 km
For the train it applies that SeatKm (AP) = 380 km 200 = 76000 km
Seat km for the analysis horizon = Seat km (AP) Projection factor of the valid day summed
up over all trip sections.
For the bus it applies that SeatKm (AH) = 38 262.5 km 260 + 38 962.5 km 365 =
15,943.375 km
For the train it applies that SeatKm (AH) = 76000 km 365 = 27740000 km
For seat km in the analysis time interval TI, the calculation is analog to the service km
calculation (illustration 194).
For the bus it applies that SeatKm (TI) = 35 (27.5 + 3.75 + 15 + 12.5 + 5 + 27.5) km + 35
(7.5 + 7.5 + 7.5) = 3,981.25 km
For the train it applies that SeatKm (TI) = 30 km 200 = 6000 km
PTV AG
617
Service time for the analysis period = Num PuT Departures (AP) Times from Time profiles
For the bus it applies that ServiceTime (AP) = 38 45 min + 38 13 min = 2204 min = 36 h
44 min
For the train it applies that ServiceTime (AP) = 38 16 min = 608 min = 10h 8 min
Service time for the analysis horizon = Service time (AP) Projection factor of the valid day
summed up over all trip sections.
For the bus it applies that Service time (AH) = 38 45 min 365 + 38 13 min 260 =
752590 min = 12543 h 10 min
For the train it applies that Service time (AH) = 38 16 min 365 = 221920 min = 3698h
40 min
Service time for the analysis time interval TI: Calculation is done analog to the service
kilometer calculation (illustration 194).
For the bus it applies that service time (TI) = 45 min + 13 min + (5 km/10 km) 13 min +
12 min + (5 km/10 km) 20 min + 13 min + 13 min + (5 km/10 km) 20 min + 0 min + (5 km/
10 km) 12 min + 45 min + 13 min = 186.5 min = 3 h 10 min
For the train it applies that Service time (TI) = 3 16 min = 48 min
7.6.4
Description
Passenger
kilometers
(DSeg)
The link that passengers are driving with the PuT vehicle
Passenger kilometers = Passenger trips unlinked trip distance from Boarding to Alighting
stop
Passenger hours
(DSeg)
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
618
PTV AG
Indicator
Description
PTrips Unlinked
>2xTransfer
(DSeg)
Passenger trips with 3 or more transfers on their way from origin zone to
destination zone. This attribute is only available for the elements of the line
hierarchy.
PTrips Unlinked
with 0xTransfer
(DSeg)
Passenger trips without transfer on their way from origin zone to destination zone.
This attribute is only available for the elements of the line hierarchy.
PTrips Unlinked
with 1xTransfer
(DSeg)
Passenger trips with exactly one transfer on their way from origin zone to
destination zone. This attribute is only available for the elements of the line
hierarchy.
PTrips Unlinked
with 2xTrans
(DSeg)
Passenger trips with exactly two transfers on their way from origin zone to
destination zone. This attribute is only available for the elements of the line
hierarchy.
PTrips Unlinked
DSeg
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
Mean volume total capacity ratio = passenger kilometers / total capacity kilometers 100
(This attribute is only available for the elements of the line hierarchy.)
Boarding
passengers (DSeg)
Alighting
passengers (DSeg)
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)
PTV AG
619
Indicator
Description
PassThrough
PassThrough with
stop (DSeg)
Number of passengers with stop event. These are all passengers traveling with a
line which stops at this stop point, however, they neither board or alight here (This
attribute is only available for stops and stop points).
PassThrough
Number of through passengers without stop event. These are all passengers
without stop (DSeg) traveling with a line, which passes the stop point, but does not stop there.
(This attribute is only available for stops and stop points.)
PassTransfer
PassTransTotal
(DSeg)
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)
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.)
The value Passenger kilometers per analysis period is calculated as follows: PassKm(AP)
= Passenger trips trip distance from Boarding to Alighting stop
For the bus it applies that 2400 10 km(A<->C) + 2000 27.5 km(A<->X) + 4000
7.5 km(B<->X) = 109000
620
PTV AG
The value Passenger kilometers per analysis horizon is calculated as follows: PassKm(AH)
= PassKm(AP) Projection factor of the demand segment summed up over all demand
segments.
For the bus it applies that 109000 km 365 = 39785000 km
For the train it applies that 120000 km 365 = 43800000 km
Illustration 195: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m.
The value Passenger hours per analysis period is calculated as follows: PassHour(AP) =
Passenger trips Run time from Boarding to Alighting stop.
For the bus it applies that 2400 12 min + 2000 45 min + 4000 13 min = 2846 h 40 min
For the train it applies that 12000h 16 min = 3200 h
PTV AG
621
The value Passenger hours per analysis horizon is calculated as follows: PassHour(AH) =
PassHour(AP) Projection factor of the demand segment summed up over all demand
segments.
For the bus it applies that 2846 h 40 min 365 = 1039033 h 20 min
For the train it applies that 3200 h 365 = 1168000 h
The value Passenger hours per analysis time period TI is calculated as follows.
For the bus it applies that 255 h 55 min. The calculation can be taken from illustration 196.
7.6.5
622
PTV AG
Note: Please note that the reference period for costs and the reference period for revenues
have to match, in order to get reasonable cost coverage results. The revenues are calculated
for the assignment time interval. The attribute OD trips total indicates the number of
passenger trips in the assignment time interval; it thus varies according to the particular
assignment time interval. Thus, the revenues also vary according to the temporal position
and length of the assignment time interval. Cost calculation, however, refers to the analysis
period. As the assignment time interval often only consists of the peak hour (e.g. evening
rush hour from 4-6 p.m.), project the results to the analysis period when you want to calculate
cost coverage in your model or combine indicators calculated in the assignment with
indicators calculated in the procedure PuT operating indicators (file IndicatorSource.xls, in
the directory ...Program files\PTV Vision\PTV Visum 13\Doc\Eng). To create identical
reference periods, you have to define a projection factor from the assignment time interval to
the analysis period by demand segment (see User Manual, Chpt. 7.2, page 1215). The
projection factor 1 is only correct here, if you carry out an assignment for the whole day.
7.6.6
PTV AG
623
Kilometer costs /
Cost distance
Assigned fixed cost for a vehicle (debt service as well as other fixed costs such as
insurance costs).
Vehicle costs = cost rate per vehicle unit number of vehicles
The number of vehicles is an output attribute of line blocking.
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).
Three cost rates which are included in the calculation of stop point costs (see
"Stop point cost" on page 628).
Costs for the usage of links (infrastructure cost) The link costs are divided equally
between the vehicle journeys which use the link.
Three cost rates which are included in the calculation of link costs (see "Link
costs" on page 626).
Operator costs /
Cost operator
Costs 1/2/3
operators
Three cost rates which are included in the calculation of operator costs (see
"Operator cost" on page 629).
The total costs which accumulate for operating public transport, are returned in the following
attribute.
Total cost
Cost
Costs = time costs + distance costs + vehicle costs + stop point costs + link costs + operator
costs
7.6.6.1
The costs for a vehicle is composed of hourly costs, kilometer costs and fixed costs. In Visum,
these costs are assigned to vehicle units (see User Manual, Chpt. 7.2.2, page 1216). In
practice these kilometer and vehicle costs are dependent on the vehicle type used (for
example standard or articulated bus, or tram in single or multiple traction) and the hourly costs
of the operator (for example public or private operator, type of labor contract).
624
PTV AG
The attribute Cost rate per vehicle unit contains the fixed costs for each vehicle unit (the
acquisition costs for example). Fixed costs increase with every additional vehicle
required.
The value Number of vehicles results from the necessary vehicle blocks. Line blocking
is therefore assumed for the calculation of vehicle costs.
Standard bus
Train
Service
Service
Service
Empty
Empty
Empty
300.00
200.00
300.00
200.00
700.00
500.00
5.00
5.00
5.00
5.00
10.00
10.00
7,000.00
7,000.00
20,000.00
Analysis period
Analysis period
Analysis period
PTV AG
625
Vehicle combinations
Standard bus
Service
Empty
Service
Train
Empty
Service
Empty
0.00
0.00
0.00
0.00
50.00
50.00
0.00
0.00
0.00
0.00
0.00
0.00
ServiceKm
EmptyKm
380 km
0 km
Service time
Empty time
10.13 h
0h
Table 229: Distances and times for the vehicle combination Train in the analysis period
Calculating the vehicle type-dependent costs (distance costs, time costs and vehicle costs) for
lines returns the following result for the Train line.
Distance costs / analysis period
CostDist(AP) = CostKmService ServiceKm(AP) + CostKmEmpty EmptyKm(AP)
CU
CU
= 10 -------- 380 km + 10 -------- 0 km = 3800 CU
km
km
Time costs / analysis period
CostTime(AP) = CostTimeService ServiceTime(AP) + CostTimeEmpty EmptyTime(AP)
CU
CU
= 750 -------- 10.13 h + 500 -------- 0 h = 7600 CU
h
h
Vehicle costs / analysis period
CostVehicle(AP) = Cost rate vehicle unit Number of vehicles
CU
= 20000 ---------- 1 Veh = 20000 CU
Veh
7.6.6.2
Link costs
Link costs are infrastructure costs, which accumulate when using a link. The link costs are
divided equally between the vehicle journeys which use the link. Up to three cost values
(attributes CostRate1_PuTSys - CostRate3_PuTSys) can be specified per link and transport
system to model link costs (see User Manual, Chpt. 2.14.7, page 283). For each of these three
cost values, one of the following cost types can be selected:
Depreciation costs, for example annual costs for depreciation and interest rates which
result from the investment cost for the link
Running costs, for example maintenance costs and operating costs
Utilization costs, for example fees for using stop points or tracks
Dependent on the selected cost type, the allocation of the costs to the individual vehicle
journeys is then carried out according to the formulas described below.
626
PTV AG
CostValue L, T q ( q 1 )
1 - ---------------with q = 1 + p/100
CostsLinkAP, L, T = ---------------------------------------------------------------------DT
FacTS
q 1
CostsLink AP, L, T
CostsLinkV, L, T = -----------------------------------------V
L, T
Cost type running costs
CostValue: for example annual maintenance costs for a link (link attributes CostRate1-PuTSys, also 2
and-3)
CostValue L, T
CostsLinkV, L, T = -------------------------------------- VL, T FacTS
Cost type utilization costs
CostValue: for example fees for using a link (link attributes CostRate1-PuTSys, also 2 and-3)
CostsLinkV, L, T = CostValueL, T
CostValueL, T
Cost value which is entered as attribute of the link. For running costs
the value can refer to AP or AH. Depreciation costs and utilization
costs can either be distributed to all vehicle journeys or allocated only
to vehicle journeys which end or start at this stop point (see User
Manual, Chpt. 7.3.2.5, page 1225).
CostsLinkAP, L, T
CostsLinkV, L, T
VL, T
FacTS
DT
Calculation example: Link costs for vehicle journeys in the analysis period
100000 CU
Interest rate p
7%
Depreciation time DT
10 years
365
19
PTV AG
627
100000 1.07
39.008 19 = 2.053
10
1
1
- ---------- = 39.008
0.07 -------------------------10
365
1.07 1
100 CU
Link lengths
5 km per link
Link length
Analysis horizon
365
Example for utilization costs (in the example, stored in attribute Link Cost 1)
100 CU
Length of link 4
10 km
km
Link Cost 1 for vehicle journey (in this example, it is 100 CU/km 10km = 1000 CU
constant for all vehicle journeys of the train)
7.6.6.3
Stop point costs are infrastructure costs which accumulate when using a stop point. The costs
are defined for each stop point. The costs are evenly distributed between the vehicle journeys
which allow boarding and alighting on this stop point. To model the costs, up to three cost
values (attributes Cost rate1 to Cost rate3) may be entered for each stop point (see User
Manual, Chpt. 2.26.2, page 425). For each of these three cost values, one of the following cost
types can be selected.
Depreciation costs, for example annual costs for depreciation and interest rates which
result from the investment cost for the link
Running costs, for example maintenance costs and operating costs
Utilization costs, for example fees for using stop points or tracks
Dependent on the selected cost type, the allocation of the costs to the individual vehicle
journeys is then carried out according to the formulas described below.
628
PTV AG
CostValue SP q ( q 1 )
1 - ---------------with q = 1 + p/100
CostsSP AP, SP = -------------------------------------------------------------------AD
FacTS
q 1
CostsSP AP, SP
CostsSP V, SP = ----------------------------------V
SP
Cost type running costs
CostValue: for example annual maintenance costs for a stop point (Stop point attributes CostRate1 to 3)
CostValue SP
CostsSP V, SP = ------------------------------------V
FacTS
SP
Cost value which is entered as an attribute of the stop point SP. For running
costs the value can refer to AP or AH. Depreciation costs and utilization costs
can either be distributed to all vehicle journeys or allocated only to vehicle
journeys which end or start at this stop point.
CostsSPAP, SP
Stop point costs of the stop point SP in the analysis period (AP).
CostsSPV, SP
Costs for a vehicle journey V which uses the stop point SP.
VSP
FacTS
The transport supply projection factor from AP to AH (see User Manual, Chpt.
2.42, page 645)
DT
7.6.6.4
Operator cost
Up to three cost values (attributes Cost rate1 to 3) can be entered for each operator. For each
of these three cost values, one of the following cost types can be selected.
Depreciation costs, for example investment costs (debt service for depot and offices)
Running costs, for example maintenance costs (maintenance for the depot and
administrative/sales costs).
To distribute operator costs to the vehicle journeys, which are operated by this operator, a
distribution key can be specified which consists of the following weighted indicators
PTV AG
With the values of any combination of these six attributes, you can thus distribute the operator
costs onto vehicle journeys. The weighting factors must amount to 100 % (see User Manual,
Chpt. 7.3.2.5, page 1225).
Distribution of operator costs O on a vehicle journey
The share of one vehicle journey V in the operator costs of its operator O is:
SeatKm V
ServKm V
Share V = ----------------------------------------------- WeightServKm + ------------------------------------------------ WeightSeatKm
SeatKm V
ServKm V
V FO
V FO
ServTime V
1
+ ---------------------------------------------------- WeightServTime + -------------------------------------------------------- WeightJourneys
NumberVehJourneys
ServTimeV
V FO
PassKmTrav V
+ ------------------------------------------------------------- WeightPassKmTrav
PassKmTrav V
V FO
PTripsUnlinked V
+ -------------------------------------------------------------------- WeightPTripsUnlinked
PTripsUnlinked V
V FO
CostValue O q ( q 1 )
1
- ----------------- with q = 1 + p/100
CostOpAP, O = -----------------------------------------------------------------DT
FacTS
q 1
CostOpV = CostOp AP, O Share V
Cost type running costs
CostValue O Share V
CostOpV = -----------------------------------------------------FacTS
ShareV
FO
CostValueO
CostOpAP, O
CostOpV
FacTS
DT
630
PTV AG
7500000 CU
Depreciation time DT
10 years
Interest rate
7%
365
10
25 %
27.5 km
1330km
25 %
962.5 km
46,550 km
50 %
2,495.0 km
109,000 km
962.5
2495
27.5----------- 0.25 + ---------------- 0.25 + -------------------- 0.5 = 0.022
46550
109000
1330
80,000 CU
Analysis horizon
365
80000
---------------- = 219.18
365
25 %
27.5 km
1,330 km
25 %
962.5 km
Table 237: Calculation example for the running costs of the operator
PTV AG
631
46,550 km
50 %
2,495.0 km
109,000 km
27 . 5
962 . 5
2495 . 0
------------- 0, 25 + ---------------- 0, 25 + -------------------- 0 . 50 = 0 . 022
1330
46550
109000
80000 0 . 022
------------------------------------- = 4.5 CU
365
Table 237: Calculation example for the running costs of the operator
7.6.7
The decision for one of these three possibilities depends on the model's desired level of detail,
the availability of input data and the planned work load for modeling the revenue calculation.
The three possibilities of revenue calculation in Visum are described below. For each
possibility, an example calculation is carried out using the application example data.
Independent of the selected type of revenue calculation, the following output attributes
(revenue indicators) are available.
Indicator
Description
Total revenue
Total revenue from fare revenues which apply to the network object.
Revenue-DSeg
Revenue by demand segment from fare revenues which apply to the network
object.
632
PTV AG
Indicator
Description
Revenue total
Total revenue from fare gains which applies to the territory and the selected level.
(length-proportional) Distribution is proportional to the link lengths of the traversed links.
Revenue-DSeg
Like revenue total (length-proportional), but only the revenue by demand
(length-proportional) segment.
Revenue total (fare
point-proportional)
Total revenue from fare gains which applies to the territory and the selected level.
Distribution is proportional to the number of traversed fare points on links and time
profile items.
Revenue-DSeg (fare Like revenue total (fare point-proportional), but only the revenue by demand
point-proportional)
segment.
Revenue
PTripUnlinked
Revenue PTripsUnlinked_DSeg
Revenue per demand segment / passenger trips unlinked per demand segment
Cost coverage %
CostCov total
Cost coverage per passenger trip = Cost coverage total / passenger trips unlinked
7.6.7.1
To estimate the revenues from ticket fares, a revenue amount per passenger trip can be
specified. In the following example, a fixed revenue of 4.00 CU per passenger trip is specified
and the revenue per line calculated. The distribution regards only the number of path legs (see
"Revenue distribution" on page 636). The following route table (PuT path legs) provides an
overview of all other indicators required, including the passenger trips.
From zone
To zone
Line
FromSPoint
ToSPoint Passenger
trips
A Village
(100)
X City
(200)
BUS1
10
20
Train
20
40
1,501
1501 4
--------------------2
4.00
1501 4
--------------------2
A Village
(100)
X City
(200)
BUS1
10
40
499
A Village
(100)
C Village
(201)
BUS1
10
20
200
PTV AG
633
BUS1
40
10
1,000
Train
40
20
1,000
4.00
1000 4
--------------------2
BUS1
20
10
4.00
1000 4
--------------------2
Train
40
20
5,000
BUS1
40
30
2,000
C Village
(201)
A Village
(100)
BUS1
20
10
200
C Village
(201)
X City
(200)
Train
20
40
5,000
B Village
(202)
X City
(200)
BUS1
30
40
2,000
Revenues per line then result from summation of the revenue shares for each line.
Line
Bus1
Train
7.6.7.2
If fare points have been defined for links or time profile items of the model, revenue calculation
can regard a fixed revenue per traversed fare point (see User Manual, Chpt. 7.5, page 1230).
In the following example, a revenue of 0.20 CU per fare point is specified. The route table (PuT
path legs) provides an overview of the calculation.
From To
zone zone
Line
100
BUS1
100
200
200
From
SP
To SP
NumFP
10
20
10
Train
20
40
20
BUS1
10
40
29
PTrips
1501
Fixed
revenue per
FP [CU]
0.20 1501 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2
0.20 1501 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2
499
0.20 499 29 0 . 2
634
PTV AG
100
201
BUS1
10
20
10
200
0.20 200 10 0 . 2
200
100
BUS1
40
10
30
1,000
0.20 1000 30 0 . 2
200
100
Train
40
20
20
1,000
0.20 1000 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2
BUS1
20
10
10
0.20 1000 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2
200
201
Train
40
20
20
5,000
0.20 5000 20 0 . 2
200
202
BUS1
40
30
10
2,000
0.20 2000 10 0 . 2
201
100
BUS1
20
10
10
200
201
200
Train
20
40
20
5,000
0.20 5000 20 0 . 2
202
200
BUS1
30
40
10
2,000
0.20 2000 10 0 . 2
0.20 200 10 0 . 2
Revenues per line then result from summation of the revenue shares for each PuT path leg.
Line
Bus1
Train
Fare points can be defined for links and also for time profile items. In the calculation of the
revenue share for each path leg, the sum of fare points at both of those network objects goes
in.
TW1
TW2
T W3
Path legs
Stop points
H1
H2
10
TP at links (NumTPs-TSys)
12
H3
H4
10
H5
10
21
13
PTV AG
635
7.6.7.3
The most precise variant of the revenue calculation is the one which is based on the Visum fare
model. To do so, fare systems and ticket types have to be defined and connected with the
network lines (see "PuT fare model" on page 582). A fare model provides a specific fare for
each PuT path.
Revenue =
Volume Fare
[CU]
Fare = Base
fare +
Supplement
[CU]
Supplement
for Train [CU]
One-way
ticket base
fare [CU]
Number of
fare zones
Passenger
trips
Path legs
To zone
From zone
The revenue is first calculated on PuT path level. The passenger trips (volume) of the path are
thus multiplied with the fare. The revenue is then distributed to the PuT path legs (see
"Revenue distribution" on page 636). With a zone-based fare, the following revenues result for
the paths in the example Example_LLE.ver.
A Village X City
Bus1
Train
1,000
3.00
3.00
6.00
6,000.00
A Village X City
Bus1
1,000
3.00
0.00
3.00
3,000.00
200
2.00
0.00
1.00
200.00
X City
A Village Bus1
1,000
3.00
0.00
3.00
3,000.00
X City
A Village Bus1
Train
1,000
3.00
3.00
6.00
6,000.00
X City
C Village Train
5,000
1.00
3.00
4.00
20,000.00
X City
B Village Bus1
2,000
1.00
0.00
1.00
2,000.00
200
1.00
0.00
1.00
200.00
C Village X City
5,000
1.00
3.00
4.00
20,000.00
B Village X City
Bus1
2,000
1.00
0.00
1.00
Total
2,000.00
62,400.00
7.6.7.4
Revenue distribution
Internally Visum first calculates the revenues for PuT paths. The revenues are then distributed
to the PuT path leg and then converted to the network object line hierarchy (lines, line routes,
etc.). You can influence the distribution of the revenues by the following parameters.
636
With Weight number of path legsyou can achieve an even distribution of the revenue over
all path legs. Each path leg receives the same revenue share, if the weight is 100 %.
With Weight number of fare points the distribution will be based on the ratio between the
number of fare points on the path leg and the number of fare points on the total path. Thus
you can achieve, that longer (in terms of the number of fare points) path legs receive a
greater portion of the revenues.
You can select any weighting between both distribution possibilities, number of path legs
and number of fare points.
PTV AG
When specifying Fixed amount per path leg, each path leg first receives a fixed sum of
the total revenue. The remaining revenue is then distributed to the path legs according to
the distribution rules mentioned above. If the sum of all of the fixed amounts exceeds the
revenue to be distributed, the fixed amounts are correspondingly reduced. If a fare model
is used, the supplements are not taken into consideration.
Note: Revenue distribution does not regard how the revenue was calculated (fare model,
fixed revenue per passenger trip or fixed revenue per fare point).
For revenue distribution the following formulas are applied
Share-FarePt = NumFarePt-PL / NumFarePt-Total
Share-PathLeg = 1 / NumPL
RevShare-PathLeg =(Share-FarePt W- NumFarePt + Share-PathLeg W-NumPL)
Rev-PathLeg = Rev-Fix + (Rev-PassTrip Rev-Fix NumPL) RevShare-PathLeg
NumPL
NumFarePt-PL
NumFarePt-Total
RevShare-PathLeg
W-NumFarePt
W-NumPL
Rev-PassTrip
Rev-Fix
Rev-PathLeg
W-NumFarePt + W-NumPL=1.0
The revenue distribution is also demonstrated with the example Example_LLE.ver. A zonebased fare model was modeled there and the calculation of the input data required for revenue
distribution already demonstrated (see "Revenue calculation using the fare model" on
page 636).
Revenue distribution is only carried out for those paths which comprise more than one path leg.
In the example, this is the path from A Village to X City, where 1,000 passengers use the bus
and the train, and back. As the number of path leg fare points is 10 for both the bus (A Village
C Village) and the train (C Village X Town), a distribution factor of 0.5 results in each case.
From origin zone
100 (A Village)
To destination zone
200 (X City)
Link 1: 5 (Bus)
Link 2: 5 (Bus)
Link 4: 10 (Train)
Share-FarePt(Bus1)
5 FP + 5 FP
------------------------------- = 0 . 5
20 FP
PTV AG
637
Share-PathLeg(Bus1)
1
--2
Revenue on Path 1
6000 CU
75 %
25 %
FP + 5 FP
1
5
------------------------------- 0. 75 + --- 0. 25 6000 CU = 3000 CU
20 FP
If you want to return the revenues on the line level, the following calculation thus applies.
Line
FromZone
ToZone
PTripsUnlinked
Fare
BUS1
A Village
X City
1,000
3.00
3,000.00
A Village
X City
1,000
6.00
1
6000 --- = 3000
2
A Village
C Village
200
1.00
200.00
B Village
X City
2,000
1.00
2,000.00
C Village
A Village
200
1.00
200.0
X City
A Village
1,000
3.00
3,000.00
X City
A Village
1,000
6.00
1
6000 --- = 3000
2
X City
B Village
2,000
1.00
2,000.00
X City
C Village
5,000
4.00
20,000.00
X City
A Village
1,000
6.00
1
6000 --- = 3000
2
C Village
X City
5,000
4.00
2,000.00
A Village
X City
1,000
6.00
1
6000 --- = 3000
2
Total
TRAIN
=16,400.00
Total
=46,000.00
Another calculation example illustrates the calibration options (especially the definition of a
fixed amount for each path leg). Let the following network be the example network.
S1
Bus 1
2 FP
S2
Train
6 FP
S3
Bus 2
S4
4 FP
Illustration 199: Example network for fixed amount per path leg
638
PTV AG
Passenger trips
12
Share-FarePt(Bus1)
2
------ = 0 . 167
12
Share-FarePt(Train)
6
------ = 0 . 5
12
Share-FarePt(Bus2)
4
------ = 0 . 333
12
Share-PL
1
--- = 0 . 333
3
Rev-PassTrip
3.00
Bus 1
Train
Bus 2
Bus 1
Train
Bus 2
Table 248: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.00
Path leg
Bus 1
Train
Bus 2
Table 249: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.20
When using a fare model (see "Revenue calculation using the fare model" on page 636), the
distribution of supplements can also be influenced. With the option Distribute supplements
to transport systems you have the following possibilities:
PTV AG
If the option is selected, the supplement charged for the transport system is only distributed
to the path legs which are traversed by this transport system. This is how the supplement
is only distributed to the path legs, where the long-distance train is used, for example for a
connection where a local train without supplement and a long-distance train with
supplement are used.
639
If the option has not been selected, the supplement is distributed to all path legs according
to the distribution key, independent of whether the transport system, for which the
supplement was defined, is used for this path leg. This is how a regional train also benefits
from the supplement for a long-distance train, for revenue distribution, for example.
An example illustrates the differences between both methods. There is only one fixed
supplement in the example. To make it easier, there is no distance-based supplement. The
base fare of the connection is 30.00 CU.
TSys
(#Rank)
Number of
fare points on
path leg
Distribution of
the base fare
[CU]
Fixed
supplement
[CU]
Transport system-based
supplement distribution
onto path legs [CU]
Distribution of the
supplement onto
all path legs [CU]
EC (#2)
100.00
10.00
7.00
(**) 3.50
IC (#2)
100.00
10.00
7.00
(**) 3.50
2.33
RE (#3)
100.00
10.00
0.00
0.00
2.33
30.00
(*) 7.00
7.00
7.00
Sum
2.33
(*) The fixed supplement of the top-ranking TSys (ICE) is only charged once, in this case
7.00 CU.
(**) The supplement of 7.00 CU is only distributed onto both transport systems EC and IC,
because they have the same maximum rank. If for example, the IC had a rank 3 and a fixed
supplement of 3.00 CU, the EC would obtain the complete supplement of 7.00 CU, when
taking the rank into consideration and distributing by transport system.
7.6.7.5
For cost coverage calculation, total revenues have to be compared with total costs. The
following output attributes are available.
Indicator
Description
CostCov total
For the application example, cost coverage data on line level is calculated as follows for Bus1
for example.
640
PTV AG
Total revenue
16400.00 CU
Cost
36321.86 CU
CostCov total
36321.86
---------------------------- 100 = 45.15 %
16400.00
8,400
-19921.86
------------------------------ = -2.37 CU
8400
7.6.8
7.6.8.1
Using projection factors, the analysis period values of indicators can be extrapolated to any
user-defined analysis horizon. If your analysis period is one day and a service trip runs every
day throughout the year, you can for example use a projection factor of 365 to calculate the
revenue for the entire year. If the service trip only runs on weekdays, you can select a
projection factor of 260. Depending on the indicator to be calculated, the projection factor has
to either be set for the valid day or for the demand segment (table 252).
Indicator category
Projection factor
Transport supply /
Valid day
General indicators
Transport supply
Projection factor
Hourly costs / Valid
day
Network performance
Costs (apart from Cost Time)
Cost Time
Projection factor by
DSeg
X
X
X
Revenues
Table 252: Which projection factor applies for the calculation of indicators?
PTV AG
641
The application example makes the difference between the projection factors on valid days
and those by the demand segment clear. For trip 135, passenger kilometers and service
kilometers are compared to each other.
Valid day
260
7.5 km
365
397.5 km
7.6.8.2
For the projection to the analysis horizon, the indicators of the transport demand (network
performance, revenues) as well as the indicators of the transport supply (operating supply,
costs) and the hourly costs are each projected with a different projection factor. This takes the
fact into account that the transport demand, for example at the weekend, can decline more
severely than the transport supply. At the same time, there are higher personnel costs, i.e.
higher hourly cost rates on Sundays.
The projection factors for transport supply and hourly costs can be specified for each valid day
separately. In this way, for an analysis period of one week in August, not only can the indicators
of regularly occurring Valid Days be correctly projected to an analysis horizon of one year (for
example, Mon-Fri with factor 52), but also seasonally restricted Valid Days (for example,
Sat+Sun during the school summer holidays by applying factor 6).
The projection factors for the extrapolation of the network performance from the assignment
time interval to the analysis period or horizon are set separately for each demand segment.
Therefore, the projection factor from the assignment time interval to the analysis period
regards the relevance of the OD matrix content for the demand segment.
If the assignment time interval and the period of validity of the matrix cover the entire
analysis period, this factor is then equal to 1.
If the assignment time interval is shorter than the analysis period, then the projection factor
corresponds to the ratio between the demand in the analysis period and the demand in the
assignment time interval.
If the demand time series of the demand segment refers to only a part of the assignment
time interval, then the projection factor corresponds to the ratio between the demand in the
analysis period and that of the demand time series time period.
The following example shows how this kind of calculation can be used to save computation
time in case of homogeneous demand.
Example
The analysis period and the assignment time interval should each cover one week (Monday to
Sunday). The timetable services from Monday to Friday are identical. For the "commuters"
demand segment the demand from Monday to Friday may be constant and the same time
642
PTV AG
series may be applied on weekdays, whereas on the weekend there is no demand in this
segment. The demand of this demand segment is coded in the OD matrix of one day in
combination with the time series for 24h, beginning Monday at 0:00. Due to the time series,
only the trips which start on Monday are charged during assignment. In order nevertheless to
indicate correct weekly values as PuT volumes per analysis period, the following projection
factors are applied to the "commuters" demand segment.
Projection from ... to ...
Factor
5 52 = 260
The following example of a vehicle journey with two sections (illustration 200) shows the
calculation of selected operating indicators for the following analysis time slices.
As shown in illustration 200 and table 254, vehicle journey section 1 is served daily, whereas
vehicle journey section 2 is available only on Sundays and public holidays.
8:00
7:00
6:00
0 km
1
10 km
20 km
2
30 km
s
Illustration 200: Time-distance diagram for a vehicle journey with two vehicle journey sections
VehJourney
Valid day
VehJournSect 1
VehJournSect 2
Daily
Sunday+Holiday
06:30 a.m.
Arrival
07:30 a.m.
Trip length
30 km
52
63
30 km
20 km
10 km
10 km
0 km
10 km
10 km
10 km
10 km
0 km
10 km
200
100
Seat capacity
Table 254: Further specifications for the vehicle journey with two VJ sections
PTV AG
643
The table 255 shows the calculation of the seat kilometers. This is done by multiplying the
seating capacity by the service trip length and then simply adding up the vehicle journey
section data.
Analysis period Mon-Sun
VehJournSect 1
VehJournSect 2
Sum
30000 km
Analysis horizon
VehJournSect 1
28000 km 52 = 1456000 km
VehJournSect 2
2000 km 63 = 126000 km
Sum
1582000 km
VehJournSect 2
100 seats 0 km =
Sum
0 km
2000 km
Compared to seat kilometers, the calculation of service kilometers (often termed load
kilometers or train kilometers) by simply adding up the vehicle journey sections is not
permitted. In this case, it must be realized that superimposed vehicle journey sections may
only be counted once. This is particularly important for the calculation of any track costs
derived from the service kilometers. Track costs are calculated on the basis of service
kilometers regardless of the train composition. In the projection to the analysis horizon,
however, different projection factors may arise for the vehicle journey sections. In this case a
maximum formation is taking place. In the example shown in table 256, this is the case on
Sunday. The calculation of the service time is carried out in the same way.
Analysis period MonSun
Analysis horizon
Monday
20 km 1
20 km 52
10 km 0
Tuesday
20 km 1
20 km 52
10 km 1
Wednesday
20 km 1
20 km 52
10 km 0
Thursday
20 km 1
20 km 52
10 km 0
Friday
20 km 1
20 km 52
10 km 0
Saturday
20 km 1
20 km 52
10 km 0
10 km 1
+ 10 km 1
+ 10 km 1
10 km 52
+ 10 km MAX(52;63)
+ 10 km 63
20 km 0
150 km
8,020 km
10 km
Sunday
Sum
644
PTV AG
7.6.8.3
Based on the value calculated by vehicle journey section, Visum internally sums up all
indicators along the line hierarchy. Here, internally means that the user cannot view all
indicators on the vehicle journey section level. This is due to the memory which is required for
the data storage). This also applies to indicators are evaluated by territory or time slice.
For operators, aggregation is also carried out via the vehicle journey sections (because as an
option, each vehicle journey section can be assigned an operator). For the aggregation on
transport system level, the line values are added per transport system (because a transport
system has to be assigned to each line).
For the service kilometers of the transport system Train in the application example, the
calculation is as follows.
Illustration 202: Aggregation of the service kilometers from the trips onto the line
PTV AG
645
7.6.8.4
The temporal cut is applied, if you want to calculate indicators for a certain analysis time
interval (see User Manual, Chpt. 4.2.2, page 949) or during the calculation of the indicators for
the analysis period. In the last case, the complete days of the analysis period are treated
internally the same as a time interval, which last from 12 pm to 12 am. The temporal cut is
carried out on the time profile.
For the time cut, the departing line route items are decisive. Indicators are always first
calculated on the trip section level and then aggregated along the line hierarchy (see
"Aggregation along the line hierarchy" on page 645). If a time interval lasts for example from
8 a.m. to 9 a.m. and a trip departs at 7:55 a.m., the line route item which departs at 7:55 a.m.,
is not included in the indicator calculation. If however, another trip departs at 8:55 a.m., this line
route item is still included in the calculation.
The division of link-related indicators is thus based on the acuteness of individual links. In the
case of trips exceeding a time interval limit for example, a time interval is assigned to the
values of those links whose FromNode is traversed within the time interval. For that purpose,
the passage times at each of the nodes and stop points crossed are interpolated from the run
times of the time profile first and then compared with the limits of the time intervals (see
"Interpolation of passage times (run times in minutes)" on page 646). A calculation example
can also be found in a different place (see "Measurement of the transport supply" on
page 615).
3
Line route
Time profile
C
2
10
4 * 3 / (3 + 6*0.5)
2
A
2
B
2
X
2
C
8
D
7.6.8.5
In principle, the calculation of the territory-specific portion is based on cutting the link.
646
Length-related and time-related indicators, which are calculated per link (for example
service kilometers), are summed up for the territory where the link is located in.
If a link traverses several territories, the indicators of territories is proportionally added
to the respective length shares, for length-related indicators.
If a link traverses several territories, the indicators of territories is proportionally added
to the respective time shares, for time-related indicators.
PTV AG
For indicators which are not calculated per link, such as the number of stop events in a
territory, this territory is summed up where the polygon lies.
7.6.8.6
Partially traversed links are a special case. These are links with a stop point on the link, where
a trip ends or starts at this link stop point. For the calculation of some indicators, the link has to
be traversed by at least 50 %, to be included in the calculation. Which rule applies for which
indicator and network object, can be taken from the file IndicatorAvailability.xls. An example for
this are the service kilometers on the link. In the upper section of the illustration 204, the link is
only traversed by 20 %. The service kilometers on the link are then 0 km. In the lower section
of the illustration, the link is traversed by 80 %. The service kilometers on the link are then
8 km.
Link 1: 10km
Trip
H1
H2
20%
H3
H3
80%
Trip
H2
H1
80%
20%
Illustration 204: Partially traversed links
7.6.8.7
For some indicators, coupled vehicle journeys are counted proportionally. This means, that two
vehicle journeys which are coupled, in the coupled section share the value of the indicator. The
Excel file IndicatorAvailability.xls provides an overview of the indicators to which this applies. If
indicators regard the coupled vehicle journeys only for certain network objects, this is
additionally noted in a comment.
The following example illustrates the influence of couplings. Couplings are taken into
consideration for service kilometers, for section service kilometers however, couplings are not
taken into consideration.
PTV AG
647
19km
2km
Trip 1
Trip 2
Coupling
(in associated time profile of the trips)
7.6.8.8
In addition to the pre-defined PuT operating indicators also user-defined indicators can be
extrapolated from the level of vehicle journey sections to higher levels of the line hierarchy
called Projection of additional attributes if required, they are returned by territory, too.
Each vehicle journey section attribute selected for the projection of additional attributes is
calculated according to the following algorithm.
Note: If the result attributes already exist, but are either not numeric or not editable, an error
message will be displayed and the projection of additional attributes will not start at all.
Unaffected hereof, the rest of the PuT Operating Indicators procedure, however, will still be
executed.
Here, the projection factor specified for the Valid Day of the journey section is used for the
transport supply.
648
PTV AG
Territory cut
If the original attribute is a length-related attribute, the value of the vehicle journey
section is first distributed onto the traversed links in proportion to the line length. Then
the link values are intersected with territories as usual. Thus, the value of a link is added
to the share (link length in territory / link length) in the AP result attribute per object(s) of
the line hierarchy x territory.
If the original attribute is a time-related attribute, the value of the vehicle journey section
is first distributed onto the traversed links in proportion to the run times of the time
profile. Here, too, the link values are length-proportionally allocated to the territories
(see above).
If the original attribute is not length-related, its value will simply be added up for each
traversed territory.
The values calculated per vehicle journey section are each multiplied by the projection
factor AH for the transport supply (see above) and then added up equally in the AH result
attribute per object(s) of the line hierarchy x territory.
Note: If the Init PuT Operating Indicators procedure is executed, the user-defined attributes
of the TerritoryPuTDetail network object, for example, Territory x TSys x Vehicle
combination, will be deleted (even if the LineCosting results are dropped for other reasons).
The other result attributes are kept since they might have existed before. If necessary, they
have to be deleted manually.
In the example Example_LLE.ver the network object vehicle journey section has the userdefined attribute Revenue_per_PassKm. This reflects the ratio between revenue and
passenger kilometers. Projection to line data is carried out according to the following schema.
Main line
Line
Line route
Time profile
Vehicle journey
Vehicle journey item
PTV AG
649
650
PTV AG
The Visum add-on module HBEFA allows you to calculate emission values in Visum by link,
territory or network-wide. The calculation is based on the Handbook Emission Factors for Road
Transport version 3.1 (see "Emission calculation according to HBEFA 3.1" on page 657).
Subjects
8.1
Noise volume
Air pollution emissions
Emission calculation according to HBEFA 3.1
Noise volume
To calculate noise volumes based on traffic volumes, Visum offers the Noise-Emis-Rls90 and
Noise-Emis-Nordic procedures. The Noise-Emis-Rls90 procedure is based on the RLS-90 of
the noise reduction for roads by the German Federal Minister for Traffic, the Noise-EmisNordic procedure on the Nordic Council of Ministers (1996) model.
The model is fairly simple but sufficient to identify relative variations, that is, how, where, and
to what extent traffic-routing and road construction measures affect traffic volumes and, as a
consequence, the noise situation of particular roads.
8.1.1
Noise-Emis-Rls90 procedure
The procedure determines the average emission level of long and straight roads in accordance
with RLS-90. For the calculation of Lm,E in decibels, Visum considers the following operations:
PTV AG
Lm(25 ) = 37 ,5 + 10 lg [M (1 + 0 ,082 p )]
651
Determination of correction factor DStrO for different road surfaces in accordance with table
4, RLS-90. Visum keeps the correction factors listed in this table as an ASCII file RLS.DAT
in the background.
Determination of speed correction Dv for permissible maximum speeds other than 100 km/
h using equation (8), RLS-90. For car v_0 is valid from 30 to130 km/h, for HGV from 30 to
80 km/h.
Determination of correction factor DStg for inclinations and gradients using equation (9),
RLS-90.
Note: The correction factor DE which takes absorption characteristics of reflecting areas
into account is not calculated.
The final result for every active link is the emission level Lm,E which is calculated through
an addition using equation (6), RLS-90.
Lm ,E = Lm + Dv + DStrO + DStg
8.1.2
8.1.3
Description
Share of HGV
(Input)
Slope
(Input)
Lengthways link slant g in percent for specifying correction factor DStg for
inclinations and gradients where the following rules apply:
DStg = 0,6 |g| -3 for |g| > 5%
DStg = 0
for |g| 5%
Default: 0
Value range: -50 to 50
SurfaceType
EWS surface type
(Input)
For different road surface types, correction penalties are generated and added
in accordance with RLS 90, table 4. The respective data are stored in the
parameters file RLS.DAT (see "Parameters file RLS.DAT" on page 653).
Default: 1
Value range: 1 to 9
Noise
(Output)
652
PTV AG
50 km/h
>= 60km/h
2.0
2.0
3.0
3.0
6.0
6.0
1.0
-2.0
-2.0
-4.0
-5.0
PTV AG
653
8.2
8.2.1
Pollution-Emis procedure
This procedure is based on emission factors issued by the Swiss Federal Office for the
Environment (BAFU) for pollutants NOx, CO, HC and SO2, for both cars and HGVs. For each
pollutant, a regression curve with polynomes to the 5th degree is used.
Emiss:= a + b * v + c * v2 + d * v3 + e * v4 + f * v5
The parameters a,b,c,d,e and f of the polynome were determined separately for different
pollutants for cars and HGVs for the reference years 1990, 1992, and 2000 and are contained
in the parameter text files EMI1990.DAT, EMI1992.DAT and EMI2000.DAT. For the reference
year 1990, for example, the following values are used.
654
PTV AG
*
*
*
*
*
*
*
*
bx
cx2
dx3
ex4
fx5
NOx CAR
0.75860
2.8004e-2 -9.9187e-4
1.4276e-5 -5.6655e-8
0.0
* NOx HGV
* CO
CAR
* CO
HGV
* HC
CAR
* HC
HGV
24.216
-0.70194
1.5878e-2 -1.5996e-4
16.425
-0.38357
2.8706e-3 -4.5425e-6
45.380
-3.0729
9.7880e-2 -1.6116e-3
2.2155
-6.6593e-2 8.7930e-4
-5.1330e-6
2.3153e-3
7.1751e-7
0.0
0.0
0.0
1.3138e-5 -4.1410e-8
1.1381e-8
46.490
-3.7859
0.13382
101.80
-3.0309
4.4557e-2
-2.8928e-4 7.7300e-7
1980.4
-87.564
2.9120
-5.0701e-2 4.3285e-4
0.0
1.9258e-5 -6.1410e-8
* SO2 CAR
0.0
* SO2 HGV
-1.3577e-6
Recent measurements have shown that actual emission values are generally overestimated by
1990 calculation factors, because the change in vehicle fleets (more vehicles have now been
equipped with catalytic converters) has contributed to decreasing volumes per vehicle. The
latest Swiss emission factors take this change into account with modifications for the years
1992 and 2000.
The polynome approximation of emissions relative to speed shows the following developments
for CO for the different reference years in illustration 208:
CO emission volume in g/km
20,0
HGV (same values for all years)
18,0
16,0
14,0
Car 1990
12,0
10,0
8,0
Car 1992
6,0
4,0
2,0
Car 2000
0,0
0
10
20
30
40
50
60
Speed km/h
70
80
90
100
110
8.2.2
PTV AG
655
Attribute
Description
Share of HGV Relevant HGV share in percent of total traffic (above 2.8 t total permissible weight)
(Input)
EDat_NOx
(Output)
EDat_SO2
(Output)
EDat_CO
(Output)
EDat_HC
(Output)
Hydrocarbons in g/km
The illustration 209 shows an example where the nitrogen monoxide volumes are displayed as
link bars according to Pollution-Emis. In the User Manual you will find further information on
implementation (see User Manual, Chpt. 8.8, page 1254).
Note: For the display of pollution emissions, we recommend the use of classified values.
656
PTV AG
8.3
8.3.1
Fundamental principle
The HBEFA-based emission calculation procedure allows you to calculate emission values
by link, by territory or network-wide in Visum. The calculation is based on the Handbook
Emission Factors for Road Transport version 3.1. From the Handbook HBEFA 3.1:
"The Handbook of emission factors for Road Transport provides emission factors, i.e. the
specific emission in g/km for all current vehicle categories (PC, LDV, HDV and motorcycles),
each divided into different categories, for a wide variety of traffic situations."
Note: The complete HBEFA Handbook is available on the website www.hbefa.net.
8.3.2
PTV AG
657
8.3.2.1
Urban
HBEFA_Motorway-National or
HBEFA_Motorway-City or
HBEFA_Semi-Motorway
---
Highway
Other
No
Rural
Other
Yes
Urban
Note: If you use uniform fleet compositions for each demand segment, the fleet
composition for Urban is always applied.
Gradient class:
The gradient class results from the attribute Gradient based on the following classification:
Value range
Gradient class
< -5 %
-6 %
-5 % to below -3%
-4 %
-3 % to below -1%
-2 %
-1 % to below 1%
0%
1 % to below 3%
2%
3 % to below 5%
4%
5% and more
6%
658
PTV AG
If there is a traffic situation whose speed does not vary by more than 5km/h, which matches
the characteristic urban/rural and the link class, it will be allocated. In the case of two such
traffic situations (e.g. 55km/h), the one with the higher speed will be allocated. If no traffic
situation fulfills this condition, the nearest traffic situation with the same link class will be
used.
If no traffic situation matches the specified combination of urban/rural and HBEFA link
class, the default traffic situation Rural/Motorway-National/80km/h will be used.
For the used fleet composition, the emission factor weighted by the static traffic situation, the
level of service and the gradient class will be multiplied for each pollutant to be calculated by
the value of the volume attribute (AP) specified for the demand segment and by the length of
the link. The result is the warm emission for this pollutant, this link and this demand segment
based on the analysis period. Multiplied by the respective projection factor, the amount is
saved in the respective link attribute (AP and AH) and added to the network-wide emission (AP
and AH).
If the calculation is additionally carried out per analysis time interval, the emission factor is
determined once per interval due to the interval-dependent LOS and multiplied by the volume
value for this interval and the length of the link. The result is then saved in the subattribute
associated with the analysis time interval and added to the network-wide time-dependent
emission.
Calculated pollutants
The following pollutants can be calculated in Visum. The pollutants are divided into three
groups:
Group 1: Established measurement programs
PTV AG
Element
Description
CO
carbon monoxide
Fuel
fuel consumption
Gasoline
fuel consumption
Diesel
fuel consumption
PM
particle matters
HC
hydrocarbons
659
Element
Description
NOx
nitrogen oxide
CO2 reported
carbon dioxide "reported", i.e. without the biofuel share in the fuel
CO2 total
PN
Particle number
Description
Pb
lead
benzene
benzene
CH4
methane
SO2
sulfur dioxide
NO2
nitrogen dioxide
NMHC
non-methane hydrocarbon
Description
NH3
ammoniac
N2O
nitrous oxide
Note: The emission factors of the pollutants SO2, Pb and CO2 reported are country specific
because they depend on the composition of the fuel. So far, only values for Germany can be
calculated in Visum.
8.3.2.2
To determine the cold start excess emissions, firstly, the cold start emissions weighted over the
shares are calculated for each urban fleet composition used and for each pollutant. For this,
the supplements per pollutant and subsegment are requested from the HBEFA database.
The distribution of this emission onto links is done in two different ways, which can be switched
via attribute Calculate start excess based on routes at the origin zone:
Polygonal calculation
Calculation on routes
Note: In HBEFA, cold start excess emissions are not indicated for all subsegments. For
segments without an available excess, a cold start excess emission of 0 g/start will be
applied.
660
PTV AG
Calculation on routes
In order to determine the cold start excess emissions on routes, all routes of the demand
segments to be calculated are evaluated from the origin to the destination. For each traversed
link, a cold start excess share AP,S is calculated as the integral of the decay function over the
link length. This share is multiplied with the volume of the route and the share of cold start of
the origin zone of the route. Any attribute, whose content does not have to correspond to the
total of the volumes of all routes, can be used as volume value when calculating the warm
emissions. In order to calculate meaningful cold start excess emissions anyhow, the value is
divided by the volume of the demand segment afterwards and multiplied by the value of the
volume attribute. That implies that the relation between the route volume and the link volume
multiplied by the value of the volume attribute yields the assumed route volume on the link,
which, however, does not have to be constant along the route any more. Per link, the value is
summed up over all routes. The evaluation of the routes can end as soon as the first four
kilometers of the route are traversed, because the decay function is constantly 0 thereafter.
After that, for each link, pollutant, and demand segment, the calculated value is multiplied with
the cold start excess emission factor of the fleet composition allocated for urban and projected
over AP and AH.
As in the case of the polygonal method, the calculated absolute emission of the zone is then
distributed proportionally to this indicator per link onto the links. Please note that this does not
yield the exact dynamic route volumes but an acceptable approximation. In order to use the
dynamic route volumes in the procedure, the traffic flow model of the used dynamic
assignment would have to be reproduced. The volume per analysis time interval calculated
from these dynamic route volumes during the assignment is used instead.
Like the other emissions, the cold start excess emissions are aggregated network-wide and
issued in the statistics list Emissions (HBEFA).
Note: If no routes are available for a demand segment and the calculation on routes is
demanded at a zone, no cold start excess emissions will be calculated for this zone. Besides
the explicit rejection of the routes, this is for example the case if you want to determine
emissions of service buses using a separate, artificial demand segment whose volumes
result from, for example, the number of service trips. Here, the omission of the cold start
excess emissions is in line with the fact that almost all of the trips are warm. The procedure
can, however, still be run.
PTV AG
661
662
PTV AG
Subjects
9.1
EWS Basics
EWS link attributes
EWS Costs
EWS Cost-benefit analysis
EWS Basics
Economic efficiency analyses according to EWS-97 are based on the comparison of costs and
benefits which incur if a road construction measure is taken (planned case) or which can be
saved if the measure is not be taken (comparison case).
Utility
The EWS-97 assesses the impacts of the realization of road construction measures
considering the modification of the following benefit components (difference of the noninvestment costs).
Operating cost
Travel times
Accidental events
Noise volume
Pollutant volume
CO2 volume
Barrier effect vs. pedestrian crossing
Availability of space for pedestrians and cyclists
If the impacts of a measure are compared, the benefits may be positive (economic gains) or
negative (economic losses). The benefits are assessed separately by direction.
PTV AG
663
Costs
The costs are broken down in two components.
Time of evaluation
l u a t i o n
p e r
Benefit annuities
Discounting
i o d
Benefit annuities
20 years
Benefit for a
representative year
Accumulation
E v a
The evaluation period is 20 years. Time of evaluation is the 1st January of the year after
inauguration (in EWS module: reference year; (see "EWS Costs" on page 668)).
As a start the investment costs (EWS module: costs in the year of the due date; (see "EWS
Costs" on page 668)) incurring at different times or periods are accumulated or discounted to
the reference time or year (in EWS module: reference year; (see "EWS Costs" on
page 668)). Based on the various amortization time intervals constant annual amounts to be
invested (annuities) are calculated. This is done using annuity factors by means of which the
reference year costs are distributed over the evaluation period taking into account the
interests.
The benefits are determined for a representative year of the evaluation period (availability of
demand data) and therefore determined approximately constantly over the evaluation period
(benefit annuities). The overall benefit or the overall costs of the measures over the evaluation
period can be gained by multiplying the annuities by the corresponding cash value factor.
To determine the cost-benefit ratio the annual costs and benefits (annuities) are taken. Costs
and benefits are specified at price index 01/01/1995, hereby costs without VAT.
664
PTV AG
Cost-benefit analysis
Decision criterion for the economic efficiency of road construction measures is the quotient of
benefit and costs. In case of road construction investments the cost-benefit ratio (CBR)
specifies how many DM of benefit can be expected per DM of costs spent. If all kinds of
benefits and costs incurring additionally due to the construction measure are known, a CBR
1 provides evidence that the measure is worth to be taken. If different variants are available,
the variant featuring the higher CBR is the more advantageous one. The CBR is mainly
determined as annual CBR (see "Evaluation period and annuities" on page 664). To make the
determination of the cost-benefit ratio more transparent, the individual partial benefits of the
total cost-benefit ratio are apportioned.
Network delimitation
All coherent network segments for which the traffic volumes of comparison case and planned
case differ considerably (generally by more than 5% of the volume of the comparison case,
however, at least by 250 veh/24 h) belong to the studied network, this means the impact area
of the measure to be assessed.
If measures entail a major change of modal split, i.e. the distribution of trips on private
transport (PrT) and public transport (PuT) changes.
A road construction measure is to be compared with a construction measure for public
transport.
If benefits for public transport occur in form of modified vehicle and personnel costs as well
as running costs for rail-bound transport modes which can no longer be (EWS-97, p. 7).
In those cases the proceeding and additional methods (for example, Verfahren der
Standardisierten Bewertung, Engl.: Standardized evaluation method) have to be determined
individually in cooperation with the parties involved.
Deviations from the EWS-97 guidelines for the implementation in the Visum
EWS add-on module
The Visum EWS add-on module has integrated the EWS edition 1997 into the Visum
environment as accurately as possible. Minor corrections of the EWS guidelines have been
discussed and agreed with a member of the FGSV working committee in charge.
Hereby the following has to be taken into account.
PTV AG
665
Changes of pollutant volume (EWS-97, pp. 40, 6.5). The alternating allocation of the middle
lane of road type 2.10 in table 41, p. 49, is not taken into account.
Notes: Working with Visum, users should pay attention to all differences between the
EWS program module and EWS guidelines. If there are any questions, please contact the
PTV Vision Support.
The application of the EWS add-on module requires the detailed knowledge of EWS-97.
Gained results should be verified through plausibility checks.
9.2
Description
DistanceBuilding
EWS building distance
(Input)
BuildingType
EWS building type
(Input)
BuildingHeight
EWS building height
(Input)
Minimum average height of house fronts [m] (cf. EWS-97, equation 70)
Default: 0
Value range: 0.00 to 1,000.00
666
PTV AG
Attribute
Description
Residents
EWS residents
(Input)
EWSClass
EWS class
(Input)
EWStype
EWS type
(Input)
SidewalkWidth
EWS sidewalk width
(Input)
Curvature
EWS curvature
(Input)
CyclelaneWidth
EWS cycle lane width
(Input)
SidewalkWidthFuture
EWS sidewalk width
future
(Input)
CyclelaneWidthFuture
EWS cycle lane width
future
(Input)
Slope [%]
Surface type
Share of HGV in total average daily traffic (see also default values of HGV shares
according to RLS-90 in EWS-97, table 20).
Difference in height hm between noise emission and immission point in [m] (cf. EWS-97,
equation 66).
PTV AG
667
Note: In Visum immission height is not calculated according to EWS-97, equation (67),
but directly input by the user.
Furthermore, the following basic link attributes are required for calculations according to EWS.
Link length
permissible speed of vehicle groups (transport systems)
The volumes required for EWS can either be input as counted data or calculated by
assignment. On the one hand, it allows to use actual results gained from traffic counts and on
the other hand, the simulation of various variants based on the assignment methods integrated
in Visum. The speeds relevant for the evaluation are calculated according to EWS-97, tables
11-13.
Notes: Specification of the volume origin (assignment or AddValues) for EWS calculation in
EWS Parameters window.
System requirements
The traffic volumes required for the EWS calculation have to be available as average daily
traffic ADT (cf. EWS-97, chapter 4.3.1). If demand matrices are not available as ADT, they
have to be adjusted accordingly. The conversion factor is specified in the EWS Parameters
window.
9.3
EWS Costs
Besides the EWS link attributes and the EWS parameters the costs equally have to be input for
the calculations according to ESW-97.
Investment costs
Additional annual maintenance costs
The total investment costs can be broken down to a maximum of 10 partial investments
(structures, components). Based on the amortization periods of the partial investments, the
time of inauguration as well as the usual interest rate for investment projects of 3 % will be
converted to annual investment costs (annuities).
Visum determines the annual running costs taking the base values for comparison case and
planned case of the study network listed in EWS-97, table 15, for comparison case and
planned case of the study network. Additional annual maintenance costs surcharges for extra
expenditures (for example street lighting, winter service) and other costs according to EWS-97,
table 15 (for example bridge and tunnel engineering) will also be added, if applicable.
668
PTV AG
9.4
The following calculation results all costs in million DM/year are output.
Running costs determined from the base values of EWS-97, table 15 including additional
annual maintenance costs (see "EWS Costs" on page 668) of comparison case and
planned case and their cost difference.
Investment costs (annuities; (see "EWS Costs" on page 668)) of comparison case and
planned case and their cost difference.
Total costs, the sum of investment costs and running costs of comparison case and
planned case and their cost difference.
Non-investment costs of comparison case and planned case, each in total and related to
the individual benefit components (operating cost, accidental events etc.) and their
difference (utility).
Share%: relative benefit of the individual benefit components related to the overall benefit,
for example according to table in illustration 211:
Share % CO 2 =
PTV AG
CBRCO 2
0.94
=
= 6.56
CBRTotal 14.36
669
CBR, overall cost-benefit ratio and relative cost-benefit ratio of the individual benefit
components, for example according to table in illustration 211.
CBRTotal =
UtilityTotal
7.945 Mio. DM / a
=
= 14.36
CostDiffTotal 0.553 Mio. DM / a
CBRCO 2 =
UtilityCO 2
0.521 Mio. DM / a
=
= 0.94
CostDiffTotal 0.553 Mio. DM / a
The cost-benefit ratio allows a ranking of the different planning variants: construction
worthiness if CBRTotal 1.
670
PTV AG
10
GIS functions
Visum allows you to include data from geographic information systems (GIS) into your model.
Both ESRI shape files (file extension *.shp) and the Personal Geodatabase (PGD) are
supported. Visum also offers typical GIS functions such as the different objects or different
coordinate systems for georeferencing your network. Furthermore, functions for network
digitalization (GPS tracking) and visualization (legends, backgrounds, texts, polygons) are
offered, which make network data preparation for presentations easier.
Other GIS typical functions have already been discussed at some other point:
Subjects
10.1
To create GIS objects in Visum, you have to either select the PGD Feature Classes or Feature
Datasets for display or editing. The following objects are thus created in Visum:
PTV AG
671
For each selected Feature Class of the Personal Geodatabase, a GIS category is created.
For each Feature a GIS object
None of the coordinates transferred to Visum are being converted. The GIS objects are always
removed again as soon as the connection to the PGD has ended. If you want to permanently
include GIS objects into the Visum network, proceed as follows:
10.2
Shape files can contain points, lines or polygons (surfaces). Only one type of element can be
contained in a shape file.
Note: A technical description of the data format can be found on the Internet at www.esri.com/
library/whitepapers/pdfs/shapefile.pdf.
10.2.1
672
PTV AG
Link, Screenline,
Connector
Point
Polyline
Polygon
POI
X
X
Note: Creating POIs is only possible with additive reading of shape files, because a POI
category has to be specified, where the POIs can be included. At least one POI category has
to therefore be contained in the network, to read shape files as POIs.
Connectors, stop points, and count locations can only be read in additively.
If you want to read existing node data as a stop points into the shape file, you have to first read
it as a node and then with the function aggregate node (see User Manual, Chpt. 2.12.14,
page 255), create stop points.
While reading polylines as links, you can create alternative directed links or links with both
directions. If a link is undirected, it has to be determined how to interpret each attribute.
While importing the shape file you can determine which source attribute (from the shape file)
should be assigned to which target attribute (an existing or user-defined attribute of the
selected network object). The illustration 212 shows an example, where shape file data are
read as a link. The shape file contains the attributes STREET_NAM, LENGTH and LANE,
which allocate the Visum link attributes Name, Length and Number of lanes.
Note: When loading polygons from shape files (e.g. as zone polygons or POIs for a
background image), you can optionally activate normalization of the loaded surface data (see
"Multi-part surfaces" on page 114). This is required if you want to use the loaded polygons to
perform geometrical operations, such as surface calculation or intersections, as otherwise
the results might be falsified. If you merely wish to display polygons, then normalization is not
required.
PTV AG
673
Example applications
Reading shape files with a road network as links in Visum. In Visum a routing-enabled link
network is then available.
Note: The links have to first be enabled for transport systems.
In addition to the import of shape files as Visum network objects, you can also insert shape files
as background. This is how you can insert land use (for example residential areas, industrial
areas, commercial areas) to make your network more visible, for example. You can thus insert
multiple shape file layers into the network (for example a layer for industrial areas). The
drawing order of the layers and its color can be changed. The illustration 213 shows an
example, where two shape files were integrated as a background with land use for residential
and commercial areas.
674
PTV AG
10.2.2
PTV AG
675
The table 261 shows in which shape types the Visum network objects are illustrated.
Point
Nodes
Polyline
Polygon
Main nodes
Stop points
Stops
Links
Zones
Zone centroids
X
X
Main zones
Main zone centroids
X
X
Territories
Territory centroids
X
X
Line routes
Screenlines
Connectors
Count locations
Detectors
POIs
When exporting shape files, the following special cases have to be noted.
676
Links
If links are saved undirected, only one object is created for both directions. The attributes
of the From node keep their name. Attributes of the opposite direction all start with an "R_".
If the option Directed is active, an individual object is saved in the shape file for each
direction.
Connectors
You can select whether the first point of the object should be the zone (standard setting) or
the node. For each single object the attributes of both directions are always stored.
Reverse attributes contain the entry R_ as prefix. The specified direction is always taken.
POIs
POIs can be point, polygon or polyline and are thus exported to three different files.
PTV AG
10.3
Intersect
The "Intersect" functionality known from GIS describes the overlap of two subject levels of the
same area section with the aim of gaining new information. This can be used to link two
network objects which overlap each other (intersection) and saves the thus resulting
information in an attribute. To create a demand model, GIS structure data (such as the number
of employees or the number of pupils) can for example be read in POI polygons and these
intersected with zones. The result being the type of structure data for each zone (number of
employees or pupils per zone) in a Visum attribute.
The intersection area of two objects results from the spatial overlapping of both objects. The
illustration 214 shows examples of overlapping network objects.
Use cases
A typical use case for an intersection is the data import from a GIS.
PTV AG
677
Land use data are imported to Visum using a shape file, which is read in a POI.
(Alternatively Visum can be connected to a Personal Geodatabase. Land use data in
Visum are then available as GIS objects.)
The zone and an editable attribute are later selected as target object, to adapt the created
information.
Through the intersection of zones and POIs the result is the land use data per zone and can
for example be used in a Visum demand model (for example the number of homes per
zone).
Intersection is not just confined to data exchange with GIS. Multiple application possibilities
also arise within Visum. Some examples, which information can be obtained with an
intersection operation are introduced in the following.
Intersecting zones and stop points: The passengers in a zone are calculated from the ZoneAddValue1 =
Sum of passengers at all stop points in the zone polygon.
678
PTV AG
Intersecting line routes and zones: The inhabitants of a line route are calculated from
LineRoute.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the line route.
Table 263: Calculating the number of inhabitants in the catchment areas of lines
Intersecting stops and zones: The inhabitants of a catchment area of stops are calculated from
Stop.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the stop.
Table 264: Calculating the number of inhabitants in the catchment areas of stops
PTV AG
679
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.
Intersecting stop points and zones: In which zone a stop point lies, is calculated from
StopPointAddValue1 = smallest zone number of the zone where the stop point lies (Please note that the
minimum is selected here, because theoretically, a stop point could lie in two zones, if its polygons
overlap. One of the other three functions, however, could also be selected). If you want to determine all
zones in which the stop point lies, use a target attribute of the type Text and Concatenate as aggregate
function.
Table 266: Calculating the zone number where a stop point lies
680
PTV AG
Intersecting zones and stops: which stops lie within a zone. As target attribute, a user-defined attribute
of the type Text is used, to which a concatenated list of the numbers of the stops will be saved.
Table 267: Determination of the numbers of the stops that lie within a zone
The target attribute values can either be calculated as a sum, mean value, minimum or
maximum of the source attribute values. If for example you do not want to calculate the total
number of PuT passengers per zone (table 262), but the average number of PuT passengers
at the stops of a zone, proceed as described in table 268.
Intersecting zones and stops: The average number of passengers at stops in a zone is calculated from
the ZoneAddValue1 = Average number of departures at all stops within the zone polygon.
Table 268: Calculating the average number of PuT passengers at the stops of a zone
Note: If you want to calculate the number of source objects per target object, select the
attribute 1.0 of the source object.
Buffer
To carry out intersections, at least one involved network object type has to be two-dimensional.
To obtain this, a buffer can be created around a network object.
PTV AG
681
A buffer assigns an area to a point object, line object or a polygon. The resulting area is
intersected along with the actual network object. An object point thus becomes a twodimensional object when calculating the intersection.
The buffer is not defined based on the polygon centroid, but on each point of the polygon. This
means, that the buffer is also placed around the polygon like a belt.
Source or target objects are first inflated by the set buffer size(s). The proportion is then
calculated by which the target buffer overlaps the source buffer(s). Together with the attribute
value of the source object, this share then enters the attribute value of the target object.
The buffer operation (obj, radius) assigns the area (buffer) resulting from all points that have a
distance of radius to a point of obj to the particular object. Radius = 0 results in the obj itself.
In the case of polygon objects, polygons plus their buffers are intersected.
Intersections
The intersection procedure determines source objects that overlap with a specific target object.
The attribute data of such a target object is aggregated according to the option selected and is
then assigned to the target object. The available aggregate functions and their effect depend
on the data types of the source and target attributes (table 269). The respective aggregation
functions are available in the combinations of the table only.
Aggregate function
Sum
Mean value
Effect
Sum source attribute values,
weighted by overlapping area,
where applicable
Numerical
Numerical
Text
Numerical
Numerical
Numerical
Text
Numerical
Numerical
Numerical
Text
Numerical
Text
Text
Minimum / Maximum
Number
Concatenate
Histogram
Numerical
Numerical
Text
Numerical
Text
Text
Text
Numerical
Text
Text
Text
Numerical
Text
Text
682
PTV AG
For numerical source and target attributes, you can either choose to use the full source
attribute data or a share of the data that is proportional to the overlapping area with the source
object. This section describes the results of the two options.
Note: To determine the number of source objects per target object, or the ID-number of a
surface object overlapping with another surface object, choose the full source attribute data.
In nearly all other cases, choose the proportional share of the source attribute data.
There are three types of intersections:
The polygon content content(P) of a polygon is defined as usual. The following also applies:
Content ( P1 P 2)
Content ( P 2)
0
Share( Po int p, genPoly pg )=
1
p pg
p pg
Share(l , pg ) Length(l )
Length(l )
Links ll
Links ll
683
Content ( pg1 pg 2)
Content ( pg 2)
When you choose to use the full source attribute data, the share is 100%, if source and target
object overlap (including buffers). Otherwise it is 0%. In this case the size of the overlapping
area is not relevant.
Intersection then results in:
(1)
(2)
(3)
Illustration 215: Intersecting three polygon objects with a link buffer
In illustration 215, surfaces are intersected with surfaces. The intersection of two polygons is
defined as usual.
684
PTV AG
In illustration 216, for those point objects outside of the polygon, intersection results in 0%, for
the three point objects inside of the polygon, intersection results in 100%. If 1.0 is selected as
source attribute, all stops (source object) per zone (target object) are counted here for example
(since value of source object = 1.0).
In illustration 217, for those point objects outside of the buffer polygon (= polygon + buffer),
intersection results in 0%. The intersection share within the buffer polygon is 100% for all point
objects. Six points are thus intersected with 100%.
2
1
3
4
PTV AG
685
If point objects are intersected with polygons, the intersection share of a buffer results per
polygon from the position of the buffer in the respective polygon. In illustration 218, two point
object buffers with 100% share are intersected and one point object buffer prorated (its
remaining shares intersect with polygon 2 and 3) for polygon 1.
If a polygon is positioned exactly next to an adjacent one and a buffer is defined as > 0, point
objects within the overlapping area will be counted twice, because the polygon buffers overlap
each other and the point object lies within two polygons with buffers. The resulting number of
point objects regarded for intersection is then greater than the actual number of point objects.
10.4
Coordinate systems
When creating networks, components from different GIS sources are often combined, which
partially refer to different coordinate systems. To make the data consistent a coordinate
transformation is necessary. Visum supports you with this task with the following functions.
The user can optionally specify that all coordinates in the current network belong to a
predefined coordinate system (see User Manual, Chpt. 10.1.1, page 1283).
The coordinate system can be changed in Visum. You can automatically transform the
coordinates of the current network (see User Manual, Chpt. 10.1.1, page 1283).
If data are imported, which apply to another coordinate system than that for the current
network, Visum automatically transforms the imported coordinates into the system of the
current network.
There is an option to switch from the default Visum to a predefined coordinate system. Visum
offers a selection of coordinate systems, which are provided as files with the extension *.prj.
You can find them in the directory ...Program files\PTV Vision\PTV Visum 13\Exe\Projections.
This file format is Well-Known-Text-Format in ESRI version.
Note: You can optionally specify, whether you want to work with a current projection in your
project. It is usually sufficient to keep the standard setting ("Visum"). In this case coordinates
in Visum do not apply to any current projection, but are illustrated "uninterpreted" in a
rectangular system. If, however, original files are specified in a certain projection and are
imported to a network, where no projection has been selected, the display is distorted. In this
case select the suitable projection.
In Visum, a difference is made between geographic coordinate systems and projected
coordinate systems.
In geographic coordinate systems, the coordinates are displayed as spherical coordinates with
geographic length and width. They are measured as an angle from the earth's center to a point
on the earth's surface (for example 47 6 northern latitude, 12 27 eastern longitude). In
comparison, the coordinates of the earth ellipsoid is projected to a level, for plane coordinate
systems. A location on earth is therefore distinctly determined as an X and Y coordinate on the
level. The following example shows two projection files for a planar and a geometric coordinate
system in Visum.
686
PTV AG
Example for planar coordinate system (WGS 1984 UTM Zone 48N.prj)
PROJCS["WGS_1984_UTM_Zone_48N",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["False_Easting",500000],
PARAMETER["False_Northing",0],
PARAMETER["Central_Meridian",105],
PARAMETER["Scale_Factor",0.9996],
PARAMETER["Latitude_Of_Origin",0],
UNIT["Meter",1]]
Example for geographic coordinate system is the German Main Triangle Network (Deutsches
Hauptdreiecksnetz.prj):
GEOGCS["GCS_Deutsches_Hauptdreiecksnetz",
DATUM["D_Deutsches_Hauptdreiecksnetz",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]]
Note: Please note, that in the actual file *.prj the projection properties which are written down
row by row, have to be successive (in a row). Detailed information on how to create
projections can be found on the ESRI homepage (for example at www.support.esri.com/index.cfm?fa=knowledgebase.techArticles.articleShow&d=14056).
Visum manages coordinate systems in the following file types: Depending on the file type,
coordinate information is saved or imported differently.
PTV AG
File type
Write
Read
*.ver
Version file
*.net, *.mdb,
*.accdb
Network file
Database
687
10.5
File type
Write
Read
*.shp
Shape file
*.inp
Vissim network
*.hgr
Background file
not applicable
10.5.1
Texts
Texts serve to additionally label the network display. There are two text types:
Background texts
Texts which are added to the network display
Legend texts
Texts which are inserted into a legend
Note: Graphic texts are network-independent graphic objects and therefore be differentiated
from labels of network objects and labels for plot output.
10.5.2
Legend
Using the Legend function, in the Visum network display or schematic line diagram, you can
show additional, descriptive and explanatory information. To do so, in the legend, select the
objects you want to show and specify the display style (see User Manual, Chpt. 10.9,
page 1325). In addition, in the legend footer, you can insert user-defined information, e.g.
diagrams created with external programs (illustration 219).
688
PTV AG
10.5.3
Backgrounds
Including backgrounds allows you to improve network display and orientation as well as add
graphic information to scale. This is how a zoning plan or a city map can be applied to the
background of the network display for example. Graphic background data can be provided in
different ways. You can insert existing files in various graphic or GIS formats as a background
for your network display. Vector graphics, e.g. *.shp or *.dxf as well as raster graphics, e.g.
*.jpg, *.bmp or *.sid, are supported.
Besides existing graphic files, you may also use city maps or aerial and satellite images,
provided by map services on the Internet, as your background image. Map providers offer highresolution aerial and satellite images as well as detailed city maps for many regions. Apart from
commercial offers such as Microsoft Bing Maps (see "Backgrounds by Bing Maps" on
page 691), there is free data available by map providers, e,g. OpenStreetMap, that you may
use under certain conditions. You can download the map data automatically and insert it as
your background. If you have a permanent Internet connection, you can show the Background
graphic layer as an alternative to a statically embedded background. The graphic layer
contains the background graphics that match a network section. They are called dynamically
by map providers on the Internet (see User Manual, Chpt. 10.7.1.1, page 1309).
PTV AG
689
Note: Using data from map providers is subject to license terms and conditions. Please learn
about these terms in advance and consider them when working on projects and sharing
results.
690
PTV AG
Map providers offer maps and aerial photos in a pre-arranged tile configuration. They come in
a graphic format (e.g. JPEG or PNG) and in a uniform size that allows for several detail levels.
The data are available in a projected form, usually in Mercator projection (see "Coordinate
systems" on page 686). Visum automatically downloads the tiles for the current network
section (in the detail level selected) from the map provider, converts the data into the
coordinate system format used in Visum and integrates the data as background objects.
Depending on the size of the current network section, the original tiles are combined to several
large files. The background files generated are saved to special background folders in the
project directory. The folder structure is shown in the Administration tab, in the Background
window. You can use the Administration function to control the visibility of network
backgrounds (see User Manual, Chpt. 10.7.4, page 1315).
Note: To use background images of map providers you need to set a coordinate system for
your network (see User Manual, Chpt. 10.1.1, page 1283). Background images of freely
accessible map providers are downloaded once and saved to the computer. The embedded
maps are not automatically updated or adapted to a different network section. This is why the
use of freely available map data does not require a continuous Internet connection. If you
want to update background images, delete the existing ones and embed new ones.
PTV AG
691
692
PTV AG
Description
*.bmp (dib)
*.wmf (emf)
Windows Metafile: both vector- and pixel-based Windows graphic format (standard and
enhanced format)
*.gif
*.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
*.tif
Tagged Image File: pixel based default format for DTP and scanner applications; also with
CCITT compression
*.tga
*.dwg
A CAD format developed by Autodesk for CAD software AutoCad. The DWG format today,
is a de facto standard for CAD data exchange and the most commonly used drawing data
format.
*.dxf
Drawing Interchange Format: A vector graphic format developed by Autodesk, for CAD
data exchange, which was developed for the CAD program AutoCAD. A *.dxf file writes a
CAD model (for example a technical drawing) as text according to the ASCII standard.
*.ecw
Enhanced Compression Wavelet: ECW is a raster graphic format, which allows very high
compression rates. It is therefore ideal for saving aerial photographs and satellite images.
*.shp
Shape files are a data format for geodata, which are used in most GIS. The data format is
ideal for including GIS data in Visum (see "Shape files as a GIS interface" on page 672).
*.sid
*.svg
PTV AG
693
32.0
0.0
0.0
-32.0
691200.0
4576000.0
Note: Georeferencing and thus creating the World file can be executed with GIS software (for
example ArcGIS by ESRI). Because the World file is a text file, it is theoretically possible to
create it yourself in the text editor, if the necessary information is known.
10.5.4
Polygons
The polygons of Visum are graphic objects available for free design of your drawings. Polygons
can be edited in many ways:
694
PTV AG
10.6
GPS tracking
If a GPS receiver is connected to your PC, you can display the current position in the network
graphic. With tracking switched on, the network graphic display is then updated in user-defined
time intervals (see User Manual, Chpt. 10.10, page 1329).
The function requires a connection via a serial interface. Receivers with a Bluetooth or USB
interface can also be used, if they emulate a serial interface. You can apply these functions to
digitalize links for example.
Each time the updating time interval has expired, the marking bitmap will be refreshed,
however, only if a GPS signal has actually been received. A GPS signal accompanied by a
warning (for example due to bad transmission or incorrect conversion of the coordinates) will
be drawn in Marking1 color (see User Manual, Chpt. 12.2, page 1400). The position acquired
by the GPS receiver (length, width) will always be transferred into the current projection of the
network (see "Coordinate systems" on page 686). If no projection has been set, the position is
taken over directly. All that has to be noted is that the network coordinates correspond to the
actual geographical position.
PTV AG
695
696
PTV AG
11
Interactive analyses
Visum offers various functionalities that allow you to evaluate your traffic model interactively.
These can be used to analyze both PrT and PuT. The following interactive analyses are
available.
Flow bundles
Isochrones
Search for the shortest path between zones, nodes or main nodes, according to
different criteria (e.g. distance)
Subjects
11.1
Flow bundles
Isochrones
Shortest path search
Flow bundles
Flow bundles are used to filter and graphically display loaded paths (obtained through
assignment) according to various criteria. Loaded paths are the result of assignment
calculation and are characterized by the following properties:
Flow bundles consist of all paths traversing the network objects marked for flow bundle
calculation. Marked network objects thus constitute the path filter criteria of a flow bundle. In
the following section, you will learn about how to use the individual filter criteria. The
illustration 222 displays the principle of the flow bundle. The left figure shows all paths found in
the assignment. The right figure shows the paths traversing the highlighted link.
PTV AG
697
The flow bundle can be displayed graphically in the network editor (see User Manual, Chpt.
11.1.2, page 1345) or output as a list (see User Manual, Chpt. 12.1.6, page 1380). Using PuT
assignment as an example, illustration 223 displays the flow bundle paths in the PuT path legs
list. In the graphical display, the path courses highlighted in color and the respective flow
bundle volumes for each traversed link describe the spatial and quantitative distribution of
traffic of the specified flow bundle.
Illustration 223: Display of the flow bundle paths in the PuT path leg list
Note: To display a flow bundle, you first have to calculate an assignment and save its paths.
You can save paths in the PrT (see User Manual, Chpt. 5.1.2, page 975) and in the PuT (see
User Manual, Chpt. 6.1.1.2, page 1072).
698
PTV AG
The flow bundle type is defined via the network object type selected:
Flow bundles based on nodes, main nodes, stops, stop points or stop areas (highlighting
nodes, main nodes, stop points, stop areas or stops)
Link flow bundle (highlighting links)
Zone and main zone flow bundle (highlighting zones or main zones)
Traffic type-based flow bundle (by setting specific links or network objects of the line
hierarchy, i.e. lines, line routes, etc., passive)
The flow bundle can be created by highlighting one or more objects of a network object type. It
can also be determined by any combination of highlighted network objects of different network
object types (see "Combining flow bundle criteria" on page 706).
Notes: If a flow bundle is active, its demand can be saved as a flow bundle matrix.
The flow bundle considers the active settings of the OD pair filter. This allows you to perform
flow bundle analyses that are additionally defined via the zone type (e.g. for internal zones
only).
11.1.1
PTV AG
699
Illustration 224: PuT node flow bundle with additional filter criteria for lines
Illustration 225: Some of the paths which traverse node 100001 and use line 002
700
PTV AG
Flow bundles based on stop points, stop areas and stops (PuT only)
The flow bundles for the three network objects of the stop hierarchy (stop point, stop area and
stop) output all paths traversing each of the selected network objects. You can limit the
passenger types for each network object selected:
Origin boardings (B): A path is displayed in the flow bundle, if passengers board at the
network object selected, i.e. if there is no other PuT partial leg before boarding.
Destination alightings (A): A path is displayed in the flow bundle, if passengers alight at the
network object selected, i.e. if there is no other PuT partial leg after alighting.
Transfers (T): A path is displayed in the flow bundle, if passengers traverse at the network
object selected. This can be at a boarding or an alighting point of transfer.
Through passengers with stop (W): A path is displayed in the flow bundle, if there is a stop
at the selected network object and passengers remain on board. The line stops at the
network object without passengers alighting or transferring.
Through passengers without stop (N): A path is displayed in the flow bundle, if passengers
pass the selected network object without stopping. In this case the line does not stop.
Just like for nodes and links, you additionally have the option of limiting PuT supply (e.g. to
certain lines) (see "PuT supply filter" on page 705). For transfers, you can set separate filters
for alighting and boarding passengers.
Origin traffic: all paths starting in the selected zone or main zone
Destination traffic: all paths ending in the selected zone or main zone
Origin and destination traffic: all paths that start or end in the selected zone or main zone
In addition, you have to select the demand segments, both in PrT and PuT, whose paths you
want to use for flow bundle calculation.
Just like for the nodes, for PuT you additionally have the option of limiting PuT supply (e.g. to
certain lines) (see "PuT supply filter" on page 705). Limiting PuT supply applies to the first or
last PuT path leg, depending on whether you have filtered by origin or destination traffic.
11.1.2
PTV AG
701
In the following example, Lynnwood town center through traffic is illustrated by the traffic typebased flow bundle. Only those paths are displayed in the flow bundle that start and end in an
external zone, but between the zones traverse the city center. In illustration 226, the flow
bundle is displayed for the through traffic and for the flow bundle path from external zone 136
to external zone 27.
Illustration 226: Display of through traffic with a flow bundle of active links
Note: To calculate a traffic-type based flow bundle, you need to set at least one link or one
network object of the line hierarchy to passive. To set an object to passive, use the filter (see
User Manual, Chpt. 2.7, page 194) or spatial selection (see User Manual, Chpt. 2.8,
page 217).
In both cases (links or network objects belonging to the line hierarchy), Visum distinguishes
between the traffic types internal traffic, origin traffic, destination traffic, through traffic, external
traffic and bypassing internal traffic. These traffic types partition the number of all paths, i.e.
each path has a unique traffic type.
The following examples refer to a link traffic type flow bundle, for which inner city links have
been set to active and outer city links to passive.
702
Internal trips: Paths used by active network objects only. Example: The flow bundle shows
the paths in the urban area.
PTV AG
Origin demand: Paths starting with an active network object and ending with a passive
network object. Example: The flow bundle shows all commuter flows from the urban area
to its urban hinterland.
Destination demand: Paths starting with a passive network object and ending with an active
network object. Example: The flow bundle shows all commuter flows from the urban
hinterland to the urban area.
Through traffic: All paths that start and end with a passive object, but use at least one active
object in-between. Example: The flow bundle shows HGV traffic traversing a conurbation.
External trips: Paths that do not use active network objects. Example: The flow bundle
shows traffic bypassing a conurbation.
Bypassing internal trips: Paths that start and end with an active network object, but use at
least one passive network object in-between. Example: The flow bundle shows traffic that
starts and ends in an urban area, but that traverses the urban hinterland, e.g. on a
bypassing road that has a higher speed limit.
The table 274 shows which sequence of links (for a link traffic type flow bundle) or of PuT lines
on path legs of a PuT path (for a PuT line traffic type flow bundle) belongs to which traffic type.
For sequences with more than four objects, there are more variants.
Number of links
or PuT lines
Internal trips
1
a
2
a-a
3
a-a-a
4
a-a-a-a
Origin demand
a-p
a-x-p
a-x-x-p
Destination demand
p-a
p-x-a
p-x-x-a
Through traffic
p-a-p
p-a-x-p or
p-x-a-p
External trips
p-p
p-p-p
p-p-p-p
a-p-a
a-p-x-a or
a-x-p-a
Table 274: Traffic type based on status (active / passive) of links or PuT lines
PTV AG
703
The link traffic type flow bundle also allows you to limit PuT supply, e.g. to specific lines (see
"PuT supply filter" on page 705). Only those links are considered active that have been set to
active and that are used by an active PuT line.
Example: Calculation of the number of passengers using long-distance transportation on a link
corridor (completely or partly):
If you want to combine several conditions of the type "Active links" within one flow bundle, you
might have to reverse the active links for the flow bundle, i.e. set all passive links to active and
vice versa. To do so, switch the reference quantity of the link traffic type flow bundle from
"active links" to "passive links" and vice versa.
Example: You want to determine the number of passengers using part of and the entire link
corridor for long-distance transportation, but outside the corridor only use local public transport.
By combining two terms that have different reference quantities you can a) filter paths using a
specific PuT supply on active links and b) filter paths using a specific, but different PuT supply
on passive links.
PTV AG
Internal trips
Through traffic
Origin demand
Destination demand
External trips
Legend
Active PuT supply
Passive PuT supply
Table 275: Significance of traffic types after applying path filter for active PuT lines
For instance, you can perform the following analyses on active PuT lines, using a path filter:
1. Objective: Determine the number of passengers using a long-distance line on at least one
path leg
Only long-distance trains are active. Selection of the network object type lines.
Selection of the traffic types internal traffic, origin traffic, destination traffic, through
traffic and bypassing internal traffic
2. Determine the number of passengers using at least one long-distance line on at least one
path leg and at least one public transport line on one path leg
Only long-distance lines are active. Selection of the network object type lines.
Selection of the traffic types origin traffic, destination traffic, through traffic and
bypassing internal traffic
3. Objective: Determine number of passengers who only use vehicle journeys provided by a
specific operator X.
Only vehicle journeys of operator X are active. Selection of network object type vehicle
journeys.
Selection of the traffic type internal traffic
11.1.3
PTV AG
705
You can choose between different types of PuT supply. The options are: transport systems,
main lines, lines, line routes, time profiles, vehicle journeys and operators. Vehicle journeys
and operators require a timetable-based assignment, for which paths are saved as
connections.
The results obtained with the supply filter depend on the network object type:
nodes and links represent fairly simple examples. The supply filter criteria is met, if the
node or link is traversed by the supply selected. Thereby it is irrelevant whether the paths
traverses the node or link, or starts or ends there.
For zones and main zones, the supply filter filters the first or last path leg - depending on
whether you choose to filter by origin or destination traffic. The options Also PuT-Walk
TSys and Also PuT-Aux TSys are taken into account when Visum checks the connector
node of the path. Consequently, a path starting or ending with a PuT-Walk or PuT-Aux
transport system belongs to the flow bundle, if the respective option has been activated or
the first or last path leg is used for the PuT supply selected.
For stop points, stop areas and stops, Visum distinguishes between two cases:
When determining the number of passengers transferring, you can set supply filters
with the criteria "alighting" and "boarding". This, for instance, allows you to filter all paths
that at a stop switch from long-distance transport to local transport.
Just as for the zones, the options PuT-walk and PuT-Aux play a special role. If you
select "boarding" and the option Also walk TSys, you will also filter by all transfers that
after alighting include a footpath - independent of the PuT supply the passengers
alighted from. The same applies respectively for the option Also Aux TSys.
For all other passenger types, the supply filter is used as described for nodes and links.
When using the traffic type flow bundle conditions for active links, you can additionally filter the
PuT supply. The PuT supply filter is applied directly to the active links. For a traffic type-based
flow bundle, a link on a PuT path is considered active, if both the link itself and the PuT supply
on it are active.
11.1.4
706
PTV AG
Illustration 227: Paths which start in zone 102 and end in zones 1, 2 or 5
PTV AG
707
Illustration 228: All paths which traverse a link section in north direction
Notes: Any number of nodes, main nodes, stops, stop areas, stop points and links can be
linked in any order.
Zones and main zones can only be the beginning or end of a path and can therefore not be
traversed.
Flow bundle conditions for network objects (see "Flow bundle definition through selection of
network objects" on page 699) and flow bundle conditions for traffic types (see "Flow bundle
definition through selection of traffic types" on page 701) can be combined through the AND
operator. In this case, however, the sequence is not specified, as traffic type flow bundles
always refer to the entire path. This is why there are used at the end of AND THEN operations.
Note: You can use the AND operator to combine various traffic type flow bundle conditions or
to combine traffic type flow bundle conditions with network object flow bundle conditions.
The following example shows the flow bundle of illustration 226, for which two additional links
were selected. The flow bundle filters the Lynwood through traffic, traversing the two links in
the sequence specified.
708
PTV AG
Illustration 229: Through traffic traversing the two links in the sequence specified
PTV AG
709
The examples show that the negated network object flow bundle conditions are always
evaluated for an area between positive network object flow bundle conditions. If the sequence
is not important, you might have to add the negated conditions a few times (see example 4).
The sequence is not important for traffic type-based flow bundle conditions. This means that
when you use a complement, it produces a simple logic negation - which corresponds to the
selection of a complementary traffic type set.
Defining an OR operation
Adding an OR operation ends a series of AND THEN operations. Then you can add additional
conditions. A flow bundle describes all paths that fulfill at least one of the filter criteria linked to
an OR operation.
Any number of AND THEN operations can be linked by OR operations. Each path is only
output once with the flow bundle, even if it is found for several AND THEN operations.
The illustration 230 shows how you can simultaneously show a PrT flow bundle and a PuT flow
bundle, using an OR operation. The PrT flow bundle shows all PrT paths traversing nodes
106,062,539 and 106,062,191. The PuT flow bundle shows all PuT paths traversing stops
106,061,623 and 106,063,464.
710
PTV AG
Illustration 230: Combining flow bundles for PrT and PuT by using an OR operation
11.1.5
PTV AG
711
Illustration 231: Link flow bundle with AND THEN operation and OR operation
In illustration 232, a flow bundle of alternative routes is displayed for the same flow bundle
criteria as in illustration 231. For all OD pairs for which paths were found in the origin flow
bundle, the paths are listed that do not traverse the link section selected. The comparison of
the two illustrations shows, that most traffic uses the by-pass on these OD pairs. Only a few
road users choose the routes which lead through the city. In a planning project the
effectiveness of a created measurement could thus be allocated.
712
PTV AG
11.2
Isochrones
Based on one or several selected network objects, isochrones visualize the accessibility of all
other network objects.
The accessibility can be classified in intervals that are highlighted in different colors in the
Network editor. You can, for instance, highlight all towns in the same color that can be
accessed from a specific node within a certain time.
In practice, isochrones are used to analyze the catchment area of stops. In illustration 233, all
stop areas in the urban area were highlighted and then an isochrone calculation was
performed. You can see, that especially potential PuT passengers from the eastern part of the
city (highlighted in dark red) need more than 8 min to the next stop.
PTV AG
713
The illustration 234 illustrates the effectiveness of isochrones in a simple example. In this
example, isochrones were drawn based on node 20. The travel time in the loaded network
(tCur) was used as the path-choice criterion. The links were labeled with these times. The link
segments were highlighted in different colors depending on their accessibility (here depending
on tCur) (see User Manual, Chpt. 12.3.7, page 1415). If you e.g. travel from node 20 via node
11 to node 41, the in-vehicle time is 29min 35s. Accordingly, the last link section before node
41 is highlighted in dark red, as from here your journey is longer than 26min.
714
PTV AG
If several network objects are selected for isochrone display, the shortest path from the
selected network objects to the link section is calculated for each link section. The shortest of
these shortest paths then determines which accessibility interval is assigned to the link section.
If e.g. nodes 21 and 31 are selected for the isochrone display and a link section can be reached
from node 21 in 22min and from node 31 in 28min, the link section is assigned to the
accessibility interval <= 22min and is highlighted accordingly.
Note: The accessibility of network objects can be calculated and displayed simultaneously for
both PuT and PrT.
11.2.1
PrT isochrones
The accessibility of network objects is determined via a shortest path search. Thereby the
following attributes are used as search criteria:
Note: When selecting the route choice criterion, note that t0, tCur and Impedance
correspond to each other as long as no assignment has been calculated.
You can use nodes, main nodes and zones (or a combination of them) as reference points of
PrT isochrones.
PTV AG
715
The results of PrT isochrone calculation are listed under the attribute Isochrones time PrT of
nodes, main nodes and zones. The minimum run time is listed for each network object.
The following options are available for displaying PrT isochrones graphically in the Network
editor:
716
PTV AG
11.2.2
PuT isochrones
PuT isochrones are used to analyze the accessibility of nodes, stops, stop areas, stop points
and zones within a specified time interval. Accessibility is determined based on a timetablebased connection search. The search can be based on a departure or an arrival time interval.
In the first case, you determine all connections leaving from the network object selected within
a certain time period, including an additional time span. This time span is entered after you
have selected the departure period and refers to the time within which the connection must
reach the destination.
In the second case, you analyze all connections that arrive at the network object selected
within a certain time period and you enter a lead time. This is the time span directly before the
arrival period specified and during which the connections must leave their starting point.
You can use nodes, stop areas and zones (or a combination of them) as reference points of
PuT isochrones.
You can find the results of PuT isochrone calculation in the attributes Isochrones time PuT
and Number of transfers PuT for nodes, stops, stop areas, stop points and zones. For each
network object, the minimum journey time and minimum number of required transfers is listed.
Please note that both values might appear in different connections, i.e. there is not necessarily
one connection with both the minimum journey time and the minimum number of transfers.
The results depend on the time intervals specified. You can influence the calculation (except
for the time reference), by limiting the search to active vehicle journey sections or by specifying
a maximum number of transfers.
The following options are available for displaying PuT isochrones graphically in the Network
editor:
PTV AG
717
2D drawing
The attributes Isochrones time PuT and Isochrones number of transfers PuT can be
used in 2D to classify the accessibility intervals.
Classified representation of nodes, zones, stops, stop areas and stop points
The attributes Isochrones time PuT and Isochrones number of transfers PuT can be
used for a classified representation of one or several network object types.
Isochrone display in 2D
For 2D display, the network background is highlighted in color depending on the individual
accessibility intervals.
In illustration 237, this type of representation is used to visualize the attribute Isochrones time
PuT, i.e. the time required to access stop areas. The main train station is highlighted, i.e. the
isochrones show the PuT journey time starting from the main train station.
Illustration 237: 2D display of the accessibility of stop areas from the main station
718
PTV AG
Illustration 238: Classified display of stops on the basis of the isochrone time PuT
PTV AG
719
Illustration 239: Classified display of stops on the basis of the isochrone number of transfers
11.2.3
720
PTV AG
The exact figures are provided in the list view (see illustration 241). The exact Isochrones
Time PrT is 2min 50s, the Isochrones Time PuT is 5min 25s.
PTV AG
721
11.3
An interactive shortest path search can be used especially to find errors in network modeling.
With the graphic output of the shortest path, you can quickly determine implausible shortest
paths in the network editor. It could thus occur, that links for a transport system were
mistakenly blocked by the modeler and therefore an unexpected path between two nodes is
assumed as the shortest path. With the shortest path search you can find such paths and undo
the road closure if necessary.
722
PTV AG
You can also specify whether you consider a shorter journey time or less transfers more
favorable for the shortest path search. You can search for a timetable-based shortest path
between two zones or two stop areas.
The transport system-based shortest path search does not differentiate between individual
PuT lines. Modeling the transport supply only considers the links of a basic network with their
specific run times. A basic network may include the following three options:
A graph is created from the links of this basic network. If forms the basis for a shortest path
search. Because individual lines are not distinguished, transfer stops with their respective
transfer times cannot be included in the search. However, it is possible to include transfer times
between different transport systems (transfer penalties for transport system transfers, such as
between bus and train). The transport system-based shortest path search can be performed
for an area between two zones or two nodes.
PTV AG
723
724
PTV AG
12
PTV AG
725
Subjects
12.1
Lists
Bars
Categorized display with attribute values
Labeling with tables
Labeling with charts
Turn volumes
Desire lines
Stop catchment areas
PuT transfer relations
PuT connections and transfer flows
Lane allocation
2D display
Schematic line diagram
Signal time-space diagram
Column charts
Evaluations in the timetable editor
Lists
Use lists for the following applications:
To get an overview of the network object data of your model and network analyses results
in table form
To save attribute files for the exchange with other Visum models
To export any attribute of the list in a database or in a spreadsheet
To simultaneously change the attribute values of multiple network objects, as efficiently as
in spreadsheets
To display the set of network objects, which correspond to the set filter criteria
To perform attribute-classified analyses on the properties of network objects
The list columns contain freely selectable attributes, the rows contain different objects. There
are two types of lists, specific lists for each network object type and evaluation lists.
12.1.1
726
PTV AG
Using lists, you can access both the direct and indirect attributes of network objects (see User
Manual, Chpt. 2.2, page 146). Indirect attributes are attributes of other network objects, e.g. in
a zones list, you can view the number of origin connectors. You can sort nearly all lists
(exception: path lists) by any column.
The network object data is not only readable, you can also change it directly in the list view. To
do so, simply enter a new value. You can change any editable attributes. To have more
options, activate the Extended input options (see User Manual, Chpt. 12.1.3, page 1373) for
attributes whose specification is limited. You can then change attributes, such as TSysSet, in
a separate window. For attributes including an enumeration type, a list box of options is
displayed in clear text format.
The list allows you to make changes efficiently to several objects and/or attributes at the same
time. To do so, simply highlight the cells you want to change and enter a new value. The new
value is then adopted for all highlighted cells. When making your changes, you cannot only
enter constant values (e.g. "2"), but also simple calculation procedures. If, for instance, you
want to double the length of all links, in the "Links" list, highlight all the cells of the "Length"
column. Enter "=*2" and Visum multiplies each cell value by 2. This option is also available via
the context menu (Arithmetic operations on marked section). When using lists, you can
also use the Windows Clipboard for data exchange, i.e. the Copy and Paste commands for
data exchange with a Microsoft Excel file. To exchange larger amounts of data, you can export
the list content into databases or ASCII-based Visum attribute files (*.att).
Thereby each row in the list represents a network object. Commands for network objects are
also available in the list context menu. To change attributes, you can also open the Change
network object dialog box. The dialog also allows you to delete objects and provides special
functions as the display of column diagrams. If you highlight the cells of several rows, all
changes made using the context menu or the Network editor, will apply to all highlighted
objects. Another option is to open the Multi-edit dialog for the respective network object, which
e.g. allows you to assign attribute values via formulas. Moreover, it provides all the special
Multi-edit functions.
You can synchronize lists of network objects with the Network editor, if they have an own mode
in the Network editor (see User Manual, Chpt. 12.1.9, page 1386). Highlighting objects in the
list then also highlights the same objects in the Network editor window. You can specify to keep
the current view, to show the highlighted network object or to auto zoom into the highlighted
area. Highlighting objects in the network will also highlight the same objects in the list.
Synchronization further allows you to easily perform analyses, e.g. to search for the ten links
with the highest volume, simply show the respective volume attribute in the link list. Then sort
the list by this attribute in descending order and highlight the first ten rows. If you have
activated synchronization, you can then see the respective objects in the Network editor
window.
The synchronization option is also available for some other lists. However, in this case,
synchronization only works in one direction. Highlighting objects in the list will highlight the
same objects in the network, but this does not work vice versa, as other object types cannot be
highlighted in the network. Examples would be item lists (e.g. line routes), paths (PrT paths,
PuT paths) and line blocks. In these lists, you can highlight a row and the geographical course
of the respective object is then also highlighted in the network.
You can aggregate the display of network objects in lists. To do so, select an attribute by which
you want to group the objects. Network objects with the same attribute value are then grouped
in a row. Then an aggregation function is applied to the attribute values of the grouped network
PTV AG
727
objects and its value is displayed. Typical aggregation functions are sums, minimum,
maximum, average and weighted mean. You can also use comparison, concatenate,
frequency of occurrence, and distinct occurrence. The frequency of occurrence indicates how
often a value occurs in the data of an aggregated row. The aggregate function distinct
occurrence only lists all occurring values. You can also group network objects by several
attributes at the same time. An example would be an analysis of transferring passengers by
transport systems: In the passenger transfer list, you could show the transport system code of
the from-time profile item and the to-time profile item as indirect attributes. Then you could
group the data by these two columns. As aggregation function for the volume attributes, you
would choose sum. The result is displayed in a from-transport system row and a to-transport
system row. If have not limited your selection to a stop, you can also group the objects by stop
numbers to receive a network-wide overview of the passengers transferring between transport
systems. To copy such a view to a spreadsheet program, highlight all cells. In the same way,
you can perform similar analyses and validity checks or e.g. use the links list to calculate the
average volume of specific links.
12.1.2
Territory lists
Both territory lists contain PrT and PuT indicators precisely broken down. This is how the
indicators can be calculated based on spatial territories, for example the service kilometers
which lie within a county (see "Spatial cut (Territory cut)" on page 646). The sublists Basis and
PuT detail are available for territories.
728
PTV AG
Basis
The list outputs precise indicators of PrT and PuT for each territory. Dependent on the
indicator, an assignment or the procedure territory indicators or PuT operating indicators have
to be calculated before.
Hint
To get more detailed information on how to calculate the values for this list, have a look at the
files IndicatorOrigin.xls and IndicatorAvailability.xls in your Doc directory of your Visum
installation.
PuT
detail
For PuT, the indicators for each territory can be refined on the following levels of the line
hierarchy, and if desired also per vehicle combination (see "Spatial cut (Territory cut)" on
page 646).
Territory x Transport system
Territory x Main line
Territory x Line
Territory x Line route
Territory x Time profile
Territory x Vehicle journey
Territory x TSys x Vehicle combination
Territory x Main line x Vehicle combination
Territory x Line x Vehicle combination
Territory x Line route x Vehicle combination
Territory x Time profile x Vehicle combination
Territory x Vehicle journey x Vehicle combination
This is how you can evaluate service kilometers per line within a territory for example.
Note
The list only contains entries after the procedure PuT operating indicators has been
calculated.
OD pair lists
In an OD pair list you can output the following attributes for each relation between two zones:
Note: The matrix values can also be edited in this list, so that you do not have to switch to the
matrix editor.
Stop lists
Visum provides lists for the network object stop, stop area and stop point. In addition to the
base list for the network objects themselves, you can also find a list for the timetables at stop
points and the transfer times between the stop areas of the stops, the transport systems, and
the time profiles.
PTV AG
729
Stop points
The list exports the vehicle journeys and attributes of any stop point selected by the
arrivals/departures user such as, Arrival and Departure. As an option, you can also filter according to
time profiles at the selected stop point.
Transfers and stop For each stop, the list contains the transfer walk times and the passenger transfers
area walk times in per transport system between the stop areas of the stop. Use the list for example, if
stop
you want to change the transfer times of multiple stops. You therefore do not have
to open the window Edit stop for each individual stop, to change the times.
Time profiles:
Transition walk
times
For each stop, the list contains the transfer times between the time profiles of the
stop.
Transport systems: For each stop, the list contains the transfer times between the transport systems of
Transition walk
the stop.
times
Item lists
In addition to basis lists (for example line route list) for the network objects of the line hierarchy
and for system routes, item lists are also offered (for example the line route items list). These
lists contain the individual elements (items) of the network object. These are:
Line route items
All profile points of a time profile (see User Manual, Chpt. 2.31.3.3, page 467)
All profile points of the time profile which are traversed by the vehicle journey
selected by the user
All nodes and stop points which lie on the system route
In items lists, you can switch between the section view and the classical view. The classical
view displays the sequence of fixed points like stop points, route points or profile points, while
the section view focuses on the items between these points (see User Manual, Chpt. 12.1.6.2,
page 1381).
Line lists
In addition to the base list for network objects of the line hierarchy and the respective course
lists, Visum offers two special lists for coupling.
Coupling sections
All coupling sections with their From stop point No and To stop point No. This
is how you can illustrate which stop points are coupled between which time
profiles.
Coupling section items The list shows which time profile is coupled between which time profile
elements.
730
PTV AG
Line blocks
The list shows the line blocks of all line block versions. As an option, only the line
blocks of a line block version selected by the user can be displayed.
The individual elements of all line blocks are contained in this list. The list shows the
parts which make up a line block and in which order these are traversed (vehicle
journeys, empty trips, stand times, but also user-defined line block item types). As
an option, only the items of a line block version selected by the user can be
displayed.
12.1.3
Matrix list
The matrix list shows an overview of all matrices.
12.1.4
Evaluation lists
Evaluation lists only contain results from calculations or statistical values on the network
model. Their entries can therefore not be edited. An example is the PrT path list:
Lists the paths calculated in a PrT assignment for the selected demand
segment. The rows contain the paths from an origin zone to a destination
zone.
PTV AG
731
Compared to the PrT path list, the links which lie on the path are listed
additionally for each path. This is how the exact course of the path can be
comprehended.
OD pairs PuT
Lists aggregated skims for each OD pair, which were calculated for the
routes or connections found with the assignment.
Note
You must calculate the skims beforehand for PuT with the assignment or
in a separate procedure (see "PuT skims" on page 437), for PrT via the
procedure Calculate skim matrix (see "PrT skims" on page 290).
PuT paths
Lists the paths calculated in a PuT assignment for the selected demand
segment. The rows contain the paths from an origin zone to a destination
zone.
Lists all path legs (see "Network model" on page 29) of each route or
connection of an OD pair from an origin zone to a destination zone for the
selected demand segment, found by the PuT assignment.
732
PTV AG
Statistics Goodness of
PrT assignment
Statistics - Goodness of
PrT assignment with ICA
Statistics - Assignment
analysis
Output of the statistical evaluation of the assignment analysis for PrT or PuT
(see "Assignment analysis PrT" on page 426 and "Assignment analysis
PuT" on page 506)
Statistics PuT
assignment statistics
Output of indicators for PuT assignments which refer to the entire network
Note
The indicators are calculated automatically with a PuT assignment (see
"Transport system-based assignment" on page 450).
Emissions HBEFA
12.2
Bars
You can draw links and connectors, whose width complies with the values of an indirect or
direct attribute of the link or the connector (see User Manual, Chpt. 12.5, page 1428). The link
volume from a PrT assignment can thus for example be visualized, like in illustration 246, by
scaling the link bar with the attribute Volume [Veh] PrT.
PTV AG
733
Connector bars can also be drawn. In illustration 247 the attribute Volume [Veh] PrT is
displayed on the connectors.
734
PTV AG
You can draw as many bars as you like with different attributes along the link or connector. This
is how you can simultaneously display the volume from a PrT assignment (attribute Volume
[Veh] PrT) and the volume from a PuT assignment (attribute Volume [Pass] PuT) on a link,
as can be seen in illustration 248.
PTV AG
735
Illustration 248: Two link bars with PrT and PuT volume
12.3
736
PTV AG
PTV AG
737
738
PTV AG
Bars (see "Bars" on page 733) can also be displayed in categories. In dependency of attribute
Saturation PrT, the link bar is colored red, green or yellow in illustration 252.
PTV AG
739
12.4
740
PTV AG
Illustration 253: Table display of boarding passengers, transfers and alighting passengers at stops
12.5
PTV AG
741
You can also display the results of the mode choice (see "Mode choice" on page 130) the
distribution of travel demand to the individual transport modes for each zone in a pie chart
(illustration 255).
742
PTV AG
Illustration 255: Display of the mode selection as pie charts for zones
12.6
Turn volumes
Turn volumes visualize attributes of turns (see "Network model" on page 29) at individual
nodes (see User Manual, Chpt. 12.14, page 1486). If you select the attribute Volume [Veh]
PrT (AP) for example, after an assignment you can illustrate which traffic volumes apply to the
turns of a node (illustration 256).
The turn attributes can also be displayed in a turn list (see "Lists" on page 726).
Tip: In the junction editor, you can also display turn volumes (see User Manual, Chpt.
2.40.18, page 637).
PTV AG
743
12.7
Desire lines
A desire line visualizes the values for relations between zones (From zone to To zone). The
values displayed on the desire line may derive from different origins.
From a demand matrix (for example to visualize the demand between zones)
From a skim matrix (for example to visualize the journey time between zones)
As a value from the network model itself (for example the direct distance between zones)
From a zone attribute of the From zone or the To zone of the relation (for example to
illustrate the From zone\origin traffic to other zones)
For each OD pair you can draw both a desire line link as well as one or more desire line bars
for a proportional display of the values (see User Manual, Chpt. 12.13, page 1481).
The display of desire lines is useful for illustrating demand matrices and indicator matrices in
the network editor. This is how you can get an overview, which OD pairs (From zone to To
zone) are especially in demand, for example. The example shown in illustration 257 shows the
travel demand between the zone Oppidum and all other zones. It is clear, that there is an
especially high demand between the zones Oppidum and B town.
744
PTV AG
Illustration 257: Desire line with bars scaled at the demand between zones
The desire line is drawn on the linear distance between the zones. If you are interested in the
exact course of the paths between origin and destination zones, use the Shortest Path
Search (see User Manual, Chpt. 11.3, page 1360).
Combined with the OD pair filter (see User Manual, Chpt. 2.7.6, page 210) the display of the
desire lines on OD pairs, which correspond to the filter criteria, can be confined. As an
alternative, the number of the OD pairs displayed can also be displayed via a classified display
(see User Manual, Chpt. 12.2, page 1400).
Furthermore, the desire line can also be drawn classified. As shown in illustration 258, you can
highlight OD pairs with a high traffic demand with colors, for example.
PTV AG
745
Illustration 258: Desire line with bars classified according to the demand between zones
12.8
746
PTV AG
Stop catchment areas can also be drawn classified. In illustration 260 catchment areas with a
radius of 300m are drawn around the stops. The circles of stops with more than 1,000
departures per analysis period are red, stops with less than 500 departures are orange, and
stops with less than 100 departures are displayed in green. This is how you can display how
strongly stops are frequented and how the entire network is made accessible by PuT, in a
graphic.
PTV AG
747
Illustration 260: Stop catchment areas classified according to the number of departures
12.9
748
PTV AG
12.10
PTV AG
749
The assessment of connections is an important task for a planner. The view allows a detailed
evaluation of connections and consistent connections, in particular in combination with
differentiated demand flows. You can easily test and analyze the impact of several service
variants on the demand flows at important transfer points.
The view of the clock-face primarily allows an analysis of transfer flows according to temporal
aspects. Respective evaluations can be supplemented by the graphic display of the spatial
transfer relations between stop areas in the network.
12.11
Lane allocation
To visualize the node topology in the network editor (see "Junction modeling" on page 78) you
can graphically display the lane allocation at nodes. A rectangle is then drawn for each
outgoing link of a node, which is open for one or more PrT transport systems and which has
one or more lanes. Inside the rectangle, an arrow is drawn for each approach lane and an
arrow head for each permitted lane turn. The illustration 263 shows an example of a node with
four legs.
750
PTV AG
A classified display is also possible for the lane allocations, by direct and indirect node
attributes. This is how you can export the lane allocation in different colors, depending on the
node volume. The illustration 264 demonstrates this with an example of a roundabout.
PTV AG
751
12.12
2D display
For point objects, (for example nodes or stops) the two-dimensional (extrapolated) display type
can be actuated for display of the distribution of attribute values. Any numerical attribute can
be selected for display of extrapolated attribute values.
The attribute value of the point object is extrapolated over the entire network area. For twodimensional visualization, up to 10 value ranges can be defined with a specific background
color assigned to each interval.
The extrapolation process:
Based on each Visum object of the selected point object class (nodes, zones, ...) an
extrapolated value is computed for each pair of co-ordinates in the network area. In this
process, the extrapolated value rises linearly with growing distance from the point object.
The rising speed is specified as parameter v-access.
The final extrapolated attribute value of a pair of co-ordinates is the minimum of all attribute
values calculated from all Visum objects.
Example
Node P1 with co-ordinates (x,y) = (0,0) has AddVal1 = 100. Point P = (300, 400) has a distance
2
of 500 = 400 + 300 to P1. This distance is 500m if the network scale is 1. Using V-access
= 5 (km/h), the AddValue will rise by 360, because for 500 m exactly 360 seconds are required
if speed = 5 km/h. The P1-related extrapolated AddValue of point P sums up to 100 + 360 =
460.
Finally, the minimum of all extrapolated values calculated by Visum from all point objects Pi of
the network is the extrapolated AddVal attribute value of point P.
Based on user-defined classification intervals, the graphical display of attribute value
distribution will show rings of value ranges having specific colors around any point object
(illustration 265) of the selected class.
752
PTV AG
Originally, this display type has been implemented in Visum for graphical display of isochrones
(see "Displaying isochrones and the accessibility of network objects" on page 1349) showing
accessibility of network objects.
For the extrapolation of numerical attributes of Visum point objects, the input parameters do
not necessarily have to be of the speed or time data type.
PTV AG
753
12.13
12.13.1
12.13.2
754
PTV AG
edge courses between two transfer nodes, the number of edges resulting from the relevant
start and end points of the edges of one of the following objects:
This allows you to realize different views of the timetable (passenger view, operation level).
The number of edges between the two transfer nodes results from vehicle journey aggregation
performed on a chosen aggregation level (see User Manual, Chpt. 12.16.8, page 1517).
Besides the 'typical' aggregation of the vehicle journeys based on the service pattern or lines
between the transfer nodes, further aggregation levels can be chosen:
Some aggregation levels distinguish between directed and undirected. This way you can
control if one edge course each will be created between the transfer nodes or only one
common edge course for both "running directions". In the case of the other aggregation levels
which relate to vehicle journey-based attributes, an undirected display does not make sense;
therefore only directed edge courses will be created.
For the aggregation by service trip pattern number, the respective input attribute will be used.
It can either be determined manually, via the Calculate service trip patterns (see User
Manual, Chpt. 6.5, page 1152) procedure or the respective Multi-edit functionality for vehicle
journeys. There you will find the description of the algorithms for the calculation of the service
trip patterns.
For edge courses, you can specify the standard graphic parameters for line objects. As a
special feature, you can classify edge courses on two classification levels, for example to
combine a display of the service frequency with the standard colors for specific lines. For the
illustration of the service frequency in particular, several new line styles featuring up to four
parallel lines can be selected (see User Manual, Chpt. 12.16.5, page 1504).
For coupled vehicle journey sections, you can display branches in the schematic line diagram.
Furthermore, you can bundle edge courses manually. This way you can display supplies as
such, where a headway of an hour can be achieved by an alternate service of a main section
instead of lines operating with a headway of two hours with deviating destinations.
The edge courses can be labeled with attribute values at the start transfer node and end
transfer node each and at the center of the course. For the transfer nodes, up to three attribute
values can be used for the label within or at a chosen position outside of the rectangle.
For the classification and labels of the edge courses, some attributes aggregated from the data
of the underlying vehicle journeys are available:
PTV AG
755
Headway
Departure and arrival times
Number of stopovers
Run times
Volumes
In addition, relations to vehicle journey items and to the opposite direction are available. They
provide access to further aspects of the data model.
12.13.3
12.13.4
756
PTV AG
lost, i.e. Visum "remembers" that there used to be an edge course for line A between transfer
node 123 and 987 with a manually adjusted course, even if the edge is not displayed any more.
This information is used again when requesting an edge course with the same key once more.
You can, however, explicitly empty this "memory" of the schematic line diagram.
The dynamic allocation of vehicle journeys to edge courses and the preservation of the layout
information on hidden edge courses allows you to retain a display despite of changes to or a
complete exchange of the timetable data (with deviating vehicle journey numbers) and use it
on other supply variants. In particular, this mechanism allows the use of the schematic line
diagram together with the scenario management, when, for example, creating a line diagram
with the desired layout in the base version which will then be automatically adjusted to the data
of the scenario when opening scenario results.
12.14
PTV AG
757
758
PTV AG
The offset of the signal controls can be edited directly in the diagram in order to synchronize
the green bands.
A user-defined PrT path which shall be used for the opposite direction, must have at least two
nodes in common with the path of the first direction and all intermediate nodes must be
traversed in reverse order. This requirement permits the use of two separate paths for the
display and thus, for example, the consideration of lanes divided by direction.
12.15
Column charts
You can create column charts with values of direct and indirect attributes (see "Attributes" on
page 94) from the network editor, for individual network objects (see User Manual, Chpt. 12.14,
page 757). You can create common chart displays directly from Visum, without having to
export list contents to Excel, to create the graphics there.
There are two standard types of column charts:
Column charts for time intervals: If you have defined time intervals (see "Spatial and
temporal correlations in Visum" on page 84) in your model, you can display an attribute for
each time interval, for a network object. This function especially supports you when
analyzing dynamic assignments. The illustration 268 shows a column chart, for which three
columns with the passenger volume for the entire PuT, the tram and the bus are drawn for
a link, for each time interval.
Column charts for relations between network objects. For a network object (for example
stop), you can display attributes, linked via the Visum data model network object (for
example the stop points of a stop) as column charts. In illustration 269, a column chart was
invoked for the stop Durlacher Tor and a column was drawn for each network object stop
point. As you can see, the stops are assigned three stop points, for which each the number
of boarding passengers, alighting passengers and transfers is displayed as a column chart.
PTV AG
759
12.16
Tabular timetable
In the standard view, the tabular timetable is presented as in illustration 270.
760
PTV AG
In the regular service mode (see User Manual, Chpt. 2.43.4, page 663) all vehicle journeys are
displayed as regular services with the additional attributes Headway start, Headway end,
Headway time and Number of vehicle journeys (illustration 271).
PTV AG
761
You can also display the columns of the tabular timetable as classified (see User Manual, Chpt.
12.2, page 1400). In the following example, the table background is classified by revenues
(illustration 272).
762
PTV AG
Graphical timetable
Vehicle journeys and vehicle journey sections are displayed graphically in the graphical
timetable. In illustration 273, the stroke display is classified according to lines (see User
Manual, Chpt. 12.2, page 1400), to distinguish vehicle journeys of different lines by using
different colors.
PTV AG
763
Illustration 273: Graphical timetable with classified display of vehicle journey line style properties
Item bars, which can be scaled with direct and indirect vehicle journey or vehicle journey
section attributes, can be drawn for vehicle journeys and vehicle journey sections (see User
Manual, Chpt. 12.2, page 1400). In the following example, the Volume of the vehicle journeys
is used as scaling attribute (illustration 274).
764
PTV AG
Item bars can also be classified (see User Manual, Chpt. 12.2, page 1400). In illustration 275
classification is carried out with the vehicle journey volume.
PTV AG
765
Illustration 275: Classification of item bars with the vehicle journey volume
Visum offers the possibility of displaying multiple bars with different attributes on vehicle
journeys or vehicle journey sections (see User Manual, Chpt. 12.2, page 1400). The
illustration 276 displays bars for Boarding passengers, Alighting passengers and Through
passengers.
766
PTV AG
Illustration 276: Display of item bars for boarding passengers, through passengers and alighting
passengers
PTV AG
767
768
PTV AG
Literature
Bellei, G.; Gentile, G.; Meschini, L.; Papola, N.: A demand model with departure time choice for withinday dynamic traffic assignment. In: European Journal of Operational Research 175 (2006), No.
3, pages 1557-1576 (available online at URL http://www.sciencedirect.com)
Bellei, G.; Gentile, G.; Papola, N.: A within-day dynamic traffic assignment model for urban road
networks. In: Transportation Research B 39 (2005), No. 1, pages 1-29 (available online at URL
http://www.sciencedirect.com)
Bregman, L. M.: Ein Beweis der Konvergenz des Verfahrens von G.W. Sheleikhovski fr ein
Transportproblem mit Beschrnkungen (in Russian). Shurnal vycisl. mat. i mat. fiz. 7 (1967),
No. 1, pages 147-156 (Convergence of the procedure)
Bregman, L. M.: Eine Relaxationsmethode zur Bestimmung des gemeinsamen Punktes konvexer Mengen
und ihre Anwendung zur Lsung konvexer Optimierungsaufgaben (in Russian). Shurnal vycisl.
mat. i mat. fiz. 7 (1967), No. 3, pages 620-631 [Engl. translation: The relaxation method of
finding the common point of convex sets and its application to the solution of problems in
convex programming. U.S.S.R. Computational Math. Math. Phys. 7 (1967), pp. 200-217]
Brilon, W.: Traffic engineering and the new German highway capacity manual. In: Transportation
Research A 28 (1994), No. 6, page 473 (available online at URL http://www.sciencedirect.com)
Brilon, W.; Weinert, A.: Bemessungsverfahren fr Knotenpunkte mit abknickender Vorfahrt. In: Straenverkehrstechnik 7, 2002, pages 346-356.
Bundesministerium fr Verkehr (publisher): Richtlinien fr den Lrmschutz an Straen, Ausgabe 1990
(RLS-90). Federal Ministry of Transport, Building and Urban Affairs, 1990
EMNID-Institut GmbH (publisher): KONTIV 89: Bericht zur Methode. Anlagenband und Tabellenteil.
Bielefeld, 1991 (Method report)
Evans, A. W.: Some properties of trip distribution methods. In: Transportation Research 4 (1970), No. 1,
pages 19-36 (available online at URL http://www.sciencedirect.com)
Evans, S. P.; Kirby, H. R.: A three-dimensional Furness procedure for calibrating gravity models. In:
Transportation Research 8 (1974), No. 2, pages 105-122 (available online at URL http://
www.sciencedirect.com)
Frschner, G.: Verkehrsplanerische Berechnungsmethode des Straengterverkehrs. In: Wissenschaft
und Technik im Straenwesen, Heft 20, Berlin, 1982 (Transportation planning calculation
method)
Forschungsgesellschaft fr Straen- und Verkehrswesen (publisher): Leitfaden fr
Verkehrsplanungen. Kln : FGSV, 1985. (Road Traffic Resarch Association in Germany), 1985
Forschungsgesellschaft fr Straen- und Verkehrswesen (publisher): Richtlinien fr die Anlage von
Straen, Teil: Wirtschaftlichkeitsuntersuchungen (RAS-W86). Kln : FGSV, 1986 (Road
Traffic Resarch Association in Germany)
PTV AG
769
770
PTV AG
Leutzbach, W.; Haupt, T.; Mott, P.: Ermittlung der Verkehrsnachfrage. In: Forschung Stadtverkehr, Reihe
Auswertungen, Heft A4, 1988. (Determination of Travel Demand)
Lohse, D.: Berechnung von Personenverkehrsstrmen. In: Wissenschaft und Technik im Straenwesen,
Heft 17, 1977 (Calculating passenger demand flows)
Lohse, D.; Teichert, H.; Dugge, B.; Bachner, G.: Ermittlung von Verkehrsstrmen mit n-linearen
Gleichungssystemen Verkehrsnachfragemodellierung. Scientific series of Institut fr
Verkehrsplanung und Straenverkehr of TU Dresden, Vol. 5, p. 102, 1997 (Calculating
passenger demand flows)
Lohse, D.; Wegener, B.: Abschnitt 3: Verkehrsplanerische Berechnungsverfahren. In: Bauakademie der
DDR (publisher): Richtlinie fr Stadtstraen. Teil I: Methoden und Verfahren der stdtischen
Verkehrsplanung, Ausgabe 1981. Berlin : Bauinformation, 1982 (Transportation planning
calculation procedures)
Mcke, P. A.; Ruske, W.: Straenverkehrstechnische Untersuchungen fr den zweiten Ausbauplan. In:
Strae und Autobahn 19 (1968), No. 6, pages 201-211 (Transportation planning analyses)
Mhring, R.; Nkel, K.; Wnsch, G.: A model and fast optimization method for signal coordination in a
network. In: van Zuylen, H.; Middelham, F. (publisher): Proceedings of the 11th Symposium on
Control in Transportation Systems - CTS 2006, pages 73-78, Delft, 2006
Nordic Council of Ministers (publisher): Road Traffic Noise: Nordic Prediction Method. Tema Nord 1996:
525. Denmark : Nordic Council of Ministers, 1996. ISBN 9291208361
Norm DIN 18005 Teil 2 September 1991. Schallschutz im Stdtebau: Lrmkarten; Kartenmige
Darstellung von Schallimmissionen. Berlin : Beuth Verlag, 1991 (Noise Prevention in Urban
Development)
Ortzar, J. D.; Willumsen, L. G.: Modelling Transport. Chichester : Wiley, 1990
Ortzar, J. D.; Willumsen, L. G.: Modelling Transport. Third edition. Chichester : Wiley, 2001
Salzwedel, J.: Untersuchungen zur Einordnung der verkehrsplanerischen Berechnung des Gter- und
Wirtschaftsverkehrs in das Modell- und Programmsystem PEVA. (Transportation planning
analyses). Dresden, Technische Universitt, Institut fr Verkehrsplanung und
Strassenverkehr, Diplomarbeit, 1997 (Degree dissertation)
Schiller,
C.:
Integration
des
ruhenden
Verkehrs
in
die
Verkehrsangebotsund
Verkehrsnachfragemodellierung. Scientific series of Institut fr Verkehrsplanung und
Straenverkehr of TU Dresden, Vol. 8, 2004 (Transport supply and Traffic demand modelling)
PTV AG
771
772
PTV AG
List of illustrations
Illustration 1: Visum network model and impact model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Illustration 2: Example of the temporal distribution of travel demand by four intervals of 30 minutes . . . . 6
Illustration 3: Network of the original version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Illustration 4: Network of the version used for version comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference are displayed. "Verscomp" is the name of the version comparison. . . . . . . . . . . . 13
Illustration 6: Network 1 used for merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Illustration 7: Network 2 used for merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Illustration 8: Merge network of network 1 and network 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Illustration 9: Configuration of the Scenario calculation server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Illustration 10: Connection between transport systems, modes, demand segments and demand matrices . 34
Illustration 11: Example of a TURNSTANDARD table in the network file, which is used to specify
standard values for turn penalties and turn capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Illustration 12: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red) . . . . . . . 42
Illustration 13: Examples for defining transport systems of a link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Illustration 14: Example for the different speeds of two PrT transport systems depending on the volume. . . 44
Illustration 15: Transportation demand between zones illustrated in the transport network and as a
demand matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Illustration 16: Supply of the travel demand via connectors to the network . . . . . . . . . . . . . . . . . . . . . . . 47
Illustration 17: Possibilities for modeling connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Illustration 18: Intersection area with multiple nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Illustration 19: Node and link types of main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Illustration 20: Main turns open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Illustration 21: Main turns not open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Illustration 22: The stop hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Illustration 23: Possibilities of modeling stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Illustration 24: The line hierarchy used to model the PuT supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Illustration 25: Example for two line routes of a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Illustration 26: Example of two time profiles of a line route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Illustration 27: Lengths in Visum and their coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Illustration 28: Assignment of run times in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Illustration 29: Example of the aggregation of line routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Illustration 30: Examples: Coupling two and three line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Illustration 31: Calculation example for the calculation of indicators in case of couplings . . . . . . . . . . . . 69
Illustration 32: Reachability analyses for secondary schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Illustration 33: Allocating POIs to links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Illustration 34: Visualization of the local position of count locations with the date of the count . . . . . . . . 75
Illustration 35: The Congestion Charge in London is an area toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Illustration 36: Summation and average calculations with screenlines. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Illustration 37: Calculation of the urban traffic volume with screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Illustration 38: Time series by percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Illustration 39: Time series of matrix numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Illustration 40: The relationship between the different analysis time slots . . . . . . . . . . . . . . . . . . . . . . . . 89
Illustration 41: Assignment not possible because the validity of the demand and the assignment time
interval do not overlap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
PTV AG
773
List of illustrations
Illustration 42: The demand between 6:30 and 7:30 a.m. is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Illustration 43: The demand between 6:30 and 7:30 a.m. is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Illustration 44: Structural data of zones stored in user-defined attributes . . . . . . . . . . . . . . . . . . . . . . . 102
Illustration 45: Count data stored in user-defined link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Illustration 46: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Illustration 47: Positive and negative surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Illustration 48: Correlations between different demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Illustration 49: Integrated 4-step demand model in Visum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Illustration 50: Extended 4-step model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Illustration 51: Modeling through decision tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Illustration 52: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden) . . . 136
Illustration 53: EVA1 function in dependence of impedance w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Illustration 54: EVA2 function in dependence of the parameters a and b . . . . . . . . . . . . . . . . . . . . . . . 157
Illustration 55: Application of tolerance value in Go to procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Illustration 56: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min] . . . . 208
Illustration 57: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Illustration 58: VD function type BPR according to the Traffic Assignment Manual. . . . . . . . . . . . . . . . 220
Illustration 59: VD function type INRETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Illustration 60: VD function type LOHSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Illustration 61: Capacity analysis process for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Illustration 62: Method of calculation at two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Illustration 63: Calculation process for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Illustration 64: Calculation process for roundabouts according to HCM 2010 . . . . . . . . . . . . . . . . . . . . 268
Illustration 65: Approaching flows at a four-leg roundabout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Illustration 66: Calculation process for roundabouts according to the TRL/Kimber method . . . . . . . . . 273
Illustration 67: Description of the node geometry for the TRL/Kimber model . . . . . . . . . . . . . . . . . . . . 274
Illustration 68: Example network for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Illustration 69: Green time split at all nodes with succeeding left turns . . . . . . . . . . . . . . . . . . . . . . . . . 283
Illustration 70: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002 . . . 284
Illustration 71: Progression quality for approach West at node 8003. . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Illustration 72: Progression quality for approach North at node 8002 . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Illustration 73: Example network for proportional distribution of the traffic demand. . . . . . . . . . . . . . . . 291
Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2. . . . . . 299
Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1 . . . . . 299
Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2 . . . . . 300
Illustration 77: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1 . . . . . 300
Illustration 78: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2 . . . . . 301
Illustration 79: Blocking back model, phase 2, relief of congestion. Initial situation. . . . . . . . . . . . . . . . 302
Illustration 80: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1. . . . . . . . 302
Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2. . . . . . . . . 303
Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1. . . . . . . . . 303
Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2. . . . . . . . . 304
Illustration 84: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1. . . . . . . . . 304
Illustration 85: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2. . . . . . . . . 305
Illustration 86: Integral indicating the overall wait time over the interpolated measured queue lengths 307
Illustration 87: Parameterization of the Kirchhoff distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Illustration 88: Parameterization of the Logit distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
774
PTV AG
List of illustrations
PTV AG
311
312
313
314
318
323
328
329
335
339
340
344
345
353
355
363
369
370
371
375
379
380
381
381
382
383
384
385
385
386
387
388
389
390
391
392
394
395
396
397
399
400
401
402
404
775
List of illustrations
Illustration 134: Graphical determination of the time series of the inflow capacity in the case of
triangular fundamental diagram, piecewise constant inflow, and constant exit capacity . . .
Illustration 135: Dynamic version of the Bellman relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 136: Variables and models of the fixed point formulations for the network performance
model (left hand side) and for the dynamic assignment with spillback (right hand side) . . .
Illustration 137: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 138: Results of WDDTA without and with spillback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 139: Shape of the fundamental diagram based on the link attributes . . . . . . . . . . . . . . . . .
Illustration 140: Parabolic sub-critical branch in the fundamental diagram . . . . . . . . . . . . . . . . . . . . . .
Illustration 141: Signalized intersection in reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 142: Diagram of the signalized node in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 143: Example of the impedance calculation of a connection . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 144: Example of the network volume along a connection . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 145: Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 146: Different modeling options for main and subordinated networks . . . . . . . . . . . . . . . . .
Illustration 147: Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 148: Line map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 149: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 150: Example for indicator value calculation for partially traversed links . . . . . . . . . . . . . . .
Illustration 151: Network volume after transport system-based assignment (parameters file TSys1.par). .
Illustration 152: Network volume after transport system-based assignment (parameters file TSys2.par). .
Illustration 153: Example network for choice models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 154: Structure of the choice in scenario 1 (no information) . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 155: Structure of the choice in scenario 2 (local information). . . . . . . . . . . . . . . . . . . . . . . .
Illustration 156: Structure of the choice in scenario 3 (information in the vehicle) . . . . . . . . . . . . . . . . .
Illustration 157: Volume for headway-based assignment, transfer penalty 2 min . . . . . . . . . . . . . . . . .
Illustration 158: Coordination of lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 159: Network volume for timetable-based assignment (parameter file timetab1.par) . . . . .
Illustration 160: Flow chart of a timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 161: Smoothing of the vol/cap ratio in iteration i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 162: Readiness to change dependent on the alternative's departure time . . . . . . . . . . . . .
Illustration 163: Standard questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 164: Processing of PuT passenger surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 165: Validity check of the survey path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 166: Validity check of the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 167: Territories in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 168: Line 2 traverses several territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 169: Allocation of vehicles and operators in the line hierarchy. . . . . . . . . . . . . . . . . . . . . . .
Illustration 170: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . .
Illustration 171: Conflict between empty trips and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 172: Line network of the example with three bus lines (red, blue and yellow) . . . . . . . . . . .
Illustration 173: (Graphical) timetable of the example, color codes as above . . . . . . . . . . . . . . . . . . . .
Illustration 174: Covering the timetable through pure line blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 175: Covering the timetable through blocks without empty trips . . . . . . . . . . . . . . . . . . . . .
Illustration 176: Covering the timetable through line comprehensive blocks with empty trips . . . . . . . .
Illustration 177: Unsymmetrical timetable with trips beyond 24 hours . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 178: Blocking days and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 179: Display of a change of the running direction in the course of vehicle journey block
items. The line route makes a U-turn in the station "TFS". . . . . . . . . . . . . . . . . . . . . . . . . .
776
405
407
409
411
412
414
415
416
416
421
421
425
430
433
433
442
450
452
452
467
468
468
469
473
474
491
493
504
505
511
513
515
516
524
526
531
533
535
537
537
539
541
543
545
549
558
PTV AG
List of illustrations
561
564
565
566
567
568
570
571
572
579
583
587
588
606
617
621
622
623
635
638
643
645
645
646
647
648
649
654
655
656
664
669
674
675
677
684
685
685
685
689
692
692
698
698
700
700
702
707
708
PTV AG
777
List of illustrations
Illustration 229: Through traffic traversing the two links in the sequence specified . . . . . . . . . . . . . . . .
Illustration 230: Combining flow bundles for PrT and PuT by using an OR operation . . . . . . . . . . . . . .
Illustration 231: Link flow bundle with AND THEN operation and OR operation . . . . . . . . . . . . . . . . . .
Illustration 232: Link flow bundle with alternative routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 233: Isochrones to display the accessibility of stop areas . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 234: Functional principle of isochrones illustrated in a simple example . . . . . . . . . . . . . . . .
Illustration 235: Accessibility of link sections from node 7357 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 236: Classification of zones according to Isochrones time PrT . . . . . . . . . . . . . . . . . . . . . .
Illustration 237: 2D display of the accessibility of stop areas from the main station . . . . . . . . . . . . . . .
Illustration 238: Classified display of stops on the basis of the isochrone time PuT . . . . . . . . . . . . . . .
Illustration 239: Classified display of stops on the basis of the isochrone number of transfers . . . . . . .
Illustration 240: Comparison of accessibility in PrT and PuT in a graphical view . . . . . . . . . . . . . . . . .
Illustration 241: Comparison of accessibility in PrT and PuT in a list view . . . . . . . . . . . . . . . . . . . . . .
Illustration 242: Shortest path search between two nodes in PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 243: Graphical and tabular display of link volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 244: Example of a link list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 245: PrT path list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 246: Link bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 247: Connector bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 248: Two link bars with PrT and PuT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 249: Categorized link display according to link category . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 250: Categorized link display according to saturation PrT . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 251: Zone categorization according to origin traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 252: Link bar display categorized according to saturation PrT. . . . . . . . . . . . . . . . . . . . . . .
Illustration 253: Table display of boarding passengers, transfers and alighting passengers at stops . .
Illustration 254: Number of residents and workplaces per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 255: Display of the mode selection as pie charts for zones . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 256: Display of turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 257: Desire line with bars scaled at the demand between zones. . . . . . . . . . . . . . . . . . . . .
Illustration 258: Desire line with bars classified according to the demand between zones . . . . . . . . . .
Illustration 259: Stop catchment areas with a large radius of 400m . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 260: Stop catchment areas classified according to the number of departures. . . . . . . . . . .
Illustration 261: Transfer relations between stop areas of a stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 262: Transfers display of regular services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 263: Lane allocation in the network display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 264: Classified lane allocation according to the node volume . . . . . . . . . . . . . . . . . . . . . . .
Illustration 265: Isochrone view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 266: Signal time-space diagram in mode "Flowing off" . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 267: Signal time-space diagram in mode "Arterial bands" . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 268: Column charts for time intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 269: Column chart for relations between network objects . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 270: Tabular timetable in the standard view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 271: Tabular timetable in regular service mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 272: Table background classified by revenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 273: Graphical timetable with classified display of vehicle journey line style properties . . .
Illustration 274: Item bars for vehicle journeys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 275: Classification of item bars with the vehicle journey volume . . . . . . . . . . . . . . . . . . . . .
Illustration 276: Display of item bars for boarding passengers, through passengers and alighting passengers
778
709
711
712
713
714
715
716
717
718
719
720
721
721
722
725
728
731
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
751
753
758
758
759
760
761
762
763
764
765
766
767
PTV AG
List of tables
Table 1: Additional attributes for a compared numerical attribute after version comparison . . . . . . . . . . 11
Table 2: Definition of scenarios based on modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 3: Extension of scenarios for a demand variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 4: Basic network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 5: PuT network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 6: General network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 7: PrT transport systems properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 8: Flow hierarchy symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 9: OD pairs in the example Example.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 10: Example of three vehicle journeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 11: Input data for the calculation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 12: Calculation of indicators for the line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 13: Calculation of indicators for the links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 14: Network objects of the junction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 15: Deriving projection factors for AP and AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Table 16: Example of the interaction of analysis time intervals and time series . . . . . . . . . . . . . . . . . . . 90
Table 17: Examples of input and output attributes at the link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Table 18: Example of a 1..1 relation in the Visum network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 19: Example of a 0..1 relation in the Visum network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 20: Example of a 0..n relation with aggregate function Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 21: Example of a 0..n relation with aggregate function Min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 22: Example of a 0..n relation with aggregate function Max. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 23: Example of a 0..n relation with aggregate function Sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 24: Example of a 0..n relation with aggregate function Avg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 25: Example of a 0..n relation with aggregate function Concatenate . . . . . . . . . . . . . . . . . . . . . . 100
Table 26: Example of a 0..n relation with aggregate function Histogram . . . . . . . . . . . . . . . . . . . . . . . . 101
Table 27: Saving the cost per kilometer to a user-defined attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 28: Time-varying attributes and their allocation to assignment procedures . . . . . . . . . . . . . . . . . 105
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment. . . . . . . . . . . . . . . . 106
Table 30: Table Main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 31: Table Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 32: Table Surface items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 33: Table Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 34: Table Face items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 35: Table Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 36: Table Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 37: Table Intermediate points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 38: Examples of the normalization of surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table 39: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs. 136
Table 40: Examples of relevant structural properties and person groups of the demand strata . . . . . . 137
Table 41: Trip generation in EVA model: OD type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Table 42: Trip generation in EVA model: OD type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 43: Trip generation in EVA model: OD type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Table 44: List of the activity chains: mobility rates per person group in % . . . . . . . . . . . . . . . . . . . . . . . 163
PTV AG
779
List of tables
780
189
189
213
214
215
219
219
220
220
220
221
221
221
222
223
223
223
224
224
225
225
225
226
228
228
230
232
234
251
252
253
254
255
256
259
261
262
263
263
265
265
267
268
272
274
277
288
PTV AG
List of tables
288
289
290
290
313
315
315
315
315
317
319
320
321
321
323
323
324
325
326
330
344
345
346
347
348
349
351
352
358
359
359
366
367
373
374
374
375
377
378
382
383
413
417
418
422
423
427
432
PTV AG
781
List of tables
Table 140: PuT supply of the example with connections from A-Village to X-City . . . . . . . . . . . . . . . .
Table 141: Path legs after a timetable-based assignment (paths saved as connections). . . . . . . . . . .
Table 142: Path legs after a timetable-based assignment (paths saved as routes) . . . . . . . . . . . . . . .
Table 143: Skims of time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 144: Skims of length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 145: Monetary skims [Currency units] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 146: Skims of frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 147: Skims of attribute data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 148: Derived skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 149: Example of the connection skims of an OD pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 150: Availability of the skims in the PuT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . .
Table 151: Combination of skim data to the mean skim value per OD pair . . . . . . . . . . . . . . . . . . . . .
Table 152: Example for the determination of the time difference DT . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 153: Comparison of the impedance functions in the PuT assignments. . . . . . . . . . . . . . . . . . . .
Table 154: Connector weights for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 155: Temporary demand matrix for the assignment in the example . . . . . . . . . . . . . . . . . . . . . .
Table 156: Example for headway calculation from mean headway according to timetable . . . . . . . . .
Table 157: Example for headway calculation from mean wait time according to timetable . . . . . . . . .
Table 158: Considering elapsed wait time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 159: Travel times and headways of the lines in the example network . . . . . . . . . . . . . . . . . . . .
Table 160: Line shares and the mean costs depending on the information available. . . . . . . . . . . . . .
Table 161: Headway calculation for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 162: Impedance calculation for the routes in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 163: Changes to shares with variation of the transfer penalty. . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 164: Mean skim values for the headway-based assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 165: Calculation of the temporal distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 166: Procedure parameters for the comparison of the distribution models . . . . . . . . . . . . . . . . .
Table 167: Example 1 Initial situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 168: Example 2 Isochronous, identical pair of connections . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 169: Example 3 Identical pair of connections with high temporal proximity . . . . . . . . . . . . . . .
Table 170: Example 4 Similar pair of connections with high temporal proximity (connection 3 now
includes transfer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 171: Example 5 - Differing pair of connections with moderate temporal proximity . . . . . . . . . . .
Table 172: Result of connection search (transfer penalty 10 min, parameter file timetab1.par) . . . . . .
Table 173: Temporal distances T and impedances R of the connections for the two analyzed
intervals of travel demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 174: Distribution of trips to the connections (Kirchhoff, = 3). . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 175: Calculation rules for the output attributes of the assignment analysis. . . . . . . . . . . . . . . . .
Table 176: Status indicators for the surveyed path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 177: Status indicators for the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 178: Status indicators for the succeeding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 179: Status indicators for the entire survey data record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 180: Level Territory x Transport system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 181: Indicators for line route analysis by territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 182: Territory-based indicator data for transport performance and revenue analysis . . . . . . . . .
Table 183: Territory-based analysis on aggregation level Territory x Line . . . . . . . . . . . . . . . . . . . . . .
Table 184: Analysis of the Vol/Cap ratio of seats on the line route level. . . . . . . . . . . . . . . . . . . . . . . .
Table 185: Service kilometer analysis on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 186: Cost and revenue computation on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
782
433
435
436
437
439
439
440
440
440
442
443
445
447
448
449
449
455
455
463
469
470
471
472
473
473
484
487
487
488
488
488
488
489
490
490
508
517
517
518
518
523
524
525
526
527
527
528
PTV AG
List of tables
529
529
530
534
538
539
541
543
546
PTV AG
783
546
548
549
552
553
554
555
556
556
559
559
559
576
580
581
582
595
606
607
607
607
607
608
608
608
609
615
618
624
624
624
625
626
626
627
627
List of tables
784
628
628
629
630
631
631
632
633
634
634
635
636
637
638
639
639
639
639
640
641
641
642
643
644
644
652
656
666
673
676
678
679
679
680
680
681
681
682
687
687
693
694
703
705
729
730
730
730
PTV AG
List of tables
PTV AG
785
List of tables
786
PTV AG
Index
Index
A
Activities 5, 122
attributes (EVA) 132
Activity chains 123, 161, 163
Activity pairs 5, 123
attributes (EVA) 132
Adding complex terms 188
Air pollution emissions 654
Akcelik (VD function) 223
Analysis
analysis horizon 89
analysis period 88
analysis time intervals 89, 92
analysis time slots 88
Annual calendar 85
Assessment types 153
Assignment analysis
PrT 426
PuT 506
Assignment procedure
see Assignments
Assignment quality 307
Assignment time interval 88
Assignments
demand segments 37
distribution models 308
PrT procedures
see PrT assignment procedures
PuT procedures
see PuT assignment procedures
Attraction 128, 135, 139, 151
Attributes
direct 94
indirect 95
time-varying 105
user-defined 101
Average Excess Cost AEC (PrT assignment quality) 308
B
Background formats 693
Backgrounds 689
automatic positioning 694
PTV AG
C
Calculate skim matrix (procedure) 290
Calculation results
temporal distinction 92, 93
Calendar 57, 84
Calendar period 88
Capacities
adjusting to demand values 93
Cascetta 370
Charts 8
column charts 742, 759
pie charts 743
Choice models
with independence 487
C-Logit approach 370
Cold start excess emissions
calculation according to HBEFA 660
Column charts 8, 759
Commonality factor 370
Conical (VD function) 220
Conical marginal (VD function) 221
Connection 478
Connection choice
timetable-based assignment 484
787
Index
DeltaT 483
early 483
late 483
Demand
distribution to PuT connectors 448
see Transport demand
Demand matrices 3, 120
updating 195
Demand model 119
Demand model structure 121
Demand models 1, 3
activity chain based
see Demand models, Tour-based model
EVA model for passenger demand 5, 132
Standard 4-step model 5, 126
time series 5
Tour-based model 5, 161
788
PTV AG
Index
EVA
see EVA model for passenger demand
EVA model for passenger demand 5, 119, 132
activities 132
activity pairs 132
assessment types 153
balance factors 158, 161
balancing 143
constraints 139
demand strata 133
elasticity functions 155
evaluation 153
evaluation functions 152, 154
weighting probabilities 153
Furness method
trilinear 158
home trips 151
mobility rates 138
mode choice 152
multi procedure
trilinear 158
structural properties 132
study area factors 138
trip distribution 152
trip generation 135
zones 134
EWS-97 663
F
Face items 111
Faces 111
Fares 447
Flow bundles 7, 697
alternative routes 711
combining flow bundle criteria 706
defining flow bundles 699
displaying paths 711
link flow bundles 701
main node flow bundles 700
node flow bundles 699
selecting network objects 699
selecting types of traffic 701
stop point, stop area, and stop flow bundles 701
zone and main zone flow bundles 701
G
Gap (PrT assignment quality) 308
Geographic information systems (GIS) 671
PTV AG
Georeferencing 686
GIS objects 76, 671
Go to procedure (procedure) 4, 182, 183, 184
GPS tracking 695
Graphic objects 688
Graphical display 725
Graphical timetable 763
Gravity model 129, 174
calculating 174
calibrating 173
Green time optimization 277, 279
H
HBEFA
basis for calculating cold start excess emissions 660
basis for calculating warm emissions 658
emission calculation 657
HBEFA-based emission calculation 657
HCM 229
Headway calculation
from mean headway 454
from mean wait time 455
Headway-based assignment 453
coordination 474
generalized costs 456
headway calculation 454
impedance 456
Highway Capacity Manual (HCM) 229
Histogram 186
Home trips 151, 164
Hypothetic vehicle impedance (PrT assignment
quality) 308
I
ICA 229
Impact models 1, 6, 205
Environmental impact model 207
Operator model 206
User model 205
Impedance functions 207
at node 226
EVA model for passenger demand 153
headway-based assignment 456
PrT assignments 216
timetable-based assignment 481
Impedances
connectors 217
789
Index
examples 224
headway-based assignment 456
links 217
main turns 218
nodes 217
preloaded volume 218
routes 216
turns 217
Incremental assignment 315
evaluation 320
examples 316
input and output attributes 318
procedure 317
Independence of connections 485
Indicators 209
aggregation along line hierarchy 645
calculating aggregation levels 522
calculation for coupled sections 647
calculation for partially traversed links 647
calculation principles 641
examples 523, 526, 529
global indicators 210
projection of additional attributes 648
projection to analysis horizon 641
temporal dependencies (example) 642
territory-based cut 646
territory-based evaluation (aggregation levels) 525
time cut 646
Indirect attributes
aggregation functions 96
Average and AverageActive 99
Concatenate and ConcatenateActive 99
Count and CountActive 96
Frequency and FrequencyActive 100
Max and MaxActive 98
Min and MinActive 97
relations 95
Sum and SumActive 98
INRETS (VD function) 222
Interactive analyses 697
flow bundles 697
isochrones 713
shortest path search 722
Intermediate points 111
Intersection Capacity Analysis (ICA) 229
all-way stop 260
roundabouts 267
signalized nodes 230
790
J
Journey sections 62
Journeys 61
Junction
traffic-related modeling 78
Junction model 78
signal control 82
Junction modeling 78
K
Kirchhoff model 309
L
Lanes 81
lane allocation 750
lane turns 81
Leg templates 82
Legend 688
Legs 80
Level of Service 259
Line block check 560
common 562
forced 562
Line blocking 532, 533
block item and block item type 552
block version 547
blocks 549
cost function 554
coverage check 563
data model 536
depots 555
distributing empty trips and empty times 579
evaluation of the procedure 535
examples 536
layover times 555
line block check 560
lists 730
optimization problem 534
procedure description 564
PuT interlining matrix 579
with vehicle interchange
PTV AG
Index
PTV AG
M
Main lines 58
Main nodes 48
Main relations 51
Main turns 50
impedances 218
Main zone matrices
disaggregating 191
Main zones 51
Major flows 41
Matched transfers 475
Matrices 3, 120
adding columns or rows 191
adding complex term 188
aggregating 192
calibrating (PrT) 203
classifying matrix values 186
combining matrices and vectors 188
correcting 195
demand matrices 120
diagonal
extracting 187
setting 187
editing 184
functions 184
exponential function 187
extending 191
see Matrices, splitting
forming maximum or minimum 187
791
Index
N
NCHRP 255 425
Nested Mode Choice
see Mode choice, nested
792
Network check 84
Network display
bars 733
classified 736
labeling with charts 741
labeling with tables 740
Network merge 14
analysis time intervals 17
examples 14
Network model 1, 2
Network objects
block 549
block item 552
block item type 552
block item types 33
block version 547
block versions 33
buffer 681
connectors 30, 46
count locations 33, 74
demand segments 29, 34, 36, 120
detectors 34, 74
fare zones 33
GIS objects 34, 76, 671
intersecting 677, 681
line blocking 536
line routes 32, 58
lines 32, 58
link types 30
links 30, 40
main lines 32, 58
main nodes 30, 48
main OD pairs 51
main turns 30, 50
main zones 30, 51
modes 29, 34, 36
nodes 29, 38
OD pairs 31
Operator model (PuT) 530
paths 31, 52
Points of Interest (POI) 33, 72
PuT coordination groups 33
PuT operators 32, 56
PuT vehicles 57
screenlines 34, 77
stop areas 31, 55
stop points 31, 54
stops 31, 56
PTV AG
Index
O
OD matrices
see Demand matrices
OD pairs 46
Operator model 530
Operator model (PuT) 206, 521
PTV AG
P
Passenger survey 509
direct assignment 519
survey data
assignment 519
plausibilization 513
reading 513
Path legs
PrT 215
PuT 434
Paths 52, 209
displaying (flow bundles) 711
filtering (flow bundles) 697
PrT 215
PuT 434
Perceived journey time 446, 481
Person groups 5, 122
Personal Geodatabase (PGD) 671
Point 111
Points of Interest (POI) 72
Pollution-Emis procedure 654
Polygons 111, 694
Procedure description
line blocking without vehicle interchange 563
Production 128, 135, 139, 151
Projecting path volumes (PrT) 202
Projection 88
examples 90
Projections 686
PrT
path legs 215
path objects 52
paths 215
PrT assignment procedures 211
convergence criteria 307
dynamic stochastic assignment 419
793
Index
794
Q
Queues 221
R
Ramp metering 221
RAS-W-86 663
Result analysis 7
Revenues (PuT) 622
fares 447
RLS-90 651
Route loading
TSys-based assignment 453
Route search
TSys-based assignment 452
Routes
distribution of demand 308
impedances 216
skims 437
S
Scenario management 18
Scenarios 18
calculating 23
creating based on modifications 23
defining modifications 22
distributed calculation 24
Schematic 754
Schematic line diagrams 754
displaying demand and transfer flows 756
displaying supply 754
editing 754
transferring the layout 756
Screenlines 77
Shape files 672
Shortest path search 7, 480, 722
PrT 7, 722
PuT 7, 723
Signal control 82
stage templates 84
Signal controls
optimizing cycle and green time 278, 281
optimizing offset times 281
Signal coordination 278, 281
Signal time optimization 277
Signal time-space diagram 757
Skim matrices 7, 120
Skims 209
calculating (PrT) 290
PTV AG
Index
T
Tables 8
Tabular display 725
Tabular timetable 760
tCur 218
Temporal utility 447
Territories 52, 93
Texts 688
TFlowFuzzy 195
Time profiles 60
coupling 67
specifying run times 63
Time series 86, 121
PTV AG
examples 90
matrix numbers 5, 87, 121
percentage 5, 87, 121
Time-of-Day Choice
Standard 4-step model 131
Timetable editor 8, 760
evaluations 760
graphical timetable 763
tabular timetable 760
Timetable-based assignment 477
connection choice 484, 489
connection preselection 481
connection search 478
Branch and Bound 478
shortest path search 480
distribution of trips over connections 484
evaluation 477
fare 484
impedance 481
independence of connections 485
opening 492
perceived journey time 481
PuT-Aux TSys 491
temporal utility 447
temporal utility of a connection 483
Timetables 65
Time-varying attributes 105
TModel 228
Toll in the assignment 376
Toll systems 75
Total Excess Cost TEC (PrT assignment quality) 308
Tour-based model 5, 119, 161
activity chain based model 161
constraints 162
destination choice 164
home trips 164
mode choice
combined 168
structural properties 161
trip distribution
combined 164
trip generation 163
utility function 165, 168
Transfer relations 748
Transfer wait time (Timetable-based assignment) 482
Transport demand 1, 3, 4, 119
distributing to PrT connectors 291
distributing to routes 308
795
Index
model 1, 3, 125
time reference 86
time series 86
Transport demand matrices
see Demand matrices
Transport demand model 1, 3
Transport system-based assignment 450
Transport systems 34, 35
TRIBUT procedure 376
Trip distribution 4
EVA model for passenger demand 152
Standard 4-step model 129
Tour-based model 164
Trip generation 4
EVA model for passenger demand 135
Standard 4-step model 128
Tour-based model 163
TSys-based assignment
evaluation 451, 452
route loading 453
Turn volumes display 7
Turns 38
impedances 217
PrT capacity 40
PrT turn time 40
turn standards 39
turn types 39
Turns VD function 228
U
User models 6
User optimum 221, 321
User-defined attributes 101
V
Valid days 57, 85
Value of time (VT) 378
VD functions 218
Akcelik 223
BPR (according to Traffic Assignment Manual) 220
conical 220
conical marginal 221
INRETS 222
linear bottle-neck 224
logistic 222
Lohse 224
quadratic 222
796
SIGMOIDAL_MMF_LINKS 222
SIGMOIDAL_MMF_NODES 222
user-defined 225
Vehicle combination set 573
Vehicle combinations 57
in the operator model 530
Vehicle journey sections 62
Vehicle journeys 61
Vehicle units 57
in the operator model 530
Version comparison 9
Versions
comparing 8
W
Weekly calendar 85
Weighting (EVA) 153, 160
evaluation functions 152, 154
Box-Cox 155
Box-Tukey 155
combined 155
EVA1 154
EVA2 154, 157
Kirchhoff 155
Logit 155
Schiller 155, 157
TModel 155
weighting matrices 160
weighting probabilities 153
Weighting matrices 120
World files 694
Z
Zone matrices
aggregating 191
Zones 45
attributes (EVA) 134
PTV AG
Index
PTV AG
797
PTV GROUP
Haid-und-Neu-Str. 15
76131 Karlsruhe
Germany
Telefon +49 (0) 721 96 51 300
Fax +49 (0) 721 96 51 562
E-Mail info@vision.ptvgroup.com
www.ptvgroup.com
www.vision-traffic.ptvgroup.com