Transyt 16 User Guide

by James C Binning
© Copyright TRL Limited 2019. All rights reserved.
Software manufactured
under an ISO 9001
registered quality
management system
DD: +44 (0)1344 379777 | E: software@trl.co.uk | http://www.trlsoftware.com

TRL Software | Crowthorne House | Nine Mile Ride | Wokingham | Berkshire | RG40 3GA | UK
The information contained herein is the property of TRL. Whilst every effort has been made
to ensure that the matter presented in this document is relevant, accurate and up-to-date at
the time of publication, TRL cannot accept any liability for any error or omission.
The copyright in this material is held by TRL Limited and cannot be used for commercial gain
or reproduced unless authorised/licensed by TRL Limited.
First Published 2019
TRANSYT 16 User Guide (Issue A)

TRANSYT is a macroscopic off-line computer program for studying everything from
isolated road junctions to large signal-coordinated networks. Traditionally TRANSYT’s
primary role has been the study and determination of optimum fixed time, co-
ordinated, traffic signal timings in any network of roads for which the average traffic
flows are known. However, TRANSYT 16 is also designed specifically to be used for the
assessment of isolated signal controlled junctions, signalised roundabouts, partially
signalised roundabouts and for any network of non-signalled and signal controlled
junctions which influence the behaviour of each other’s traffic.
A traffic model of the network calculates a Performance Index (P.I.) in monetary terms,
which, in its simplest form, is a weighted sum of all vehicle delay and stops. A number
of available optimising routines systematically alter signal offsets and/or allocation of
green times to search for the timings which reduce the P.I. to a minimum value.
TRANSYT is the most widely used program of its type throughout the world.
This Application Guide provides a comprehensive user’s guide to the latest version of
TRANSYT software (TRANSYT 16) issued by TRL. It has been updated to include details
of the changes made since TRANSYT 14; in particular the addition of a pedestrian
crossing model which is capable of modelling the ‘walk-on-red’ behaviour of
pedestrians, enhanced modelling of time-varying traffic conditions, and other extensive
enhancements to both the traffic model and the fully-interactive graphical interface.

Page 4

May 2019, Issue A (to accompany TRANSYT 16.0.0)
For program advice, sales and distribution information please contact:
TRL Software Sales

TRL | Crowthorne House | Nine Mile Ride | Wokingham | Berkshire | RG40 3GA | United Kingdom
Telephone lines: +44 (0)1344 379777

Fax: +44 (0)1344 770356
E-mail: software@trl.co.uk
Website: www.trlsoftware.com
Consultancy: software@trl.co.uk
Useful product-related links:
Knowledge base: www.trlsoftware.com/support/knowledgebase
Latest downloads: Contact TRL Software Sales
Training courses: www.trlsoftware.com/support/training
Version history: version history
Videos: www.youtube.com/TRLSoftwareChannel

Page 6
CHAPTER HEADINGS
1 Introduction ........................................................................................................... 18
2 Installing the Software .......................................................................................... 27
3 Quick Start Guide................................................................................................... 31
4 Vehicle Modelling Basics ....................................................................................... 55
5 Optimisation Basics ............................................................................................... 77
6 Simulation Model .................................................................................................. 79
7 User Interface operation ....................................................................................... 81
8 Data Entry............................................................................................................ 111
9 Special data-entry screens .................................................................................. 121
10 Data Grids ...................................................................................................... 143
11 Network Diagram ........................................................................................... 153
12 Three dimensional mode (3D) ........................................................................ 201
13 Working with Analysis Sets, Demand Sets and Time Segments .................... 211
14 Working with Traffic Flows ............................................................................ 237
15 Working with Pedestrians .............................................................................. 275
16 Working with Traffic Signals .......................................................................... 295
17 Working with Flared Approaches................................................................... 343
18 Working with Priority Junctions ..................................................................... 355
19 Working with Traffic Models ......................................................................... 401
20 Working with Results ..................................................................................... 407
21 Generating Reports ........................................................................................ 427
22 TRANSYT Outputs ........................................................................................... 441
23 Simulation Mode ............................................................................................ 465
24 Analyser (X-Y Graph) ...................................................................................... 487

25 Additional Tools and Features ....................................................................... 495
26 Traffic Behaviour Models (Non-simulation) ................................................. 503
27 Traffic Model Features in Detail..................................................................... 521
28 Optimisation in detail..................................................................................... 553
29 Modelling Examples ....................................................................................... 583
30 Modelling Signalised Roundabouts ................................................................ 595
31 Definitions / Glossary ..................................................................................... 629
32 References ...................................................................................................... 651
33 Ownership and Copyright .............................................................................. 654
34 Appendix A – Importing files .......................................................................... 656
35 Appendix D – Import SCOOT data .................................................................. 664
36 Appendix E – Import SCATS data ................................................................... 667
37 Appendix G – Calculating TxC ........................................................................ 672

Page 8
CONTENTS
Contacting Us ............................................................................................................. 5
1 Introduction ........................................................................................................... 18
1.1 About TRANSYT ............................................................................................ 18
1.2 Summary of TRANSYT 16 improvements ..................................................... 20
1.3 About this manual........................................................................................ 21
1.4 Training ........................................................................................................ 22
1.5 Student Edition............................................................................................. 23
1.6 Languages .................................................................................................... 23
1.7 Related Software ......................................................................................... 23
1.8 Product Background and Versions ............................................................... 24
1.9 Help Improve TRANSYT ................................................................................ 25
1.10 Acknowledgements ...................................................................................... 25
2 Installing the Software .......................................................................................... 27
2.1 Installing/uninstalling the software............................................................. 27
2.2 Copy-protection and software registration ................................................. 27
3 Quick Start Guide................................................................................................... 31
3.1 Essential GUI terms you need to know ........................................................ 31
3.2 Quick start for new TRANSYT users ............................................................. 31
4 Vehicle Modelling Basics ....................................................................................... 55
4.1 Standard Traffic Model – Basic Assumptions .............................................. 55
4.2 Network representation ............................................................................... 56
4.3 Relationship between real lanes and traffic streams .................................. 56
4.4 Relationship between real lanes and TRANSYT links ................................... 58
4.5 Flow, speed and link/stream/lane data ....................................................... 60

4.6 Signal settings .............................................................................................. 66
4.7 Traffic behaviour and traffic model choice .................................................. 71
4.8 Delays, Queues and Stops ............................................................................ 72
4.9 Maximum queues ........................................................................................ 72
4.10 Give-way situations...................................................................................... 74
4.11 Shared stop lines on Links ............................................................................ 75
4.12 Flared Approaches ....................................................................................... 75
5 Optimisation Basics ............................................................................................... 77
5.1 Network timings optimisation ..................................................................... 77
5.2 Cycle Time optimisation ............................................................................... 78
6 Simulation Model .................................................................................................. 79
7 User Interface operation ....................................................................................... 81
7.1 General ......................................................................................................... 81
7.2 Getting help ................................................................................................. 81
7.3 Accessibility .................................................................................................. 82
7.4 Demo mode .................................................................................................. 82
7.5 Keeping it simple .......................................................................................... 83
7.6 Speed of interface when using very large files ............................................ 84
7.7 Main toolbars ............................................................................................... 85
7.8 Running Files and using Auto-Run ............................................................... 88
7.9 Undo/Redo ................................................................................................... 89
7.10 Changing the Active Data Item .................................................................... 90
7.11 Padlock system............................................................................................. 91
7.12 The 'Bulk Edit' System .................................................................................. 92
7.13 Types of Data ............................................................................................... 93

Page 10
7.14 Managing files ............................................................................................. 98
7.15 Copying and pasting data to and from the clipboard ................................ 101
7.16 Printing....................................................................................................... 101
7.17 Managing Windows ................................................................................... 102
7.18 User Preferences ........................................................................................ 104
8 Data Entry............................................................................................................ 111
8.1 Data Files ................................................................................................... 111
8.2 Library Files ................................................................................................ 111
8.3 Data Outline ............................................................................................... 112
8.4 Data Outline Screen ................................................................................... 115
8.5 Data Editor Screen ..................................................................................... 116
8.6 Network Diagram ...................................................................................... 117
8.7 Task List (Errors and Warnings) ................................................................. 117
8.8 Data Field Finder ........................................................................................ 118
9 Special data-entry screens .................................................................................. 121
9.1 Main (Common) Data Screen..................................................................... 121
9.2 Controller Streams Screen (Signal Data).................................................... 123
9.3 Links Data Screen ....................................................................................... 131
9.4 Traffic Streams Data Screen ...................................................................... 135
9.5 Pedestrian Crossing Data Screen ............................................................... 139
10 Data Grids ...................................................................................................... 143
11 Network Diagram ........................................................................................... 153
11.1 Speed of operation ..................................................................................... 154
11.2 Viewing and moving around the network ................................................. 154
11.3 Saving, using and managing “Views” ........................................................ 155

11.4 Printing, copying and exporting ................................................................. 156
11.5 Representation of Arms, Traffic Streams and Lanes ................................. 156
11.6 Representation of links .............................................................................. 161
11.7 Shaping traffic streams, links and connectors ........................................... 162
11.8 Representation of controller streams and signal timings .......................... 162
11.9 Manipulating items .................................................................................... 163
11.10 Viewing and visualising data in the network diagram .............................. 169
11.11 Network Diagram Options screen.............................................................. 195
12 Three dimensional mode (3D) ........................................................................ 201
12.1 Navigation within a 3D network ................................................................ 202
12.2 3D Results .................................................................................................. 202
12.3 Referencing/Adding 3D Models ................................................................. 206
12.4 Recording and Playing a “Fly Through” ..................................................... 208
13 Working with Analysis Sets, Demand Sets and Time Segments .................... 211
13.1 Analysis Sets ............................................................................................... 212
13.2 Demand Sets .............................................................................................. 214
13.3 Analysis/Demand Sets and Summary Results ............................................ 216
13.4 Entering flows without the use of OD Matrices ......................................... 222
13.5 Global and independent values for data sets ............................................ 222
13.6 Locking Analysis and Demand Sets ............................................................ 225
13.7 Colour coding Analysis and Demand Sets .................................................. 226
13.8 Time Segments ........................................................................................... 226
13.9 Copying and pasting all Demand Sets ....................................................... 229
13.10 Reading Demand Set flow data from Excel ............................................... 231
14 Working with Traffic Flows ............................................................................ 237

Page 12
14.2 Specifying link flows via Links Data Screen ................................................ 240
14.3 Flow Consistency ........................................................................................ 240
14.4 Flow Allocation and Assignment (Using Matrices) .................................... 243
15 Working with Pedestrians .............................................................................. 275
15.1 The Pedestrian Behaviour Model ............................................................... 275
15.2 Pedestrian Network Structure ................................................................... 276
15.3 Pedestrian Flows ........................................................................................ 281
15.4 Overview of Data requirements ................................................................. 283
15.5 Optimisation .............................................................................................. 289
15.6 Pedestrian results and network animations .............................................. 291
16 Working with Traffic Signals .......................................................................... 295
16.1 Introduction to traffic signals in TRANSYT ................................................. 295
16.2 Overview of Signal Timings ........................................................................ 303
16.3 Timings Diagram ........................................................................................ 314
16.4 Timing Wheels ........................................................................................... 324
16.5 Intergreen Matrix Screen ........................................................................... 327
16.6 Phase Delays .............................................................................................. 334
16.7 Stage Sequence Screen .............................................................................. 335
16.8 Start/end displacements ............................................................................ 338
16.9 Minimum cycle times ................................................................................. 339
16.10 Different cycle times within a network ...................................................... 340
17 Working with Flared Approaches................................................................... 343
17.2 Flared approaches - ‘quick’ flares .............................................................. 349
18 Working with Priority Junctions ..................................................................... 355
18.1 What is a Priority Object? .......................................................................... 356

18.2 Using a Priority Object library file .............................................................. 358
18.3 Applying a Priority Object to an existing network ..................................... 360
18.4 Using a traffic stream network structure .................................................. 364
18.5 Steps required when using traffic streams ................................................ 364
18.6 Movements and Conflicts .......................................................................... 367
18.7 Visibility Adjustment .................................................................................. 371
18.8 Using Links to define your priority junction ............................................... 371
18.9 Modelling crossroads ................................................................................. 374
18.10 Modelling roundabouts ............................................................................. 375
18.11 Using Links to define your roundabout ...................................................... 380
18.12 Mutual opposition...................................................................................... 381
18.13 Modelling variations of give-way .............................................................. 381
18.14 Give-ways within signalled junctions ......................................................... 386
18.15 Give-way simplifications you can make ..................................................... 398
18.16 Indirect traffic control and give-ways with a saturation flow ................... 398
19 Working with Traffic Models ......................................................................... 401
19.1 Traffic Model selection .............................................................................. 401
19.2 Vehicle-In-Service and the Random Parameter ......................................... 402
19.3 Setting Cell Saturation flows ...................................................................... 405
20 Working with Results ..................................................................................... 407
20.1 Summary Results Screen ............................................................................ 408
20.2 Detailed results .......................................................................................... 409
20.3 Animation controls..................................................................................... 410
20.4 Graphs (Flow and Spatial).......................................................................... 410
20.5 Time Distance Diagram.............................................................................. 418

Page 14
21 Generating Reports ........................................................................................ 427
21.1 Report Configurator ................................................................................... 427
21.2 About Report Files ...................................................................................... 432
21.3 Report Viewer ............................................................................................ 433
21.4 Comparing Files and Data Sets .................................................................. 435
22 TRANSYT Outputs ........................................................................................... 441
22.1 Traffic model predictions ........................................................................... 441
22.2 TRANSYT individual traffic stream, link and pedestrian crossing results .. 446
22.3 TRANSYT individual controller stream results............................................ 460
22.4 TRANSYT network-wide results .................................................................. 460
23 Simulation Mode ............................................................................................ 465
23.1 Introduction ............................................................................................... 465
23.2 How Simulation works ............................................................................... 467
23.3 Using Simulation Mode .............................................................................. 468
23.4 Simulation outputs and results .................................................................. 471
23.5 Simulation numerical results ..................................................................... 471
23.6 Diagram visualisations ............................................................................... 472
23.7 Modelling controllers running on different cycle times ............................. 478
23.8 Modelling demand dependency (Intermittent stages) .............................. 479
23.9 Multi-lane per traffic stream versus one lane per stream ......................... 480
23.10 Modelling blocking back ............................................................................ 480
23.11 Modelling oversaturated conditions .......................................................... 480
23.12 Signals Log ................................................................................................. 481
23.13 Simulation options ..................................................................................... 483
24 Analyser (X-Y Graph) ...................................................................................... 487

25 Additional Tools and Features ....................................................................... 495
25.1 Automatic Network Item Naming.............................................................. 495
25.2 Audit Trail................................................................................................... 496
25.3 Adding a Junction (Merging Networks) ..................................................... 498
25.4 Drive-on-the-left/Drive-on-the-right.......................................................... 500
25.5 Run Multiple Files....................................................................................... 501
25.6 Find Shortest/Best Route ........................................................................... 502
26 Traffic Behaviour Models (Non-simulation) ................................................. 503
26.1 Platoon dispersion model (PDM) ............................................................... 503
26.2 Cell Transmission Model ............................................................................ 510
26.3 Congested Platoon Dispersion Model ........................................................ 514
26.4 PDM versus CTM ........................................................................................ 514
26.5 Differences between the “Flare” models (CPDM and CTM) ...................... 515
26.6 Restrictions on use of the CTM .................................................................. 515
26.7 Link-by-Link PDM ....................................................................................... 516
26.8 Triangular platoon dispersion model ......................................................... 517
27 Traffic Model Features in Detail..................................................................... 521
27.1 Signal settings ............................................................................................ 521
27.2 Queues and Delays..................................................................................... 521
27.3 Stops calculation ........................................................................................ 524
27.4 Wasted green time .................................................................................... 526
27.5 Fundamentals of the Give-way Models ..................................................... 527
27.6 Shared link stop lines ................................................................................. 532
27.7 Modelling Buses, Trams and other traffic types ........................................ 534
27.8 Collections and Routes ............................................................................... 542

Page 16
27.9 Fuel consumption estimates ...................................................................... 546
27.10 (Flow) Assignment Model .......................................................................... 551
28 Optimisation in detail..................................................................................... 553
28.1 The performance index .............................................................................. 553
28.2 Network Optimisation selection ................................................................ 559
28.3 Controller-specific Optimisation Levels...................................................... 560
28.4 Locking of stages between different controllers........................................ 561
28.5 Optimisation Type (and other Advanced Settings) .................................... 565
28.6 Queue-length reductions .......................................................................... 572
28.7 Degree of Saturation limits ........................................................................ 574
28.8 Pedestrian gap-accepting penalty ............................................................. 574
28.9 Controller Stream Grouping ....................................................................... 574
28.10 Cycle time selection.................................................................................... 576
28.11 Cycle Time Optimiser ................................................................................. 577
28.12 Multiple cycling and repeated greens........................................................ 579
28.13 Considering the effect of small changes .................................................... 581
29 Modelling Examples ....................................................................................... 583
29.1 Supplied Data Files ..................................................................................... 583
29.2 A small network (Example 1) ..................................................................... 584
30 Modelling Signalised Roundabouts ................................................................ 595
30.1 About this chapter ..................................................................................... 595
30.2 Introduction ............................................................................................... 595
30.3 Using TRANSYT to model roundabouts ...................................................... 596
30.4 Using TRANSYT to design roundabouts ..................................................... 596
30.5 Modelling a roundabout (Example 2) ........................................................ 597

30.6 Checking co-ordination .............................................................................. 611
30.7 Example 3 – a signalised motorway roundabout ...................................... 612
30.8 Example 4 – an urban signalised roundabout ........................................... 623
30.9 Recommendations ..................................................................................... 627
31 Definitions / Glossary ..................................................................................... 629
31.1 TRANSYT GUI Terms ................................................................................... 629
31.2 Modelling and Traffic Engineering Terms .................................................. 630
32 References ...................................................................................................... 651
33 Ownership and Copyright .............................................................................. 654
34 Appendix A – Importing files .......................................................................... 656
34.1 Import TRANSYT 15 files ............................................................................ 656
34.4 Import from TRANSYT 7-SET/10/11/12 ..................................................... 657
34.5 Import from TRANSYT-7F ........................................................................... 658
34.6 Import from Synchro .................................................................................. 662
34.7 Import LinSig report data ........................................................................... 662
35 Appendix D – Import SCOOT data .................................................................. 664
36 Appendix E – Import SCATS data ................................................................... 667
36.1 Importing from SCATS ‘Dump’ file ............................................................. 669
36.2 Creating data files from SCATS data .......................................................... 670
37 Appendix G – Calculating TxC ........................................................................ 672

Page 18
The timings of signals at road junctions have an important effect on the levels of traffic congestion not
only at the junction itself but at surrounding junctions which may or may not have signals themselves.
Often the junctions in urban areas form part of a network of co-ordinated signalised junctions. By co-
ordinating groups of signals within a network, substantial reductions can be made to queues and
delays. Each group of signals are operated on a common cycle time. Their relative green times are set
so that known average volumes of traffic can travel through the urban area with as little delay and as
few stops as possible.
Please note that the term ‘traffic’ mentioned above should be regarded as including non-vehicular
movements through the network such as those of pedestrians, who can also benefit from good co-
ordination and also from thoughtful provision of pedestrian facilities in general.
TRANSYT’s is a software suite containing a macroscopic traffic model, signal optimiser and also a
simulation model, for the purpose of evaluation design and optimisation of everything from isolated
road junctions to large signal-coordinated networks. Traditionally TRANSYT’s primary role has been the
study and determination of optimum fixed time, co-ordinated, traffic signal timings in any network of
roads for which the average traffic flows are known, for which it is recognised internationally.
However, TRANSYT is also designed specifically to be used for the assessment of single isolated signal
controlled junctions, signalised roundabouts, partially signalised roundabouts and for any network of
non-signalled and signal controlled junctions which influence the behaviour of each other’s traffic.
The main TRANSYT method has, as shown in Figure 1-1, two main elements; the traffic model and the
signal optimiser.
The model represents traffic behaviour in a network of streets in which one or more junctions are
controlled by traffic light signals. The model predicts the value of a ‘Performance Index’ for the
network, for any fixed-time plan and set of average flows that is of interest. The Performance Index is
a measure of the overall cost of traffic congestion and is usually a weighted combination of the total
amount of delay and the number of stops experienced by traffic.
The optimisation process adjusts the signal timings and checks, using the model, whether the
adjustments reduce the Performance Index or not. By adopting only those adjustments which reduce
the Performance Index, subject to a number of constraints, such as minimum green, signal timings
are successively improved. The model also provides for give-way priority control possibilities,
including the modelling of opposed offside-turn traffic within signalled junctions and fully
unsignalised junctions which are influenced by nearby signals.
Signalised and partially-signalised roundabouts can be modelled and their delay minimised by
calculating timings which reduce blocking-back by keeping the circulating carriageway free flowing.
The delays to pedestrian ‘traffic’ at signals are also modelled, including their gap-accepting behaviour
when the signals presented to them are red.

Introduction Page 19
TRANSYT, at the time of writing, can model up to 200 nodes and 1000 links within a network.
TRANSYT is suitable for both drive-on-the-left and drive-on-the-right operation.
Figure 1-1 The basic structure of the ‘TRANSYT’ program
Many of the principles behind TRANSYT 16 are essentially the same as those at the heart of previous
versions of the program. However, TRANSYT 16 brings with it a number of significant modelling
changes as well. All of these changes are described in detail in other chapters.
Although existing users will identify many modelling changes, concessions have been made to those
familiar with previous versions of TRANSYT, where we thought it is useful to do so.

Page 20
This section allows you to quickly familiarise themselves with what new facilities have been added to
TRANSYT by summarising the changes and improvements. Full descriptions of the changes are to be
found in other chapters.
Simulation Traffic Signals and other model features
u Modelling of demand-dependent scenarios, i.e. u “Run all stage sequences” facility

irregular stages modelled by defining probability
of them running u Minimum & ’too low’ phase indication
u Explicitly modelling of blocking back issues u Controller: Minimum possible cycle time
display and selection
u Explicit modelling of complex flares (short bays)
u Network: Absolute possible cycle time display
u Modelling uneven lane usage and selection
u Modelling of entire modelled period, allowing the

network performance to be examined in detail at Links and Data:
any point in time
u Store different priority object data in each
u Significant changes in network performance can analysis set.
be associated with a particular point in time
u Dynamically link to Excel spreadsheet data
u Information-rich graphical animations showing
traffic behaviour within the network u Smaller file sizes
u Animations showing estimated positioning of u Import of data from LinSig 3 RTF files
individual vehicles
u Explicit modelling of controller streams running Optimisation:

on different cycle times, including across zones
(OD matrix boundaries). u Optimisation level network overlay
u Signal log for full modelled time period u Phase optimisation: Maximum number of stage
sequences catered for, is raised
Traffic Behaviour Modelling: u Fast Link-by-link traffic model available
u “Force to PDM and Flare” Model option

Graphical User Interface / Tools:
u Fast Link-by-Link traffic model available
u Retrospective Automatic network item naming
u Option to exclude pedestrians from traffic model
for faster run u One-click application of phase losing delays
u (Batch) Run multiple files
u A wide variety of small enhancements
Traffic Flows: Network Representation/Diagram:

u Associate and run multiple Demand Sets per u Arm/Link splitting facility

Analysis Set
u Background: Scale-with drawing
u Optimisation of specific demand sets (with other
set’s results based on these optimised timings) u Definition of connectors is improved when
‘Move Lanes’ tool is used.
u Option to automatically re-allocate low flows to
alternative busier paths u “Show all connectors as straight” option
u Negative entry flows allowed in local OD matrices u New overlays (Level of service / Optimisation
Level)
u Local user equilibrium assignment of flows
Technical
Results, Graphs and Reporting:
u Customer experience program )to improve
u Enhanced Summary Results product development)
u Copy/paste all flow data facility
u “Journey Distances” between OD pairs reported Documentation:
u Location-to-location “Route journey times” u Collections extended to include signal

involving multiple local OD matrices controller streams and pedestrian crossings
allowing easier reporting of individual
u Save and retrieve Analyser graphs junctions.
u Option to base Analyser graphs on evaluation or u Fully revised User Guide

optimised runs of the model
u Cycle Time Optimiser: Extended choice of outputs

– P.I. Delay or PRC
*needs ARCADY 7 or later and/or PICADY 5 or later
For those wishing to evaluate the differences between TRANSYT 16 and earlier versions, we
recommend you contact TRL who will be more than happy to explain whatever features you are
most interested in.
Please browse through this User Guide for information about the
many new features in TRANSYT 16, looking for the following:
This user guide is intended for anyone who is likely to be involved with the use of TRANSYT 16. The
aim is to provide content that allows new users to quickly understand the essential aspects of the
program, while also offering comprehensive reference information to everyone wishing to use or
understand TRANSYT.
To achieve these aims, this user guide describes, in separate chapters, how to get started quickly
with TRANSYT 16, all graphical interface features, the theory and research incorporated in TRANSYT
and how a TRANSYT model should be specified (including guidance on how to measure data). Also

Page 22
described is the output and how it should be interpreted. A number of examples have been
included to aid in the understanding of individual junctions and the modelling problems they pose.
Whilst it is desirable to read as much of each chapter as possible, it is accepted that sufficient time
will not always be available. Hence the earlier chapters concentrate on all the essentials needed to
get started with TRANSYT, with reference within these earlier chapters to other sections of the guide
where more detailed information is provided.
The following labels are used throughout to highlight relevant points about the topics being
covered.
is used to emphasise important points;
is used to warn of the consequences of doing something wrong. Please

pay particular attention to these, as they will help you avoid some of the more calamitous/time-
consuming mistakes that you could make.
is used to highlight the many new features in TRANSYT 16
In many places it is inevitable that “jargon” will have been used, which include general traffic
engineering terms, specific TRANSYT terms and terms relating to features of the graphical interface.
To help avoid repeated explanation of such words and phrases a glossary of terms is included (see
Chapter 31).
The graphics within this document assume drive-on-the-left situations. However, the terms
“nearside” and “offside” have been used throughout, instead of “left” or “right” to allow
understanding for both drive-on-the-left and drive-on-the-right situations.
TRANSYT, by its very nature, is a complex software product. Although we try to make our product as
easy to use as possible, and provide this comprehensive user guide, we acknowledge the demand
that will exist for training courses and the benefits that training can provide to both those totally
new to TRANSYT and to existing users.
TRL run training courses for many of the software products it sells, including hands-on courses on
TRANSYT. We use the most recent releases of our products and we use only experienced trainers –
usually TRL members of staff who have many years of experience. As the developers of TRANSYT we
can offer unrivalled training in its use.
Details of available courses are advertised on our website: https://trlsoftware.com/training

A student version of TRANSYT is available in addition to the full version. It has the same
functionality as the full version, apart from one specific limitation – Data files saved from within the
student version cannot be loaded into the full version.
Several screens are watermarked to identify it as a student edition. The reports are also
watermarked and its header also indicates the report has been produced with a student edition.
Details on availability and pricing can be obtained from TRL Software Sales or your local distributor.
The standard version of TRANSYT is produced in English. However other language versions have
been developed or are in the process of being developed. If you wish to find out what language
versions may be available, or you are interested in assisting/collaborating with our translation
program, please contact TRL Software.
TRANSYT is only one of a number of thoroughly researched and developed traffic-related software
products that TRL produce and market commercially. TRL software products are validated against a
wealth of real life data and used world-wide. Those products which are related to TRANSYT or most
relevant to those using TRANSYT are listed below:
TRL Software’s SCOOT-based UTC System Is a cloud-based urban traffic control system developed
by TRL Software. Its origins can be traced back to the earliest versions of TRANSYT.
JUNCTIONS which includes…
PICADY module is for predicting capacities, queue lengths and delays (both queueing and
geometric) at unsignalised major/minor priority junctions. It is an aid in designing new
junctions as well as assessing the effects of modifying existing designs. PICADY includes
accident prediction.
ARCADY module is for predicting capacities, queue lengths and delays (both queueing and
geometric) at roundabouts. It is an aid in designing new junctions as well as assessing the
effects of modifying existing designs. ARCADY includes accident prediction.
OSCADY module is for predicting capacities, queue lengths and delays at signalled junctions.
The capacity of traffic streams based on their saturation flows and various other properties
combined with details of the signal timings at the junction. Signal timings can also be
optimised by the program.

Page 24
For further details of these programs, and for latest news, current pricelists and purchasing
information, please visit https://www.trlsoftware.com.
Investigations carried out in the UK into possible improvements in traffic control of urban networks
in the 1960’s resulted in the development of TRANSYT/1 in 1967 by the Transport Research
Laboratory (TRL). Two trials of TRANSYT were carried out – one in Glasgow and another smaller one
in West London. The full-scale Glasgow trials were carried out with the cooperation of the City
Council in Glasgow. TRANSYT signal timings went ‘live’ in May 1967. TRANSYT was shown to
reduce the average journey times through the network of signals in Glasgow by about 16 per cent.
A similar reduction was recorded in the other smaller trial in London. Because of TRANSYT’s
international appropriateness, TRANSYT is now one of the most widely used signal timing programs
in the world.
TRANSYT has continued to be developed by TRL ever since its first release. TRANSYT 16 represents
another significant advancement of the product in terms of its traffic models, its features, and its
presentation. This latest major version is most noticeable by the introduction of a simulation model,
allowing the modelling of various demand-dependent scenarios to be modelled.
TRANSYT 16.0 (released in May 2019) is the first release of TRANSYT 16.
1.8.1 TRL Update Information Server

In order to provide up-to-date information relating to TRANSYT automatically within TRANSYT, such
as whether or not the version being used is the most up-to-date, the program will try to connect to
the TRL Update Information Server. If this connection is achieved and permitted by you, the bottom
horizontal status bar will display news concerning TRANSYT such as “NEW TRANSYT 15.5.0 Version
Available” (as shown below) or maybe blank if there is no update information available.
The displayed text is simply the title of the full information available on our server. Clicking on the
link will bring up the full message.
Connecting to the update information server DOES NOT RESULT IN THE

INSTALLATION OF ANY SOFTWARE, nor does it affect your installation or operation
of TRANSYT – including cancelling the link and/or ignoring the messages. We would
however recommend that messages that indicate a new release is available are read
and acted upon, as new releases may contain new features and repairs which you
will benefit from.
If having read about a new release you wish to download it, current maintenance holders can
request a download link by contacting software@trl.co.uk.

We would very much appreciate it if you could help us improve our products. The easiest way to do
that is for you to agree to let us collect anonymous statistics relating to the use of the product. For
example we can use the stats to work out which features are the most heavily used, and hence we
can then target improvements in these features.
To switch this option on, go to Main Menu > Help > “Help Improve TRANSYT” and select “Yes, I am
willing to participate” and press <OK>. At any time you can re-open this screen to opt in or opt out.
The work described in this report was carried out in the Software Division of TRL. The authors are
grateful to all those who carried out the development, technical reviews, auditing and testing of this
software product. The authors are also grateful for the documentation associated with earlier
versions of TRANSYT and to their authors.
The authors also thank the Department of Planning, Transport and Infrastructure, South Australia
for providing advice on creating the required data files from SCATS for subsequent import to
TRANSYT.
We would also like to thank Transport for London (TfL), UK who commissioned and funded the
original research and initial product implementation of the pedestrian behaviour at signals model.
The pedestrian behaviour at traffic signals modelling algorithm used within TRANSYT is used under
licence from Transport for London.

Page 26

Installing the Software Page 27
TRANSYT 16 will run on any modern PC under 64-bit Windows 10, 8, or 7 and as such there are no
specific hardware or software requirements other than those of a modern PC capable of running
standard 64-bit Windows desktop applications.
As may be expected, the program will run more smoothly on a PC with a fast processor and plenty of
RAM; this will be particularly noticeable if working with large networks and/or using the CTM traffic
model.
Recommended hardware and software requirements are as follows:
 A PC with a 2.0 GHz processor or faster
 64-bit version of Windows 8 or Windows 10
 8 GB RAM
 200 MB available hard disk space.
 A monitor with a resolution of 1280x1024 or higher. N.B. A wide-screen or dual monitor

display can also be very useful.
 a modern graphics card with hardware accelerated OpenGL capability
TRANSYT may run on other versions of Windows, but this is not guaranteed and is not formally
supported.
To install the software, browse the product download file for the SETUP executable, and run this file.
If you have been supplied with the product as a downloaded zip file, extract all the zipped files to a
temporary folder, and then run the SETUP executable from this temporary folder.
During installation, all necessary files are copied to the specified folder and an entry added to the
Windows Start menu.
To uninstall the software, please use the Windows Add/Remove Programs system, which is available
from the Windows Control Panel, or use the Uninstall option under the program’s Start menu entry.
TRANSYT is a copy-protected software product. Having installed TRANSYT it will initially run in a
‘DEMO’ state and in order to use the full product you must register it with TRL SOFTWARE.

Page 28
Moving the system date of your PC backwards is likely to un-register any

registered versions of this product.
There are three ‘states’ of TRANSYT’s copy protection system – “Stand-alone”, “Network”
(concurrent licence version) and “Demo”. Usually, versions are licensed on a per-site basis. Licences
may also be time-limited, i.e. a “Leased” or “Evaluation” licence. If you have obtained a time-limited
evaluation or leased version of the software, it will run in full unrestricted mode for a certain
number of days, and then revert to demo mode. You must then purchase a new unlock key to
unlock the full version of the software again.
Both the stand-alone and network copy-protection states are contained within the same product,
and the selection of which type to register (Network or Stand-alone) is part of the registration
process - Your selection must match the licence type you have purchased.
Some optional functionality of TRANSYT requires either an add-in module, or another

product to be registered, such as ARCADY and PICADY. Details of what added
functionality is accessible if you have either ARCADY or PICADY is described in
section 18.1.
ARCADY and PICADY or any other add-in modules can be registered from within
TRANSYT using the main menu option “Help > Manage Licences”. Please note that
when checking or changing the status of network versions of any of the listed
products, TRANSYT may take a few extra seconds to respond as it awaits
confirmation of the licence state.
When selecting the “Version” of ARCADY or PICADY you wish to use, please note
that only one version of the eligible versions is required to use the Priority Object
feature.
2.2.1 Stand-alone registration
Each installation of the stand-alone version of TRANSYT on an individual PC must be registered. Full
setup instructions are available in the file “SOFTWARE REGISTRATION.PDF” provided with the
software.
This document includes instructions on how to transfer your registered product from one PC to
another. Read these before you lose access to your old PC!
Depending on the situation, it is also possible to upgrade licences. This usually happens when
purchasing the full version of a product after previously leasing it. In this situation the software
licence can be upgraded. Again, see the file “SOFTWARE REGISTRATION.PDF” for full instructions

Installing the Software Page 29
2.2.2 Network copy-protected (concurrent licence) registration
The concurrent licence version works only on PCs with access to a LAN network and allows up to a
fixed number of PCs to run the product at the same time. In order to use the full product you must
setup the software as a Network Client.
Full setup instructions are available in the file “SOFTWARE REGISTRATION.PDF” provided with the
software.
2.2.3 Demo version
This version is described in section 7.4.
Please contact our product support team via software@trl.co.uk or +44 (0)1344 379777 to request
a free demonstration version of the product.
This demonstration version is not necessarily registerable. If you subsequently

purchase TRANSYT you may need to obtain a new version which you can register.

Page 30

Quick Start Guide Page 31
TRANSYT is an extensive product, but one that is designed with new users in mind. By, default many
features and tools are disabled or hidden altogether in order to avoid new users from being
overwhelmed by the number of options and being distracted from learning the basics. This chapter
is dedicated to those who “Want to know where to start, what to do, and in what order to do it”.
The following is only a very brief overview. See Chapter 1 for a general description of
the user interface.
To ensure a full understanding of how the graphical interface works it is useful to be familiar with a
few terms that are familiar to TRANSYT 16. Please spend a few moments reading the introductory
section of the Glossary. (TRANSYT GUI Terms)
Users that are familiar with previous versions of TRANSYT may wish to skim over sections of this
chapter as it is primarily for the benefit of new users.
You are likely to need to reference various other chapters while working through this one, e.g.
chapters 8 (Data Entry),) 10 (Data Grids), and 11 (Network Diagram). For details of further program
functionality please browse through the rest of this User Guide.
There is no fixed route through TRANSYT, and as such it offers a high degree of flexibility when
creating a new network. In general, data can be entered in any order and changed at any time: the
graphical user interface (GUI) is highly dynamic and any dependent data and screens are
automatically updated.
It is recommended that you first start the program with “Advanced Mode turned off (see section
7.5). This will hide some features of TRANSYT making it easier to get to grips with the reduced
number of inputs, outputs and features. This option is set when you run the program for the first
time, and can be subsequently changed via File Preferences or, for the current file, via the Data
menu. You will also find that, by default, a number of Model and Result options are switched off by
default. Leaving those items switched off until you want them will also make it easier to learn
TRANSYT.
Even with many features switched off or hidden, the open-ended nature of the TRANSYT GUI may
leave you wondering where to start… so below is one suggested way to build a new file. Please note
that this is only a suggestion, and with experience, you will find your own preferences and may well
find yourself building files in a completely different order.

Page 32
If in doubt, the “Errors and Warnings” task list (see section 8.7) always shows any current
problems with the file. For example, if you show the Task List immediately after starting a brand
new file, it will show a list of errors and warnings similar to the screenshot below, which should give
you an idea of what needs to be done. Double clicking on a row in the Task List will often take you
to an appropriate screen.
When the program first starts, or you click File>New, a list of library files will be presented to you.
Simply select the one you wish to use as a starting point for your own network, or use the browse
button to select your own non-library file. If you press Start a New File, TRANSYT will start off with a
minimalist network, while Cancel will simply close the window without doing anything at all.
Use the Data Outline (Data Outline), data editor and the toolbar icons to access each data area and
perform operations.

ALTERNATIVE: Special screens (see vertical toolbar) can be used instead to enter almost all data
items and often make the data-entry process quicker and easier.
Although the Data Editor and/or special screens can be used to enter most data it will often be
easiest to use the Network Diagram to build your network of traffic nodes, lanes (or links), controller
streams and O-D matrices, and then populate these with the required data. If you make a mistake
at any point, use the Undo/Redo buttons.
Therefore, assuming the use of the network diagram, a suggested order of data entry is as follows:

Page 34
1. In the File Description Area (via the Data Outline and Data Editor), Enter the project title,
location etc. and set the driving side.
Model and Result Options
2. Go to Main Menu > Data > Model and Result options… to select which items you want hidden
or shown in your file. TRANSYT files need a lot of data and present a lot of results and
therefore it is useful to be able to hide items you have no interest in.
Network: traffic nodes, lanes links, and pedestrian crossings
3. Optionally, use the network diagram’s Add a new…Junction button to merge more junctions
into your network – Thus saving you time (section 8.2).
4. Having merged all the files you wish to bring into your network, now connect the relevant
links and traffic streams. Use the lower toolbar item “Connect” to do this.
5. For areas of the network that you wish to build without the help of the Library System, you
can use the “Start a new file” button which will provide you with the most basic traffic stream
network to start with (see screen shot below). If you want, you can chose to delete this, in
order to start from scratch - Use the select tool at the top left of the top toolbar to click and
drag the selection over the network and then press “delete”.
6. Details of how to add items to your network is described in section 11.9.6. Items that you can
add are located on the lower toolbar. Note that the Traffic Stream item contains a menu of
different types that can be added. You can simply drag the chosen item onto the network, or
click on it and then click on the network to add them. (The first left mouse click defines the
upstream end and the second left mouse click defines the downstream end.)
7. At this point you may wish to decide whether or not to use traffic nodes. You may find it
easiest to add these all first (see screen shot), because traffic streams and links when added,
automatically attach themselves to the nearest node. The use of Traffic nodes is optional, but
they do help to identify junctions, can help when moving items within the network diagram
and can also affect how traffic is allocated to the network from the OD Matrices depending on
the settings used (section 14.4.4). Traffic Nodes have a visual representation dependent upon
whether or not anything connected to them are signalised.

N.B. you have a choice of constructing your network using traffic streams (plus arms and
lanes), or using links. Traffic streams are easier and more intuitive to use, require the use of
OD Matrices to assign flows to the network (which is generally easier), and also hide the
underlying structure of the network (again which is easier). The main downside to using traffic
streams is that the underlying network size will be bigger than you would naturally build
yourself if you used links, and therefore TRANSYT model runs will tend to be slower.
If using traffic streams and lanes carry out steps 8 to 15 and if using links carry out steps 16 -
21.
When using Arms, Traffic Streams and Lanes:
8. Add all arms, locating them in the appropriate location between the relevant nodes (if used)
as you create them. N.B. Arms are really only containers for traffic streams, so have very few
properties. They are created with one traffic stream and one lane within that. Extra lanes
can be added by using the appropriate right-click menu item. TIP: New traffic streams are
always created on the offside of any existing traffic streams on an Arm. Similarly new lanes
are created on the offside of any exiting lanes - Use the Move Lanes mode to change the
order if necessary.
9. Add the required number of additional traffic streams and number of lanes within each
stream. Normally you will be specifying as many lanes as you have actual lanes on street. In
general, one traffic stream is required to represent each distinct queueing situation that occurs.
N.B. Using one traffic stream for every lane can often result in pessimistic results, i.e. longer
queues and higher delays. Lanes are a means to calculate saturation flows and it is the traffic
streams that are the most significant modelling items. (If you are more familiar with TRANSYT
link structures, a Traffic Stream’s equivalent is a major link).
10. The traffic stream control type (e.g. signalled/unsignalled and whether or not it is a give-way,
etc.) can either be set using the appropriate toolbox tool, or, you can right-click on the traffic

Page 36
stream after having adding it, to set the control type, etc. Traffic streams leaving the network
can be set as have unrestricted flow and not signalled.
11. Attach each Arm to its traffic Node (if used) using the Manipulate…Connect tool on the
diagram bottom toolbar. These associations are shown with the blue cones; moving each
traffic node will now move all attached arms as well.
12. Create one controller stream for each genuine controller stream, and attach each signalised
traffic stream to the relevant controller stream using the Manipulate…Connect tool. This tells
TRANSYT which controller stream controls the traffic for each signalised traffic stream. These
associations are shown with the green cones. By default, traffic streams are automatically
connected to the nearest controller stream (if one exists) and to nothing otherwise, so you
may find adding these earlier in the construction process makes construction marginally
quicker. The connector tool can be used to redirect connection to the right controller stream.

13. Attach each traffic stream to its downstream traffic streams by using the connector tool in the
network diagram. Note how you can click anywhere within the lane – no need to click at the
very ends of the traffic streams.

Page 38
14. Either double-click on the traffic-stream to use the Traffic Stream Data Window to set up any
required properties such as give-way properties, lengths, and so on. Lengths can either be
entered manually or set to be calculated from the diagram. (For saturation flows see the next
step.) This will select the chosen data in the Data Editor. N.B. If you choose the option to
calculate Lengths automatically, you MUST scale the diagram for these values to be accurate
– see 11.10.1.1 on how to do this.
15. Decide whether or not you wish to enter saturation flows directly for the traffic stream or get
them from the sum of the lane values. If you decide to derive them from the lane values you
now need to add saturation flows for each lane. For each lane, either enter them directly or
estimate from RR67 data.
At this point the Task List will still show a large number of errors but these should all be to do
with signals rather than network connectivity.
Now skip to page 40
When using Links:
16. Add all links, locating them in the appropriate location between the relevant nodes as you
create them. To set the link control type (e.g. signalised/unsignalised) and whether or not it is
a give-way, pedestrian link etc.), you can either use the appropriate tool bar item, or, you can
right-click on the link after adding it and then set the control type, etc.

17. Attach each Arm to its traffic Node using the connector tool in the network diagram. These
associations are shown with the blue cones; moving each traffic node will now move all
attached arms as well.
18. Create one controller stream for each genuine controller stream, and attach each link to its
controlling controller stream by using the connector tool in the network diagram. This tells
TRANSYT which controller stream controls the traffic for signalised links. These associations
are shown with the green cones; moving each node will now move all attached links as well.
19. Attach each link to its downstream link(s) by using the connector tool in the network diagram.

Page 40
20. Set up any shared stop lines by using the shared stop line tool in the network diagram.
21. Double click on links and use the Data Outline and Data Editor to set up any required
properties such as give-way properties, lengths, saturation flows and so on.
At this point the Task List will still show a large number of errors but these should all be to do with
signals rather than network connectivity.
When using Arms, Traffic Streams and Lanes OR links:
22. ALTERNATIVE: Use one or more Data Grid screens to rapidly enter data for all traffic streams,
links, etc. in one go (see chapter 10). This saves having to click on each item in turn, especially
if you have all data to hand in a tabular form. Tip: You can use the Shift or Ctrl keys to make
multiple selections in the same column and then right-click to change all selected items to the
same value (see screen shots below).

Traffic Flows
You have a choice to enter traffic flows directly or to use OD Matrices to assign flows to the traffic-
carrying items in the network. N.B. if using a link structure using an OD-Matrix is optional, but it
must be used if using a lane structure. It is recommended that each separate OD Matrix should
only be used to assign flows to one, two or three junctions (a signalised roundabout counts as one
junction) as otherwise the underlying structure within TRANSYT can become very large (slowing
TRANSYT model runs appreciably) and may also require route choice decisions to be made.
When using an OD-Matrix to define flows:
23. Use the network diagram to add an OD-Matrix (section 14.4) and then add the required
number of locations. (Locations are where traffic both enters and leaves the network.) Using
the Connect tool, attach each location to the traffic stream (or link) to which the traffic will be
entering the network and also attach the traffic stream (or link) to the location which is
flowing to that location, making sure to connect the locations in the right order, i.e. location
to entry, and exit to location.
24. Enter your “normal” traffic flow data using the “Entry Flows” tab of your OD-Matrix, leaving
the various options in the “Local Matrix” tab as they are. If you find you are adding flows into
a cell that is a faded-yellow colour this traffic will not get allocated to the network because
this indicates that there are no underlying paths connecting the two locations. – You will
need to check that you have set up the necessary connectors.

Page 42
25. Also check that the paths created by the OD Matrix are valid paths – Select each path one by
one using the “Paths” tab (the network diagram highlights the items used by each path). If a
path looks unrealistic, disable it using the “Allocation Type”. Tip: You can use the filtering
system to examine just the paths to or from one particular location. This makes it a lot easier
to systematically check of any path are missing or need to be disabled.
26. Optionally set the Allocation Type to “Fixed” or “Percentage” in order to specify how much
traffic uses a particular path – if appropriate for the model you are creating.
TIP: Use the Flow Consistency Diagram built into the Traffic Streams Data screen to check the
consistency of traffic crossing from one OD Matrix to another.
Now skip to step Signals

When defining flows directly to links and their sources:
27. You can enter traffic flows and set up cruise times etc. by clicking on each link and source in
the network diagram and then entering the appropriate numbers in the Data Editor.
(‘Sources’ were referred to as ‘upstreams’ in TRANSYT 12). Click on a link to view and edit its
main flow and uniform flow; click on a connector between links to set up the flows between
links.
28. ALTERNATIVE: Use the Links Data screen to view and edit sources for each link and all flows
for links. This screen incorporates a link consistency tool that allows you to identify where
discrepancies in your flows exist.
29. ALTERNATIVE: Use one or more Data Grids to view and edit all flows for all links (and similarly
for all sources).

Page 44
Naming your network items:
30. Having created your network, you may want to quickly name the various network items in a
consistent and logical manner. A facility to apply a naming convention automatically across
your network is accessed from Main Menu > Tools > Automatic Network Item Naming. See
section 25.1 for more details on this feature.
Signals
You have previously created your controller streams and then associated each signalled traffic
stream (or link) with the right controller stream. You now need to define the signal data (phases,
stages, sequences). There are various ways of entering signals data - Some suggested methods are
given below:
31. Add the number of phases you want using the Data Outline or open the Signals Data screen,
select the Phases tab, and click the “Create New Phases…” button. Specify how many you
want, accepting that any existing ones will be removed. N.B. phases can be added individually
on this screen by right-clicking on the left-most column of any existing phase.

32. Optionally, set the Phase “Type”. This makes it easier for others to interpret your signal data
and allows the colour coded timings diagram to display what type of phase it is. If set,
warning messages will also tell you if the phase is subsequently used inappropriately. In order
to enter a pedestrian phase blackout period you must set the phase type.
33. On the same tab, set any minimum greens or maximum greens you wish to define.
34. For each traffic stream (or link) use the network diagram (Right-click on controller stream),
Links Data Screen, Traffic Streams Data screen or Data Editor to set the Signal Phases which
define the signal conditions given to each traffic stream (or link). Up to two phases can be
associated with each traffic stream or link, which allows filters and turn indicative arrows to
be modelled.
35. Use the Intergreen Matrix (“Matrices” on the vertical button bar) to specify which phases
conflict with each other – this is done by entering intergreens. Note how the reciprocal
intergreens will auto-populate with zero intergreens as you type to ensure a conflict always
operates in both directions. A pale yellow background colour is used to indicate where
conflicts ‘might’ exist, based on the existing signal timings.
36. Alternatively (to previous step), you can calculate an initial set of conflicts and intergreen
values from the network diagram geometry. If you do this, you must ensure that the diagram
has been scaled. It is also advisable to curve all connectors within the junction. On-street
observations should be used to ensure that the intergreen values specified are suitable.
37. Using the Signals Data screen, select the “Stage Library Tab” and click the “Auto Generate
Stages” button. This will automatically create in the “Stage Library” a collection of all possible
stages – a stage for each valid combination of phases that can run together ( Outline:
Controller Stream n>Stage Library), e.g. For the above example two Library Stages would be
created – one with phase A and C running together and the other with just phase B.

Page 46
38. 1st ALTERNATIVE (to previous step): Using the Signals Data screen, select the “Stage Library
Tab”. You can use the “Create New Stages…” button to specify how many stages you wish,
and then simply type your comma-separated list of phases you wish to run in each stage.
39. 2nd ALTERNATIVE (to previous step): Open the Timings Diagram for the controller stream you
wish to edit. Within the Timings Diagram, click Tools>Reset and Create New Stages and enter
the number of required stages. Note that the “Auto Generate Library Stages” option does the
same thing as the “Auto Generate Stages” button on the Controller stream screen.
40. Using the Signals Data screen, select the “Delays Tab”. Click the “Create New Delays” button
to add any phase delays (gaining or losing) you wish to specify. Delays can be specified for
any stage transitions you like; hence why they can be defined before the stage sequence is
chosen. You may wish, however, to come back to this screen if you only wish to define phase
delays for your chosen stage sequence.

41. Select the “Stage Sequences Tab”. Click the “Auto Generate Sequences” button to tell
TRANSYT to create a number of valid stage sequences. TRANSYT will populate the data
outline “Stage Sequences” with up to ten of the simplest staging arrangements. The
sequence offering the lowest “minimum possible cycle time” is selected automatically as the
current sequence. (In the screen shot “Use Sequence” has been changed manually to use the
second sequence.)
42. ALTERNATIVE (to previous step): Select the “Stage Sequences Tab”. Manually create the
stage sequences: One sequence is already created automatically for you. Click on the column
titles “Stage IDs and enter the stages in the order you wish to have them running in the
sequence. To add more sequences, right-click on the left most column of the existing stage
sequence and select “Add a copy of Stage Sequence 1” or select “Create new sequence”.
43. 2nd ALTERNATIVE (to previous step): Select the “Stage Sequences Tab”. Click the “Stage
Sequence Diagram” button to launch the Stage Sequence Diagram. Drag and drop the stages
within the diagram to change the order of the stages to what you want. N.B. You can also re-
define the library stages used in the shown sequence by double-clicking on the red and green
phase arrows. (You can watch the effect in the Stage Library shown in the Data Outline.)
Right-click on any stage to add a new stage immediately before the one you clicked on.

Page 48
44. 3rd ALTERNATIVE (to step 38): Select the “Stage Sequences Tab”. Click the “Phase Timings
Diagram” button to launch the Timings Diagram. Right-click on each item in the diagram
(stages and green periods) and use the pop-up menu to add/delete stages or to redefine
which phases run in which library stage.
45. Set initial stage and phase times by dragging stages and phases with the mouse within the
Timings Diagram. Note that stages are NEVER automatically created, destroyed or redefined
within the diagram.
46. Optionally, Right-click on a controller stream to display a Timing Wheel for that controller.
You can check and edit stage change times from within the Network Diagram by using Timing
Wheels.
Network properties (NB you may prefer to set these at the beginning)
47. Use the Main Data screen (or Outline: Network Options>Traffic options) to select the traffic
model to use (PDM, CTM or Flare). Generally, you should use PDM when you do not
want/need to model blocking back, and CTM when you do. “Flare” is not strictly a model type
but instead tells TRANSYT to use the most appropriate model for a flared situation – If used
(quick flares can be used instead) it should be chosen for all traffic streams in the flared area.
A full description of each of these model options is explained in chapter 26.

48. Use the Main Data screen (or Outline: Network Options>Optimisation Options) to choose
which optimisation level you would like to use. The default is to optimise the start time of
each stage 1 on each controller relative to each other (i.e. the offset) and also to optimise the
length of each green period (i.e. changes how long each stage/phase will run for).
49. In addition to the optimisation level, the option “Enable out profile accuracy” by default will
be switched on. This option, when ON, speeds up optimisation considerably – especially for
larger networks. However, the optimisation results will generally be poorer ‘on average’.
When it is switched OFF, the highest accuracy values are used by the optimiser, ensuring the
best results are achieved.
50. Also select whether to apply the auto-distribute (stage timings) routine as part of the
optimisation process – This is essential if the current timings are not already valid. Otherwise
the current timings will be used as starting point for the optimisation.
Running the file and inspecting results
51. Save the file and then press the Full Run button. If there are any errors in the data file, you
will be directed to the Task List to try to fix those errors before running the file. Otherwise,
TRANSYT will start to run and the Running Calculation screen will keep you informed of
progress by showing a status bar and the best P.I. found so far. Note: For small networks and
evaluation (un-optimised) runs, this screen may only appear for the briefest of moments.
Using the Stop button will stop the calculations and produce results for the best P.I.
discovered so far.

Page 50
52. On completing the calculations the Summary Results screen will appear. This provides a
summary of the network operation. The Network P.I. (Performance Index) provides an index,
in monetary terms, of the entire network. If you have chosen the Optimisation Level = “None”
this is equivalent to running an evaluation run.
53. Inspect network results by locating Network Results in the Data Outline and then expanding
the relevant section. Alternatively access summary results for vehicles, or pedestrians using
the vertical toolbar Results button. N.B. the background colour of results will be lime-green if
they are up-to-date and red otherwise.
54. Inspect individual results by expanding the Results section of each item in the Data Outline.
55. Inspect assortment of results with the Data Grid screen. (N.B. TRANSYT is pre-populated with
some useful data grids which are available from the data grid drop-down menu.)
56. To analyse any subset of controller streams, traffic nodes, traffic streams or links, define a
“collection” (Outline: Collections).

57. Generate Flow Graphs (such Cyclic Flow Profile Graphs) and Spatial Graphs (such as Traffic
and Flow graphs using the two Graph buttons on the vertical toolbar.
58. Open the Report Configurator and select either an existing “Configuration” or which top-level
sections and what sub-items you want in your report. The “Concise” configuration will give
you the most basic signal timing results plus a summary of the performance of each individual
network item and of the network as a whole – it excludes input data.
59. Press the Generate Report button to create your report.

Page 52
60. View the optimised signal timings via the Timings Diagram.
61. Compare files using the main menu tool “Compare Files or Data Sets…”
62. View animations of signals, effective greens, queues and traffic flows in the
network diagram by showing the Animation Controls screen and then selecting from various
options within the network diagram.
63. Add a background to your diagram. Drag one of the diagram’s bend handles to
change its size and orientation relative to the network. In order to scale the diagram, right-
click on the diagram and select Tools > Go to scale ruler. Align and size the ruler to an artefact
of known length in the background image, and right-click on the ruler to set its length to the
same as the artefact.

64. Switch to 3D Mode to more easily find the best viewing angle and to present your
findings in a more meaningful setting.
65. Add 3D (.DAE) models to your network to help make your network easily identifiable.

Page 54
66. Generate Time Distance Diagrams (Main Menu > Tools), in order to observe and check
coordination along links. To keep these in the file, store the selection as a “Collection”
67. Most network constructed to work with the standard TRANSYT models will run in Simulation
Mode too - Click the Simulation button on the vertical tool bar, and if no error messages
appear on the task list, you can press the Start Simulation button. No need to wait for the
simulation to stop – Press the “Stop Simulation” button as soon as you like and now you can
try out some of the simulation visualisations. Start by selecting the “individual vehicles”
animation type, and press the green simulation arrow button to run the animation.
68. Assuming you’ve already add a background image, from the network diagram menu select
the “background” option “Show backgrounds and numbers/overlays only”. This will allow you
to see vehicles moving and queuing without the distraction of the network structure. An
alternative is to switch off the “Opaque” option for lanes.

General User Interface operation Page 55
This chapter gives an overview of the TRANSYT standard vehicular traffic models. For details of the
Simulation traffic model see Chapter 23. Anyone new to TRANSYT or only knows about building
networks with a link structure should read this chapter. Everyone else can probably skip this
chapter, other than those sections marked with the ‘NEW’ symbol. Details have been kept to a
minimum in order to keep the emphasis on getting to know how to use TRANSYT quickly, providing
just enough background prior to using TRANSYT. There are references to other chapters where
needed, to avoid duplication. These chapters will still need to be read in order to be able to
correctly model specific network features.
It is assumed that the reader is familiar with traffic engineering terms such as phase,
stage and stage sequence. For those new to the subject, or wishing to clarify, please see the
glossary in section 31.
TRANSYT makes the following assumptions about the traffic situation:
1. There is a cyclical nature to the traffic flows in the areas of the network where there
are traffic signals. (Unsignalled junctions can be set to assume random arrival
patterns).
2. All coordinated signals have a common cycle time or a cycle time a half, third or
quarter of this value; details of all signal stages and their minimum periods are
known. Different (non-multiple) cycle times can be defined within the one network
but no coordination is assumed at any boundaries between the parts of the network
that are running on different cycle times.
3. For each distinct traffic stream flowing between junctions, or turning at junctions,
the flow rate, averaged over a specified period, is known and assumed to be
constant1.
1
time varying traffic conditions can also be modelled in TRANSYT

Page 56
TRANSYT offers you a choice of how to represent the real network being modelled – either using a
series of nodes interconnected by ‘traffic streams’ or nodes interconnected by links. Each distinct
one-way stream of traffic is represented either by at least one traffic stream or link.
A TRANSYT traffic stream’ is made up of one or more TRANSYT lanes. TRANSYT lanes will in general
have a one-to-one relationship with real lanes on-street. However, TRANSYT links do not have a
one-to-one relationship with real lanes on-street, and generally represent particular movements of
traffic and/or types of traffic.
Each traffic streams and link has a number of properties that define their behaviour (and their effect
on traffic). For example, a signalled traffic stream will have the property “Has Saturation Flow” set
automatically to true, which allows a saturation flow rate to be specified (see section 4.5.5).
Unsignalled restrictions within the network such as a bottleneck can be modelled by setting “Has
Saturation Flow” manually, even though it is defined as unsignalled. A description of how each of
these ‘types’ of traffic stream and links is represented graphically in TRANSYT is in section 11.5.
If using both traffic stream representations and link representations within the same network, each
differently-represented part of the network must be connected with a simple ‘one link into one
stream’ or ‘one stream into one link’. That is the only restriction. You can have as many discrete
sections of the network build with the two structures as you like.
Additionally, each signalled intersection is represented by at least one controller stream.
The relationship between real traffic lanes and TRANSYT lanes will be generally a direct one-to-one
relationship, so is inherently simple to define within the TRANSYT model. Each lane is automatically
part of a traffic stream which can be used to represent one or more traffic lanes. The definition of
traffic streams depends on how traffic uses the lanes on the road. Traffic on one approach may be
represented by one or more traffic streams.
In general, one traffic stream is required to represent each distinct queueing situation that occurs.
Thus, trivial queues may not warrant representation by a separate traffic stream. However, a
separately-signalled offside turn traffic stream, with a significant flow, should be represented by a
TRANSYT traffic stream which is separate from the traffic stream representing straight ahead traffic.
One traffic stream may represent two or more lanes, provided that traffic is equally likely to join the
queue in any of the lanes and that identical signal indications are shown to these lanes.
This traffic stream representation suggests that a detailed knowledge of traffic routing through a
network is necessary to prepare the link diagram. In practice, it is usually sufficient for the traffic
engineer to use his judgement to decide whether traffic entering a section of road during a particular
stage green chooses preferentially a particular direction on passing through the next signal and, if so,
the proportions of various turning flows to assign to each traffic stream.

The relationship between lanes on the road and the way these lanes are grouped together to form
TRANSYT traffic streams is illustrated in Figure 4-1 and Figure 4-2. Figure 4-1 shows a simple
‘triangular’ road network. Figure 4-2 shows the corresponding diagram of nodes, traffic streams and
lanes. Traffic on the southern approach to Node 1 is represented by two separate traffic streams
because nearside turning traffic (traffic stream 13/1) receives a different green time (because of a
filter signal) to the other traffic (traffic stream 13/2) on the approach. On the northern approach to
Node 3 traffic is also represented by two separate traffic streams (32/1 and 32/2). This gives a more
realistic picture of traffic movements, since offside turning traffic from link 21 is unlikely to turn right
again at Node 3. Finally the westbound traffic arriving from location 3 is represented by one two-lane
traffic stream as the queueing situation is likely to be even since the straight ahead traffic (a major
movement) can utilise both lanes.
Figure 4-1 Network lane structure with flows

Page 58
Figure 4-2 Model lane and traffic stream structure
The relationship between real traffic lanes and TRANSYT links depends on how traffic uses the lanes on
the road. A single link may be used to represent one or more traffic lanes. Traffic on one approach
may be represented by one or more links.
In general, one link is required to represent each distinct queueing situation that occurs. Thus, trivial
queues may not warrant representation by a separate link. However, a separately-signalled offside
turn traffic stream, with a significant flow, should be represented by a link which is separate from the
link representing straight ahead traffic. One link may represent two or more lanes, provided that traffic
is equally likely to join the queue in any of the lanes and that identical signal indications are shown to
these lanes.
Just like the alternative TRANSYT traffic stream representation, the link representation suggests that a
detailed knowledge of traffic routing through a network is necessary to prepare the link diagram.
Again, in practice, it is usually sufficient for the traffic engineer to use his judgement to decide whether
traffic entering a section of road during a particular stage green chooses preferentially a particular
direction on passing through the next signal and, if so, the proportions of various turning flows to assign
to each link.
The relationship between lanes on the road and the way they are modelled as links is illustrated in
Figure 4-3 and Figure 4-4. Figure 4-1 shows a simple ‘triangular’ road network. Figure 4-4 shows the
corresponding diagram of nodes and links. Traffic on the southern approach to Node 1 is represented
by two separate links because nearside turning traffic (link 13) receives a different green time
(because of a filter signal) to the other traffic (link 12) on the approach. On the northern approach to
Node 3 traffic is also represented by two links (31 and 32). This gives a more realistic picture of traffic
movements, since offside turning traffic from link 21 is unlikely to turn right again at Node 3 and will
chose the nearside lane catering for traffic that is turning left or going straight on.

700
250 (J.T. = 12 sec)

400 100
600*
350 50
50
800 650
(J.T. = 30 sec)
300
700
200
N
J.T. = Average journey time
* All flow units in pcu/hour
All saturation. flows = 1800 pcu/hour
Figure 4-3 Network and flows
700
22
11 350 21 400
600 1 2
50 300
(left filter) 50
300
350 450 31 32
13
350
50
12
400
33
250 3 700
100
2 Intersection
or node
22
Link (No. 22)
Figure 4-4 Diagram of links and nodes

Page 60
The TRANSYT model requires each traffic stream and link to be defined in terms of certain parameters.
Those key data values relating to the modelling of traffic behaviour are given here, and those
concerned with signal control are described in section 0.
4.5.1 Lengths
Traffic Stream (or Link length) is the distance between the upstream and downstream stop lines. For
traffic streams (or links) which do not have any upstream traffic streams (or links), e.g. an entry traffic
stream on the perimeter of the network, it is normal to use a length such as 100m or 200m. Although
a one metre value may be used, it is not recommended as some TRANSYT results will make use of this
value for their derivation and this can result in some artificially high or low outputs.
Lengths are specified using either the data editor (Data Outline: Arm n > Traffic Streams > Traffic
Stream m) or the Traffic Streams special screen (See Figure 4-5).
Figure 4-5 Traffic Stream Length (m)
The “Auto Length” option allows you to let TRANSYT work out the length of any traffic stream
automatically for you from the distances between items in the network diagram. If this feature is
used, you should scale your network diagram to ensure that distances correctly reflect real on-street
distances.
4.5.2 Traffic flows

Traffic flows are either specified directly using the method described below or are assigned via OD
Matrices. See Chapter 14 for full details of how to allocate flows to the network using OD Matrices.
A mixture of these options is allowed if using a link structure, so parts of the network can have
assigned flows and others flows entered directly. However any parts of a network structure defined
using arms and traffic streams must use OD Matrices to calculate the traffic flows.

Where an OD Matrix is used, its data options are used to calculate and automatically assign values to
the Total Flows and Source Flows within that part of the network covered by that particular OD-
Matrix.
How flows are assigned directly to links is described in the following section.
4.5.2.1 Links
Link flows are specified in the Links Data screen (Outline: Links > Link n > Flows). Flows are normally
specified in PCUs or vehicles per hour. For each link you must specify the average total flow along the
link.
Figure 4-6 Link Total flows
Each link may have associated with it a uniform flow source (see Figure 4-7). This is a flow source
which enters the link at a uniform rate throughout the cycle. Thus, there is no platooning. It can be
used to represent, for example, uncontrolled flow from a car park. Links feeding into the network
from outside also carry uniform flow but these flow levels are set using the Source Flow and
associated Total Flow for the link. The Uniform Flow Source is used only when there are other
upstream flow sources. The uniform flow source contributes along with the upstream sources to
give the total flow, but need not sum exactly (see compatibility of link flows, section 4.5.4).
Links that have their flow allocated with traffic from an OD Matrix cannot also have a uniform flow –
an attempt to set one will result in the value being reset to zero. An extra OD Matrix “Location” can
be used instead.

Page 62
Figure 4-7 Link Uniform Flows
Each link can have up to eight upstream links supplying it with vehicles. For each of these upstream
links the flow and the cruise time or cruise speed of vehicles along the link from the upstream
source must be specified.
4.5.3 Cruise times and cruise speeds

Cruise times and cruise speeds are the un-delayed times (or speeds) for traffic travelling from each
upstream stop line (for each source traffic stream or link) to the stop line on the currently selected
traffic stream (or link). The values used should be those which correspond to actual traffic
behaviour and not an ideal value intended to give good progression; they should represent the time
taken to travel from upstream to downstream stop line, under prevailing traffic conditions, when
the signal aspects at both ends of the stream (or link) are green. It is possibly better to measure
cruise time (as opposed to cruise speed) because it ignores any error in traffic stream (or link) length
measurement, and by measuring over the whole traffic stream (or link) it automatically takes into
account skin-friction, curves, bottlenecks etc.
4.5.4 Compatibility of traffic stream and link entry and exit flows
The sum of inflows to link need not equal the total flow. This facility is provided because in practice
the flow values will often be obtained from on-street measurements made at different times.
TRANSYT automatically increases or decreases by the same proportion all upstream flow values so
that the total flow is maintained. If the proportional correction is large a message is printed as a
warning but the run of the model still proceeds. The flow consistency diagram that is integrated in
both the traffic stream data and links data screens can be used to investigate the source of any
unacceptable inconsistencies.
The calculation of the proportions of traffic leaving upstream links (or streams) and entering
downstream links (or streams) are made before the traffic modelling and signal optimisation
calculations. If, in the traffic modelling process, a link (or stream) is oversaturated so that less traffic
leaves than enters, then the downstream volumes are reduced accordingly and the flows specified
as the Total Flow will not be maintained.

4.5.5 Saturation flow

Saturation flow is the maximum rate of discharge across a stop line during green while a queue
remains. At existing sites the saturation flow can be measured. On the other hand, when planning a
new junction or major alterations, the saturation flows have to be predicted from other known
quantities such as stop line lane widths and other site factors.
The prediction of saturation flows is covered in TRL Report RR67 (Kimber et al, 1986) which
describes large scale studies into saturation flow carried out between 1982 and 1986. From these
studies, empirical formulae have been derived from which it is possible to predict saturation flow for
a given set of junction parameters.
Saturation flow rates should be specified in PCU/hour or PCU/minute – as indicated/selected).

Saturation flows can be specified in vehicles, but only if all PCU factors are set to 1.0 and the flows
themselves are in vehicles also.
Saturation flows need to be specified for most traffic streams (or lanes) and links. It is not required
where all traffic makes use of the give-way max flow throughout the cycle does the TRANSYT model
not use the saturation flow’s value, i.e. a pure give-way with all traffic opposed. It is also not
required for unrestricted traffic streams and links, which are used where no restriction to traffic is
present, such as those exiting the network.
TRANSYT applies these formulae when using the Use RR67 option either in traffic stream “Lane”
data (Outline: Arm n > Traffic Stream m > Lanes > Lane p) or major link data (Outline: Link n). When
calculating the saturation flow for a major link of a “link share”, the number of lanes it is
representing is needed, so that there is somewhere to specify the lane-specific data required for the
RR67 calculations. Minor links do not require any RR67 data.
4.5.5.1 Calculating Lane Saturation Flows

The “Saturation Flow” can either be entered directly for a whole traffic stream or for each lane
within it. When specifying saturation flows per lane, these will be summed by TRANSYT to give an
overall saturation flow for the traffic stream. For each lane you also have the choice of entering the
saturation flow directly or deriving it from geometric data using the UK’s RR67 equations. If “Use
RR67” is selected the directly-entered saturation flow item is greyed out, and extra data needs to be
specified. These are as follows:
 Site Quality Factor: This can be set to “Definitely Poor”, “Average” or “Clearly Good”.
For more detail on this factor see RR67. N.B. This parameter is only selectable when
using traffic streams.
 (Road) Surface Condition: This can be set to either “wet” or “n/a”. “n/a” is the
default and indicates that this parameter is ignored within the model – This is not
quite the same as saying the road surface condition is “dry”. N.B. Used by traffic
streams only.

Page 64
 Gradient (%): The gradient should be entered as a percentage. If the slope is

downward, this can be entered as negative, although negative gradients have no
effect on saturation flows. Usually the gradient for all lanes in an arm will be
identical.
 Width (m): Lane widths should be measured at the stop-line.
 Proportion That Turn (%): This is the percentage of traffic on the lane that makes any
turning movement (left or right). If the turning proportions change, say, due to
changes you make to the O-D Matrix, you should also update these values. See
“automatic” option below.
 Turning Radius (m): The radius of turn is the approximate radius of the circle
described by vehicles as they make a turn, and can be set to 99999 for straight ahead
movements (although any similarly large number will equally do). If there is both a
left and right movement on the lane, enter the smallest (tightest) radius.
 Nearside Lane: Tick this box if the lane is regarded as a nearside lane.
The Auto turning Radius option allows you to let TRANSYT work out for you, both the proportion that
turn and the turning radius automatically from the network diagram. This has a particular advantage
over specifying the values directly, as it will ensure that the values will always reflect the allocated
traffic flows in the network whenever these change.
If this feature is used, your network diagram should be scaled to ensure that distances correctly reflect
real on-street distances.
Before TRANSYT can work out the amount of traffic that turns, TRANSYT needs to work out for each
movement (downstream source) whether it is a straight or a turning movement. In fact, TRANSYT
estimates from the diagram whether or not the “traffic turn style” is “nearside”, “offside” or “straight”.
A turning radius is also worked out for nearside or offside turns, and this is factored into the RR67
saturation flow calculation.
The network diagram can be used to check that the auto calculated traffic turning styles are
reasonable, and if not they can be changed manually.
4.5.5.2 RR67 (Saturation flow estimation) Reliability

The use of RR67 formulae to predict saturation flows is quite reliable even for junctions that are
currently at the planning stage, but some error is involved due to unexplained site-to-site variation.
The error due to site-to-site variation in the RR67 survey was 12 percent at the 95 percent
confidence level. In other words 88 percent of the variation in saturation flow from site-to-site
could be explained by known parameters (e.g. number of lanes, gradient, lane widths etc.) whereas
12 percent could not be attributed to a specific cause. The error in the results predicted by TRANSYT
can be reduced by using measured values which are more likely to represent the junction being
modelled, wherever possible.

4.5.5.3 Blocking by turning traffic

If the saturation flow is reduced due to blocking of turning traffic by opposing traffic, then this may be
approximated by increasing the relative start displacement for the start of green on that traffic stream
or link (see section 0), or may be modelled more accurately using the give-way facility
(see section 18.14).
4.5.6 Entry and exit traffic streams and links

For entry traffic streams and links on the perimeter of the network, having no upstreams, it is
recommended, in order to maintain a reasonable estimate of time spent within the network, to
enter a cruise time (or speed) for travel over the length of traffic stream (or link) specified in the
Sources Data screen (Outline: Links > Link n > Sources or Traffic Streams > Traffic Stream n > Sources.
No source traffic stream (or link) should be defined. The use of the Cell transmission Model (CTM)
on these entries offers no advantages and will slow down runs of TRANSYT so it is best to use the
PDM for such items.
Exit links are not required by TRANSYT unless using OD Matrices to allocate flows to it, but can be
useful if the direction of traffic exiting the network is to be shown graphically. If using traffic
streams, exit traffic streams are compulsory. In order to maintain a reasonable estimate of time
spent within the network, a cruise time (or speed) associated with the travel time along the link is
required. If you wish the exit link to have no influence on the signal optimisation and be excluded
from the network results, the Links Data screen option “Exclude from results calculation” can be set.
This effectively ensures that the P.I. for the link is assumed to be zero and hence does not contribute
to the overall Network P.I. Although individual results such as delays will still be shown, they will no
longer contribute to the network results.
If you do not want any queues to appear on exits, the “Has Saturation Flow” option should be de-
selected. This ensures an infinite capacity (unless using CTM) and indicates to anyone looking at the
network that the traffic stream (or link) is being used in such a way that it does not act as any form
of restriction to traffic flow, or you don’t care about what is happening at the downstream end of it.
If using CTM, the cell saturation flow can still affect traffic flow, so should still be set to an
appropriate value (see section 19.3).
4.5.7 Bottleneck traffic streams and links

Bottleneck traffic streams (or links) are unsignalled links which do not give way to other traffic, but are
restricted in some way. They are treated as if they are controlled by a 100 per cent green signal at
which a fixed saturation flow is defined. A bottleneck traffic stream (or link) is treated in a similar way
to other traffic streams (or links) – it can be associated with a traffic node for display and reporting
purposes (either as a true bottleneck or as part of a priority junction), but is not associated with a
controller stream, as it is not controlled by signals.
Shared links which are bottlenecks are specified in the Shared Stop lines tab of the Links Data screen
(Outline: Links > Link n), in a similar way to signalised links, but the ‘main’ link still has only an optional
traffic node and no associated controller stream.

Page 66
Delays and stops are calculated for bottlenecks exactly as for other traffic streams (or links), except
that the flow leaving is controlled only by the saturation flow. Thus, uniform delay and stops will occur
only if the flow arriving at some point during the cycle exceeds the saturation flow.
Random-plus-oversaturation delay and stops are calculated in the normal way (see section 27.2).
Tip: You may prefer to use Simulation Mode to study oversaturation in your network, because it
models the whole modelled time period – not just an average single cycle. See Chapter 23.
For details of the implementation within TRANSYT, please see sections 16 and 18.14.
4.6.1 TRANSYT signal terminology

TRANSYT models the operation of the signal control at each controller stream by reference to its own
stage change times. TRANSYT uses a standard definition of a stage; hence a particular stage start time
is defined as when all the phases running in that stage are green. The end-of-stage time is defined
when the first of the phases in the stage has ended their green. The green time displayed to traffic on
any one link may be initiated by any stage change and terminated by any other stage change.
When considering co-ordination between signal controlled intersections it is necessary to have a

convention which relates the green periods of any one junction to those at the other junctions in the
network. In TRANSYT this is achieved by relating all ‘stage change times’ to a common, although
arbitrary, zero time as shown in Figure 4-8.
The offset of an intersection is defined as the start time of stage one. In this way the offset may be
thought of as the start of the cycle for the node concerned, where the cycle commences with the
start of stage one and continues through the other stages in sequence.
Traditionally, TRANSYT defined stage change times as the time at which the green
signal aspect on one stage is terminated and the change to the next stage green period is initiated,
and hence includes the preceding interstage. By default, this definition is no longer used to present
results. However, TRANSYT can report “old definition” stage timings if comparisons with older
printouts are required. These are the “Call to Stage” the “Preceding interstage” and “Inclusive stage
minimum” – a minimum that includes the preceding interstage. A “Model and Results” option is
selected to reveal these parameters in the Resultant Stages Data. These parameters are also
presented in the TRANSYT Outputs – see section 22.2.9.

Stage 1 signal aspect

2 G R G
O2
OFFSET DIFFERENCE = O2 - O1
Stage 1 signal aspect

G R G
1 O1
arbitrary zero cycle time

Time
Figure 4-8 Illustration of offset and offset difference
If the offset value at one junction is subtracted from that at an adjacent junction, the difference in
offset defines the start of the cycle on one controller stream relative to that on the other and hence
defines the co-ordination along any traffic streams or links connecting the two junctions.
TRANSYT models the response of traffic to the actual signal changes by using effective green times as
opposed to the actual stage greens as explained later (see section 4.5).
The values which must be specified to define the signal timings at each controller stream in the
network are defined either for the whole network or for each individual controller stream as follows:
4.6.2 Signal values for the whole network

These values are specified in the Main Data Screen (Main Data tab).
The network cycle time for the whole network is specified in seconds (Outline: Network Options >
Network Timings).
The effective green displacements (start and end), to be applied to the whole network, are specified
in seconds (Outline: Network Options > Signals Options). Both the start and end of effective green
used in the model may be made to occur a few seconds after the actual signal stage change by
specifying ‘displacements’ of fixed duration. These displacements apply to all traffic streams and
links in the network. Figure 4-9 illustrates this concept.

Page 68
The intention is that the displacements specified in the Main (Common) Data represent the inertia of
drivers and vehicles in responding to signal indications, compared with TRANSYT’s instantaneous
stop/starts. The start displacement corrects for the time lost accelerating from rest up to cruise
speed. In the UK this value is typically 2 seconds, but a larger value would be appropriate where the
before green (starting) red-with-amber period is omitted.
D = Effective green displacement

at start of green
D = Effective green displacement
at end of green
D1 D2
Red Green Red Effective signal timings
Red Green Red Actual signal timings
Red/Amber Amber
Figure 4-9 Effective versus actual signals
The global end displacement corrects for traffic continuing to flow during the end-of-green amber
period as though the signal were effectively green. In the UK this value is typically 3 seconds (equal to
the full duration of the amber period). TRANSYT models traffic behaviour using effective green
periods, which are typically 1 second longer than, and displaced relative to, the actual green signal.
Additional relative displacements may be specified for individual phases - See section 4.6.3.5.
4.6.3 Signal values for each controller stream

Each controller stream may contain data for up to 50 stages and 50 phases. These values are specified
in the Signals Screen (Outline: Controller Streams > Controller Stream n > Stages). Phase data, phase
delays, a library of stages, a collection of stage sequences and calculated stages data relating to each
stage used by the traffic model, are all stored within each controller stream.
Each controller stream makes reference to a particular stage sequence (the Use Sequence value). The
referenced stage sequence can be any sequence in the list of existing sequences for that controller
stream. Stage sequences can be created manually by firstly creating the required stages in the Stages
library, and then defining the order of stages in a new Sequence. For convenience, all possible stages,
plus a collection of the ten simplest valid stage sequences can be generated automatically using a
“Generate Stages and Sequences” routine.

From the above described data TRANSYT calculates internally information relating to each of the
stages that is going to be used by the model, i.e. those referenced in the current sequence. This
information is reported under the description “calculated Stages”.
The Stage change times, part of the calculated stages data, are always shown in seconds.
4.6.3.1 Stage Library, Stage Minimums and Interstages

For each library stage a minimum green period can be defined. The minimum green period (User
Stage minimum) is the time between the start of the last phase starting in that stage and the earliest
time that this stage could end. This would normally be the minimum for the phase that started last,
unless this phase is a turn indicative arrow in which case it could be the minimum of one of the
other phases. This value is ignored if it is less that TRANSYT’s own calculated minimum stage length.
The calculated stage minimum, plus the phase minimums and phase maximums all act as constraints
used by the TRANSYT signal timing routines, to prevent a stage or a phase having an unduly short or
long green time. A combined value in the range of 10 to 15 seconds is normal for vehicular traffic but
pedestrian crossing needs may dictate longer times.
For a pedestrian stage, the minimum green period is the time from the end of the interstage period to
the end of the green man indication, or the end of the pedestrian black-out if this exists. For
pedestrian-only stages, the TRANSYT optimiser will typically choose the minimum stage length
unless the pedestrian costs are set to contribute to the Performance Index. This is because no
vehicular traffic flows during the pedestrian stage so there is usually no dis-benefit seen by the
optimiser when the stage length is reduced.
Interstages need not be specified as these are derived from the phase intergreens and
phase gaining and losing delays. The interstage is specified in seconds and is defined as starting
from the termination of the first phase to lose green when a stage change is made (it also signals the
end of the stage) to the commencement of the green for the last phase to receive green in the next
stage. TRANSYT produces an interstage matrix that allows every possible interstage to be viewed,
and also edited via the Timings Diagram, if required.
4.6.3.2 Phase Constraints

Phase constraints (phase-to-phase Intergreens) are specified via the Intergreen matrix screen.
Additionally, banned stage-to-stage transitions are also defined here. Other phase data is specified
in the Controller Stream Data (Signals) screen (Outline: Controller Streams >Controller Stream m >
Phases > Phase n).
In the Controller Stream Data (Signals) screen, Minimum and maximum green times can also be
specified on each individual phase in order to constrain phase lengths to what is required (Outline:
Controller Streams >Controller Stream m > Phases > Phase n).
4.6.3.3 Derived Phase Values and Green periods

During one cycle a traffic stream (or link) may have one or, optionally, two, three or four green
periods during which outflow occurs. These green periods are determined by the green times

Page 70
associated with the controlling phases and need not be the same length, but will have the same
value of saturation flow.
Traffic stream (or links) may receive green for all or part of one or more stages. The time at which
the actual green begins is determined purely by when the phases actually run, and these are
determined by you, by specifying which stages they run in, and whether or not there are any phase
delays. Phase delays alter when a phase will start or end relative to the stage it is running in – This
could result in the phase starting early or ending late. N.B. a phase starting later than any other
phase, or finishing earlier than other phase defines the actual start and end of the stage.
The effective green can be extended by use of a relative end displacement.
Should the traffic stream (or link) have a second green, the corresponding values detailed above for
the first green will also be derived by TRANSYT for the second one.
4.6.3.4 Phase Delays

Phase actual green times are specified relative to the genuine stage start and end times using
“absolute” phase-gaining and phase-losing delays. “Relative” phase-gaining delays can also be
specified, which are relative to the relevant intergreens rather than the stage ends. These values can
either be entered directly or manipulated graphically in the Timings Diagram (see section 16.3.2. Valid
stage change times are always needed by TRANSYT, and initial ones can be provided by using the
“Repair Timings” button on the Timings Diagram. See Figure 4-10 to see how phase delays are
presented in TRANSYT.
Figure 4-10 Absolute phase gaining delay and phase losing delay
4.6.3.5 Phase Effective Greens
As well as the global start and end displacements, additional relative displacements may be specified
for individual phases, if it is thought that the values for that phase differs from the overall value.
The displacements in the Main (Common) Data and the relative displacements are added together in
the program to give the effective green times before the queue calculations are carried out. For
example, if the global network start displacement (see section 16.8) is 2 seconds, and it is known that
for the phase being considered, the effective green displacement is one second longer than the overall
value, then the required relative start displacement is simply 1 second.

However, all effective displacements are subtracted from the calculated green times before these
are output in the results (see section 22.2) so that the traffic engineer can easily compare TRANSYT
values with observations of actual signal green times.
Furthermore, a negative relative start displacement (say -2 seconds) could be used to justifiably
remove or reduce the standard start displacement in situations where good coordination has
resulted in the front of a platoon of traffic arriving during a green signal.
Relative displacement values can also be used to take account of the effects of downstream
blocking. This change to the relative green times is sometimes referred to as “Underutilised green
adjustment” (UGT). Either a positive relative start displacement or a negative end displacement can
be used depending on whether the blocking occurs at the start or the end of green.
TRANSYT’s macroscopic modelling system makes use of one of three traffic models. These are the
platoon dispersion model (PDM), the Cell Transmission Model (CTM) and the ‘congested’ platoon
dispersion model (CPDM). The three models each have their own strengths and weaknesses. The
CTM is particularly useful for small networks with short traffic streams (or links). Its main advantage is
its ability to model the effects of traffic blocking back from one junction to another reducing the
upstream junction’s capacity. The PDM is suited to all network types and has the advantage of being
able to model the dispersion of platoons of traffic along traffic streams (or links), but does not model
the effects of blocking back. The CPDM is an adaptation of the PDM model such that it can model
specifically short bays (flares). Full details on these models are given in chapter 26 and on cyclic flow
profiles in Section 20.4 including advice on choosing the right model to use.
To model traffic behaviour within the network using these models, the common cycle time is divided
into a number of intervals called steps. For convenience, a step is typically set to be one second long.
How these ‘steps’ are used depends on the model used.
With the PDM model TRANSYT’s calculations are made on the basis of the average values of traffic
demand and queues for each step of a typical cycle. The resultant histograms of traffic arrivals per
step are termed cyclic flow profiles.
The profile of traffic entering a traffic stream (or link) will be displaced in time and modified during the
journey along the traffic stream (or link) link due to the different speeds of the individual vehicles.
Thus, platoons of vehicles will be partly dispersed. The amount of dispersion can be modified for
individual traffic streams (or links).
By selecting the PDM model, TRANSYT automatically takes into account the importance of having
good progression on short links.
The CTM model also uses ‘steps’ but is it also discrete in space as well as in time. As a result the CTM
cyclic flow profiles are different and are differently presented. The representation of traffic is
therefore different to the PDM model.

Page 72
The CPDM model has an additional ‘blocking’ capability that allows it to be used to model situations
flared situations. It can be considered as a superior replacement for the Flare model that was in
previous versions of TRANSYT. See section 4.12.
The CPDM model is NOT directly selectable within the program – instead the components of a flare
(the short lanes) are defined as flares and the program will use the most appropriate blocking model
that is required – this will either be CTM or CPDM. Overall flare results are then reported on the
feeding traffic stream or link.
All the models use a simplification of real traffic behaviour, and do not model individual vehicles.
Despite this, TRANSYT is able to predict good estimation of traffic delay.
Full details of the data required for these models are given in chapter 26.
Total delay to traffic on a traffic stream (or link) is the sum of the delays to all the individual vehicles
using the link (or stream) during a period of time. Total delays are usually quoted in units of
PCU-hours/hour. For example, during a cycle of 100 seconds, 40 PCUs pass through a signal. On
average they experience 20 seconds of delay each. Thus, the total delay rate is 800 PCU-seconds per
100 second cycle (equivalent to 8 PCU-seconds/second or 8 PCU-hours/hour). This delay rate is
equal to 8 PCU and can be visualised as the average number of PCUs queueing throughout the cycle
considered. This is strictly true only for the idealised vehicle behaviour that is assumed in TRANSYT.
Nevertheless, this interpretation is a reasonable approximation to what happens in reality.
Similarly, the total delay rate in a network of signals can be considered as the sum of the average
queues at all the stop lines. In TRANSYT, the total delay rate for traffic on a traffic stream is
obtained partly from the cyclic flow profiles and partly using a simple formula.
When considering the growth and decay of queues, the fact that individual vehicles arrive at
random, and that average arrival rates may vary over the modelled period, means the accurate
modelling of queues is complicated. The problem was studied comprehensively by TRRL (Kimber
and Hollis, 1979) and a time dependent method of predicting queues and delays was developed. The
method considers the probability distribution of queue lengths as a function of time.
Queue lengths are derived from cyclic flow profiles during each step of the typical cycle. As well as this
‘uniform’ component of queue, additional elements associated with random and oversaturated effects
are added to these. Full details of queue length derivation are described in Section 27.2.1.
TRANSYT also calculates the total rate at which vehicles are forced to stop on a link. This too, is
made up of a ‘uniform’ component and a ‘random-plus-oversaturation’ component. As for delay,
the uniform component is obtained from the cyclic flow profiles and the
random-plus-oversaturation component is calculated from simple equations.
As part of the calculation of traffic behaviour on a traffic stream (or link), TRANSYT estimates the
maximum queue length to be expected with the given signal settings. In reality, on some traffic

streams (or links), particularly short ones, the queue may reach back from one junction to another,
thereby at least partially blocking the upstream junction. This complex effect is, however, not
modelled in TRANSYT’s platoon dispersion model (PDM) which assumes that all vehicles queue at
the stop line. TRANSYT does however include a facility whereby you can specify a limit queue for
selected traffic streams (or links). The signal optimiser then attempts to find settings which make it
less likely that the maximum queues will exceed the limit values (see section 28.6). Furthermore,
the new Cell Transmission Model (CTM) does model blocking back effects, which can be used
instead of the PDM model in certain circumstances.
It is generally a good idea to attempt to remove or reduce blocking before trying to model these
blocking effects themselves.
4.9.1 Mean maximum queue

TRANSYT computes a mean maximum queue (PCU); this value is estimated from two components as
follows. During the typical cycle (see section 4.7) modelled in TRANSYT, a check is kept on the
position of vehicles adding onto a queue (measured in numbers of PCU back from the stop line
rather than in distance units). During a green period, traffic discharges from the front of the queue
but further traffic may join the back of the queue. The ‘maximum back of queue’ is the position (in
PCU) reached by the back of the queue just as the queue empties (see Figure 4-11). This value is an
average obtained assuming that arrivals each cycle are identical to that modelled during the typical
cycle and is known as UMMQ, uniform component of the MMQ. The second component is the
average random-plus-oversaturation queue (numerically equal to the random-plus-oversaturation
delay on the link), which is added to the maximum back of queue to give the reported value.

Page 74
Queueing vehicle Arrival rate = 1 pcu / 4 seconds
Vacated space Departure rate = 1 pcu / 2 seconds
Max. back of queue 4 5 6 7 8

Queue 4 3 2 1 0
Stop line
0 4 8 12 16
time
Figure 4-11 Uniform Component of Mean Maximum Queue
The second component is a correction to the maximum back of queue value which makes some
allowance for variations in queue size from cycle to cycle. It may be thought of as the average
number of vehicles which fail to discharge at the end of the cycle, although, in reality, this may be
zero or a larger number during individual cycles.
The mean maximum queue (PCU) is only an approximate average of the maximum queues likely to
be encountered, and it will therefore be exceeded a sizable proportion of the time.
In urban road networks there are usually a number of priority junctions. If significant, these should
be modelled.
In TRANSYT there are three types of priority situations that may need to be modelled. The first
situation is a give-way junction (priority intersection) located somewhere between the signal
controlled junctions. This can include unsignalised approaches to partially signalised roundabouts.
The second situation occurs is a give-way junction (priority intersection) located downstream of a
nearby signal controlled junction that affects the drivers behaviour at the give-way due to their
knowledge of the signal states. A clear example of this is a nearside filter lane that allows traffic to
bypass the signalled junction and then has to give way to traffic fed from that same junction.

The third situation occurs within a signal-controlled junction i.e. traffic on a link which, although
signal controlled, must also give way to an opposing flow. Such situations occur frequently at
signalled junctions where the offside traffic turns without a separate signal indication.
In all of these situations TRANSYT is able to take account of the varying opposing (controlling) traffic
conditions that the opposed (give-way) traffic has to yield to, and calculate the required queue,
delay, stop, and other performance information.
Additionally, when using the CTM traffic model, congested give-way situations can also be taken
account of.
Full details on how to model these give-way situations are in the chapter 18 and section 27.5.
Normally no distinction is made in TRANSYT between the various types of vehicles on a link. The use
of shared stop lines allows separate classes of vehicles to be represented in any one queueing
situation where, in reality, the classes of vehicles are mixed together, i.e. in a ‘common queue’. One
reason for this separation of vehicle types is because the vehicles exhibit different behaviour such as
buses which may stop at bus-stops along the link or travel slower along the link.
Furthermore, the vehicle ‘types’ need not be different types of vehicles but may consist of vehicles
which, for example, entered from different roads at the upstream intersection. This facility has
proved particularly useful when modelling signalised roundabouts (see AG48, Chapter 11).
Full details of shared stop lines are given in 27.6.
You must decide how many classes of vehicles are necessary to represent the conditions being
studied. Each class of vehicle at a common stop line is represented by a separate shared link. For
vehicles in a given class at the shared stop line, TRANSYT calculates the delay for that class taking
into account delay caused by the interaction between all vehicles using the shared stop line.
Shared stop lines can be applied to both signalled links and give-way links.
When representing your network using traffic streams instead of links, you should use the facility
within the OD Matrices to specify buses or trams separate from ‘normal traffic’.
TRANSYT provides facilities to model the extra capacity available from flared approaches (short lanes)
giving an extra lane or lanes at the stop line. Flares can be modelled using one of two different ways:
1. One way is to use a traffic model that can model the blocking back effects associated with a
flare. Flares are modelled by setting the relevant traffic streams (or links) to use the “Flare”
traffic model. TRANSYT will then use the most appropriate traffic model that has the required
blocking capabilities, i.e. either the congested platoon dispersion model (CPDM) or cell

Page 76
transmission model (CTM). A “Flare” traffic stream (or link) is, in essence, something that has
the ability to fill-up with traffic, and block upstream traffic entering it due to its restricted
length.
2. The second method is one which has been traditionally used in TRANSYT, but which has limited
capabilities – This involves the explicit creation of “Quick” flares to model flared approaches.
Using “Quick” flares, provides the mechanism to model the extra capacity available from
flared approaches, i.e. have an extra lane or lanes at the stop line. The non-linear saturation
flow is of the stepped form shown in Figure 4-12. It contrasts with the constant, single
valued, saturation flow for non-flared links or traffic streams.
sat.
flow
0 green time
Figure 4-12 Stepped saturation flow of a simple flare / short lane
For further details on modelling flares see chapter 17. This includes examples of the various cases
where flares are used. The special screens used for data-entry of flare data are shown in section 9.3
and 9.4.

Optimisation Basic Page 77
This is a brief overview of the TRANSYT optimiser. It provides just enough background information
prior to using TRANSYT. Those new to TRANSYT should read it. There are references to other
chapters where needed, to avoid duplication. These chapters will still need to be read in order to
know how to use all the optimisation facilities correctly.
The optimisation process searches for a set of timings for the network which minimise queues and
delays. This is achieved by altering both the signal offsets, which affect the co-ordination between
signals, and the durations of the individual stage green times at each junction (i.e. green splits).
It works by applying a cost to the amount of delays, stops and to a number of specific circumstances,
such as excess queues, on each traffic stream (or link) which is summed to provide an overall cost of
the network for a particular set of timings. These timings are then manipulated bit-by-bit in search
of timings giving a lower overall cost.
Although TRANSYT offers a choice of a number of different optimisation techniques the objective,
described above, is still the same. One of the techniques employed is called ‘hill-climbing’ – because
the set of solutions, if plotted, could be thought of as a series of hills and valleys in a multiple-
dimensional world. The solution found will be at the bottom of one of the valleys. Full details of the
calculation of Performance Index (PI) and the hill-climbing process are explained in chapter 28.
Before optimisation, TRANSYT must have a starting Performance Index calculated from an initial set
of signal timings. A feature called “Auto Redistribute” creates an initial set of stage timings that will
be valid, which can be run to produce the starting Performance Index.
The controller streams which are to be optimised are listed in the advanced item Optimisation
Order. By default, this list is automatically populated with all controllers within the network, but this
can be overruled. If a controller stream is omitted from the list its initial settings will not be altered,
irrespective of any local controller settings.
Thus, a network can be studied in which one or more controller streams within the network do not
have their initial settings altered and act as a constraint on the optimisation of the remaining
controller streams.
Alternatively, within the controller data ((Outline: Controller Stream n > Optimisation) both offset
and green split optimisation can be disallowed. Therefore, the green times can be ‘locked’ while still
allowing the offset (start of stage 1) to be optimised for that controller. This will usually be the easiest
place to set such constraints on the optimiser, (see section 28.3 for more detail).
Furthermore, optimisation can be switched off entirely so that TRANSYT can simply run an existing
set of timings in order to evaluate the performance of the network for these timings. A main menu
“Eval Run” button is provided for this purpose in addition to the “Full Run” (optimisation) button.

Page 78
Cycle time is not automatically considered by the signal optimiser, but TRANSYT’s “Cycle Time
Optimiser” tool, can be used to evaluate a range of cycle times, from which the optimum can be
selected. The operation of, and output from the Cycle Time Optimiser is described in section 28.11
which also discusses issues related to the choice of cycle time.

Simulation Model Page 79
TRANSYT includes the ability to model single junctions, and small to medium sized network networks
using a simulation technique. This complements, and in some cases replaces, the ‘core’ macroscopic
TRANSYT models. This mode is fully described in Chapter 23. Unless otherwise stated, everything
else in this User Guide refers to the core models.
The table below summarises the main differences between Simulation and the core models:
Core Macroscopic Model Simulation
Underlying principle Uses analytical methods Uses simulation
Speed Fast Slower
Optimisation of signals Yes Not yet
Results identical every time Results vary slightly due to

Repeatability
(for same starting data) stochastic nature of simulation
Based on longstanding
Source TRANSYT model (using time- Developed more recently
dependant queueing)
Can additionally model stages

Limited to modelling a that come in every nth cycle or
Scope
repeating signal cycles randomly, i.e. models demand
dependant situations
Modelling using Cell Blocking back can be modelled

Modelling blocking back effects?
Transmission Model for a wider range of scenarios
Superior animations of
Network diagram shows
individual queueing and
Visualisations various animations in 2D and
approximate location of
3D
moving traffic

Page 80

The TRANSYT user interface contains many screens, many of which can be displayed at the same
time and also interact with each other. Altering a value on one screen will if necessary update
relevant values on other screens.
If the file contains no errors, it can run at any time, and the results automatically updated. With
auto-run mode turned on, the results will automatically update as input values are changed – These
runs are evaluation runs only, i.e. using the current signal timings.
There are a few cases where a screen must be explicitly 'exited from' before changes are saved, e.g.
options > preferences screens. In addition some screens have a ‘bulk edit mode where you can work
with the data in the screen in isolation to the rest of the data, for speed and convenience.
In general, you can show multiple instances of the same screen – for example you can show several
Intergreen Matrix screens, each showing the data for a different controller stream. See Padlock
System (section 7.11).
At any time there is one active item, such as a traffic stream or OD location. The current item is
highlighted in the data outline and other screens. If the data editor or Data Grid is visible, then the
properties for the current item will be displayed and should be editable. The data outline can be
used to add/delete items as well as to navigate around the data.
Double-clicking on an item will often bring up an appropriate screen, while right-clicking will often
display a context-sensitive list of menu items.
Most items are accessible from more than one place, e.g. via special dedicated screens access from
the vertical toolbar, or via the data editor.
Note that TRANSYT does not use a separate output file - the results are saved within the input file,
and the date/time of the run also recorded. Detailed animation data and some graph data are not
stored in the file, but this can be regenerated whenever an Evaluation run is carried out.
When a HTML report is generated, the report is saved to a default location and from there it can be
archived if needed. Optionally it can be converted within TRANSYT to either a Word or PDF file. The
generated PDF files are fully paginated.
The whole of this User Guide is available from within TRANSYT as an electronic document. To access
this help file, use the Help menu, or, press F1 at any time.

Page 82
If you cannot find an answer to your question, check the TRL software website first for knowledge-
based articles, latest news items, or contact us directly at TRL.
A program such as TRANSYT inevitably has to use colours such as red and green to represent
different signal states. In recognition of the fact that you may prefer to use a different colour
scheme, and to make black and white printing more flexible, most of the colours used in TRANSYT
can be customised via the user Preferences screen. Select File>Preferences, and then adjust the
options in the Colours section.
A number of network diagram colours can also be changed via the network diagram options screen.
TRANSYT may be provided to you in a demonstration mode. In this mode, most of the functionality
of the program is present but there are a number of restrictions in place: for example, you cannot
save files, optimise timings or print anything. You can make changes to the file, e.g. manually edit
the signal timings, add or delete items from the network, but some of the key data is randomised, so
that the results are of no commercial value. The results themselves will be consistent with the
randomised data used such that, for example, the animations you see in Simulation mode will match
the results seen elsewhere in the program. This allows you to try out and observe the extensive
capabilities of TRANSYT.
To remove the above restrictions, you must upgrade to the full version of the software.
If you have obtained an evaluation version of the software, it will run unrestricted for a specified
number of days, and then revert to demo mode. You must then purchase the full version if you wish
to continue to have full functionality.

The current security status of the program is shown in the splash screen, which is available from
within the program by selecting Help > About.
TRANSYT has a considerable number of inputs, outputs, options and features, so it is important that
you only see what you need to see to keep the program as simple to use as possible. At the
application level, TRANSYT offers control over these using the Advanced Mode option (see section
Advanced Mode 7.5.1).
Furthermore, there are features and data items that you may not be interested in, for the file you
are working on. Therefore, a file-based solution is provided under Data Outline / Options called
“Model and Results”. See section 7.5.2.
Finally, the data outline will hide certain sections if items relating to it are not already present in the
data file. If you wish to see a full list of data outline items for all your files, you can set the File
Preference “Exhaustive Data Outline” to true.
7.5.1 Advanced Mode

In order to make it easier for those unfamiliar with this version of TRANSYT an “Advanced Mode”
mode of operation (Main Menu>Data>Use Advanced Mode) is provided. While “Advanced Mode” is
‘off’ a number of features and output results are hidden, making it easier to get to grips with
TRANSYT.
It is recommended that anyone totally unfamiliar with TRANSYT should leave this mode switched off
while they learn the basic operation of TRANSYT, i.e. work in “Basic Mode”.
Some input values that are hidden when not in “Advanced Mode” are still used by
TRANSYT. In order to prevent these values being changed while in Advanced Mode
and subsequently hidden in Basic Mode, which clearly would be dangerous,
TRANSYT prevents advanced files from being set back to Basic Mode.
When merging either a user file or library file into your network, if it contains
advanced features, TRANSYT will change your network to advanced mode prior to
merging. You will be given the option of cancelling the operation if you do not wish
this to happen.

Page 84
7.5.2 Model and Result Options

Either use the Data Outline to navigate to Options > “Model and Results” or access this same data
using the main menu item “Data > Model and Results options…”
The Model and Results options consist of a list of individual features or data items, most of which
will be switched off by default. This helps significantly in keeping the graphical interface free of
items you do not need nor want see within your network file.
It is recommended that when creating a new network, you simply scan the list of items and only
switch on those you wish to use or see in your file. Unlike Advanced/Basic Mode, You can go back
and switch off or on any these items at any time. If an item is not selected it will not appear in any
of the data entry screens or in any of the results screens. However, these ‘hidden items’ can still be
found using the Data Field Finder (see section 8.8)
Normally you should not experience any problems with the general speed and responsiveness of the
GUI but sometimes with large files you may notice a general slowdown. In this case, note the
following:
 Some windows (e.g. Data Grids) have a Bulk Edit mode: in this mode, the rest of the
application is suspended until you click a Done or OK button. Use this mode if you need to
edit a large amount of data in one go.
 Switching on Fast Mode (Main Menu>Data>Fast Mode) will speed up the responsiveness of
the overall user interface, but at the expense of some features. When on, TRANSYT will not
save any UNDO points (which take time), nor will validation checks on the data be carried out
each time a change is made. However, when the file is run (and also before other key
actions) validation checks will still be carried out to ensure the integrity of the results. While
in FAST mode undo points can also be saved manually whenever you want using the main
toolbar’s Store button. An undo point is automatically saved when you initially switch on
Fast Mode.
 The background of the task list button on the main menu will change to cyan as a reminder
that the task list will not update while in this FAST mode.
 Switching off the option “Generate PDM Profile Data” (Outline: Network Options > Traffic
Options > Advanced) stops TRANSYT storing large amounts of cyclic flow data each time the
file is run. You should notice that evaluation runs will be quicker. However, while in this
mode, you will not be able to view any cyclic flow data, i.e. graphs or diagram animations.
 If Auto-Run is turned on (i.e. yellow), the file will carry out an evaluation run every time you
make a change. Turn it off to make changes before manually re-running the file.
 Close the Data Outline and Data Editor if you are not using them.

 If you have lots of windows open, they will often update themselves. Try closing down any
unnecessary windows, or display one window at a time.
 If memory usage becomes a problem (e.g. “unable to allocate sufficient storage” message
occurs) then the user preference “Number of UNDO points” can be reduced.) This reduces
the amount of memory required significantly.
 If using 3-D models within the 3-D Network Diagram, hide the 3-D models until you need to
display them. There is an option to do this.
 If you have a lot of large background images within the network these can slow navigating
around the diagram, so temporarily hide these using a “Background” option.
See also section 7.8.1 on model run times.
7.7.1 Horizontal toolbar
From left to right, the buttons on the horizontal toolbar are:
Icon User guide reference
New File
Open File Managing files
Save File
Copy to clipboard
Clipboard
Paste
Print
Printing
Print Preview
Undo
Undo and redo
Redo
Store (hidden) Fast Mode
Show Data Outline Data outline
Show Data Editor
(Right-click converts current Data editor
data grid into a Data Editor)
Show Data Grid
(Right-click converts current Data grids
data editor into a Data Grid)
Show Task List Task list (Errors and Warnings)

Page 86
Show Audit Trail Audit Trail

Show Windows Manager Windows Manager
Back
Changing the active data item
Forwards
Sync Synchronise data grids
Previous
Changing the active data item
Next
Toggle Auto-Run
Eval (Evaluation) Run
(Includes dropdown to run all
data sets) Running files
Full (Optimised) Run
(Includes dropdown to run all
data sets)
Configure Report Configure Reports
Generate Report Reports
7.7.2 Main Menu

The options within the main menu (File, Edit, Go To, Data, Run, Tools, Windows, Help) duplicate
some of the buttons on the main horizontal and vertical toolbars, and are self-explanatory.
However, a number of TRANSYT features are only available from the menus, such as
importing/exporting options, and the various items under the “Tools” menu.
The Go To menu options, allow you to go straight to a specific item within your network if you know
its ID. If there is none of a particular item its menu option will be hidden. Your Go To request will be
ignored if no screens are open at the time.

7.7.3 Vertical toolbar

From top to bottom, the buttons on the vertical toolbar are:
Icon
Open a new Network Diagram (Schematic) window
Open a new main (common) data screen
Open a new Local OD Matrix screen
Open a new traffic stream data screen
Open a new link data screen
Open a new pedestrian crossing data screen
Open a new controller stream data screen
Open a new intergreen matrix screen
Open a new stage sequence screen
Open a new timings diagram
Switch to Simulation Mode
Open a new flow graph (includes cyclic flow profiles)
Open a new spatial flow graph
Open various summary results
Show the Summary Results screen

Page 88
The following horizontal toolbar buttons and main menu options are used to initiate a run of
TRANSYT:
Click this run button (or press F5) to carry out a run of TRANSYT based on the
optimisation level and optimisation options you have set. The analysis program is run
using the current data file and the corresponding results are displayed.
Click this evaluation run button to carry out a run of TRANSYT using the existing signal
timings. I.e. no optimisation or redistribution of signal timings is carried out.
To run all the analysis sets in one go, you can

select the drop-down menu on either button.
Click this auto-run button to toggle the Auto-Run feature off and on. When Auto-Run is
turned on, TRANSYT will carry out an evaluation run and screens will automatically
update to reflect the latest changes to any part of the data. This ensures the results
always match the current signal timings. The button turns yellow to alert you when it is
on.
Run times in TRANSYT are heavily dependent on the size of the network and the choice
of traffic models used. We recommend leaving Auto-Run switched off unless working
with a network with short evaluation run times. You may also want to turn off Auto-Run
when you want the results screens to stay static.
7.8.1 Run Times

The time taken to run a file depends greatly on the size and complexity of the network, the chosen
optimisation options and the traffic models you are using. Run times also increase with the number
of time-steps and the number of time segments.
If using a PC with reasonable specifications, most networks using a PDM model should run in a few
seconds and “Auto-Run” can be used without any problems for small to medium-sized networks. If
there are a large number of lanes, links or controller streams, run-times can increase to noticeable
levels, and it is advisable to turn Auto-Run off. We also recommend leaving Auto-Run switched off
when using the Cell Transmission (CTM) traffic model, since this is significantly slower than the
platoon dispersion model (PDM).
Use the PDM to model links and traffic streams that cause no blocking back problems. Only use
CTM when blocking needs to be modelled, e.g. if you need to model blocking effects, say, as part of

a base model. Remember that good use of weighting factors and queue limits, etc. can often
remove blocking problems, and hence remove the need to model blocking in the first place, and
hence the need to use CTM.
If you intend to model a particularly large network, it is well worth considering if you can forgo the
use of CTM (i.e. do not need to model blocking effects) and also avoid the use of the “flare” model -
using “Quick flares” instead to model flares. If so, we recommend you switch the traffic model to
“link-by-link PDM”. This is considerably faster and will still giving good results.
At the bottom right of the main screen you will see the numbers of each network component. The
number of path segments represents the underling hidden ‘link’ structure generated by TRANSYT
when using traffic streams. You can reduce the number of these significantly by cutting down on
the number of active OD paths. If for example, a path has a tiny proportion of the traffic taking a
particular OD movement, disabling this path may make little difference to the accuracy of your
model but will reduce the size of the underlying network. The OD matrix option “Limit Paths by
Flow ”will do this for you automatically, based on the flow threshold you set.
There are also a number of other OD matrix options that will filter out unnecessary/unrealistic paths
– These can be used very effectively to reduce the size of the underlying network, and hence can be
used to increase run speeds.
When set the global option “exclude pedestrians from traffic model” will stop pedestrian crossings
throughout the network from being modelled. This will speed up model run times slightly,
particularly if you have a lot of crossings.
The status bar at the bottom of the main screen shows what TRANSYT is doing at any time.
See also section 7.6 on speeding up the user interface for very large files.
See also section 25.5 on running multiple files, i.e. ‘batch running’
The Undo and Redo buttons on the main toolbar allow you to step back through recent changes, and
then re-do these changes if necessary. Each click of the Undo button will go back one step in the
'history' of the file, and will automatically update all open windows and re-run the file if necessary.
Use the Undo/Redo button drop-down menus to show a list of recent changes and to jump straight
to a particular change. The latest change will be the top item.
For more complex, intentional changes (when you wish to compare one version of a network to
another), consider using the File>Copy Into New File option (see section 7.14.4).

Page 90
The Undo/Redo buttons are also very useful for studying the effect of a change to a data item,
especially when the auto-run option is switched on. For example you can run a file, display the
Summary Results screen’ adjust a data item field; and flick back and forth between the before and
after results via the Undo/Redo buttons.
Also see section 7.18 on user preferences regarding reducing the number of Undo points to reduce
the memory requirements of TRANSYT.
The Active Data Item is the data item that is currently selected and highlighted in the Data Outline
(and other screens) and will have its data fields displayed in the Data Editor. The Active Data Item
may be, for example, Traffic Stream 10 or Controller Stream 7. It may also be a specific type of data
such as Traffic Stream 10: Modelling, or a general network wide item such as Network Options. See
section 31.1 for more details.
There in several ways to set the Active Data Item:
 Click on the item in the Data Outline (8.3)
 Selecting an item via the Go To menu on the main toolbar
 Click on a row header in a Data Grid (see section 10)
 Click or double-click on the item in the network diagram
 Click or double-click on the item in any other appropriate screen, such as the Timings
Diagram
 Click on other 'shortcuts', which appear on some screens as hyperlinks.
In some cases you need to double click the item; double clicking can also be used to show the Data
Editor or other properties for the item.
In addition, you can use the following toolbar buttons:
Use the Back/Forwards buttons on the main toolbar.
These remember a history of 'visited' data items in a similar way to a web browser. The Back button
will set the Active Data Item to its previous item, and similarly for the Forwards button. These are
useful when the data item you were looking at changed because you clicked on a different item
elsewhere and you then wish to quickly go back to the original item.

Use the Next/Previous buttons on the main toolbar.
These move the Active Data Item to the next/previous data item that is of the same type as the
current data item. E.g., when on Traffic Stream 1: Modelling, the Next button will move to Traffic
Stream 2: Modelling, and so on. This allows you to quickly move between all items of the same type
without having to find them in the Data Outline. The use of Data Grids is generally a more
convenient way of viewing the data of several items at once.
Many screens automatically update themselves so that they always show data for the Active Data
Item, where appropriate.
If you want to prevent such screens from automatically updating, you can lock them to the item that
they are currently displaying. Do this by clicking on the padlock icon shown in the top-left corner to
toggle between locked and unlocked modes.
Some screens (in particular, the Data Editor and Data Grid) have a special padlock that cycles
through four modes as you click on it:
1. Normal mode: the screen updates as usual whenever you click on an item in the Data Outline
(or Network Diagram or any other appropriate screen). Sometimes this may be
inconvenient, in which case use one of the modes below.
2. Lock to type of item mode. The screen stays fixed to the current type of item (for example
Phase A data), but will update to show e.g. Phase A data for Controller stream 1, 2, 3, etc. as
you select different controller streams. You don’t need to click on Phase A for each
controller stream in the Data Outline: clicking on any part of a controller stream, or any
controller stream in the Network Diagram, is sufficient.
With Data Grids, this mode locks the rows in the grid to the currently selected type of row
and/or filter, but does not prevent the rows themselves from updating. For example, if you
show a data grid of Phase A data and then use this locking mode, then the data grid will only
ever show Phase A data, whatever you click on in the Data Editor.

Page 92
3. Lock to specific items mode. The screen stays fixed to the current item, no matter where
you click in the Data Outline. E.g. it shows Phase A data for Controller Stream 1, and will not
show data for Controller Stream 2 or Controller Stream 3 until you unlock it.
With Data Grids, this mode locks the specific rows in the grid.
4. Lock entire screen. In this mode all the data on the screen freezes and becomes read-only
and will stay fixed even if you change the file. In this way you can compare data in several
screens without having to worry about the data changing when you re-run the file.
This can be particularly useful when you are comparing results. For example you can view
the results for one Analysis Set, freeze the screen, then show a second instance of the screen
and select a different Analysis Set; in this way you can view data for several Analysis Sets at
the same time. It is also useful for leaving a frozen version of the screen visible before you
start making changes to the data in another instance of the screen.
Some screens (in particular, Data Grids) have a Bulk Edit button. When pressed, this switches the
screen into a special mode where it becomes the only window in the application that responds to
input. All other windows become inactive and cannot be clicked on.
To exit from this mode and return to the rest of the application, you must press the Done button.

This mode has several purposes:
 To prevent every mouse click or key press from updating other windows in the application.
Particularly with the data grid, you may have a list of numbers which you wish to quickly
enter into the program; using the Bulk Edit mode makes the Data Grid far more responsive
and avoids other screens from updating until you have finished.
 To prevent every mouse click or key press from causing other windows to check data and
potentially show warnings/errors about data inconsistency. In other words, you can work
exclusively with a screen and not worry about checking warnings in the Task List until you
have finished.
Note that when working in this mode, the Undo/Redo buttons apply to the entire set of changes
made between entering and exiting this mode.
 Editable items are shown with a normal white background. There are is a couple of
exceptions to this – the max flow (opposed) and slope coefficient is automatically
overwritten if they are being calculated for you by a priority object.
 Some normally editable items may be disabled and are shown in dark grey with a grey
background. There are several reasons why items may be disabled:
o It may be directly inapplicable
o It may be a data item that is shown for information only and is always calculated by
the program (i.e. never editable).
o It may be because of data entered elsewhere (e.g. if a traffic stream is signal

controlled the option to select whether or not it “Has Saturation Flow” is made read-
only and set to TRUE. OD flows that are part of a composite demand set will be read-
only because their values will come from a combination of other demand sets.

Page 94
o It may be inapplicable because of the current program mode or options set

elsewhere.
 If a data item is a result, i.e., an output from TRANSYT, it is shown (by default) with a light
green background once the traffic model has been run. (This colour can be changed as it is a
File Preference) Before you run the model, or if you subsequently make a change to the
current analysis set data. These items are shown with a red background to indicate that they
are potentially inconsistent with the input data. Please note that changes to the network
diagram can indirectly change the data, resulting in a red background.
 When looking at results, some items may not be applicable – in which case they will either be
hidden from view, or will be blank. This is usually because you are looking at results for the
whole network or for the summary time segment and the particular data item is inapplicable
– e.g. there is a mean max queue (MMQ) for each traffic stream, but not for the entire
network; there is a calculated saturation flow for each traffic stream for each time segment,
but not for the summary time segment. You can check this by showing the Help>Glossary
screen.
 Use Data Outline > Network Options > Traffic options > DoS Threshold (%) to control the
thresholds above which Degree of Saturations are shown in red.
7.13.1 Item IDs

TRANSYT works with many items such as controller streams, arms, lanes, traffic streams, all of which
have a short ID. IDs can contain any mixture of numbers and letters, although there is a maximum
length of 10 characters. You cannot have two items of the same type with the same ID.
You can use very flexible naming conventions, for example using your own set of prefixes/suffixes
when naming traffic streams and links to associate them with particular approaches or controller
streams.
Optionally, you can also enter a longer name and description for most items.
When adding a new traffic stream or other item via the Data Outline or the network diagram, you
can get TRANSYT to automatically assign the ID as the next available number, or get it to prompt you
for an ID each time (see User Preferences). You can subsequently change it.

When you change an item’s ID, any other data that references the original ID will be automatically
updated. For example, if you load an existing file and then decide that Traffic Stream 112 should be
named Traffic Stream X120, you can make the change using the Data Editor: any part of the file that
referred to Traffic Stream 112 (e.g. Traffic Stream sources/upstreams, give-ways, and so on), will
automatically be changed to refer to the new ID, and so the data in the file will remain consistent.
7.13.2 Referencing Traffic Streams, Lanes and Link-shares

Identifying and referring to traffic streams is simple. The presence of a “/” indicates a stream is
being referred to. The format is of the form X/Y. Where X is the Arm ID and the Y is the Traffic
Stream ID. So 7/1 as shown in screenshot is referring to first Traffic Stream on Arm 7. In the
network diagram the traffic streams are drawn in order, with the first traffic stream located nearest
the arm name.
Traffic Stream IDs are not unique, but the combination of arm (which is unique) and traffic stream is.
Links are referred to simply by referring to their ID which is unique within the file. Obviously, link
IDs should not use the “/” character in them otherwise they may be wrongly identified as a traffic
stream instead.
Link-shares are referred to by specifying the major link of the “Link Share”.
7.13.3 Units
TRANSYT expresses some data items in monetary terms. The currency symbol used is arbitrary as
long as all economic input data (monetary value of stops/delays) are entered using the same
currency. The default unit is £ (sterling), but you can change this to any other symbol via Data

Page 96
Outline > Options>Units>cost Units or via Main Menu > Data. A user Preference allows you to set
the default currency unit for all new files.
In the screenshot below, Australia Dollars has been set as the currency unit, and this is reflected in
all input and output screens and reports. (N.B. no currency conversion is carried out; the unit of cost
is purely symbolic.)
TRANSYT also provides several options for the units for speed, distance and fuel consumption items.
Wherever possible, data items in TRANSYT are always shown with their units, to avoid any potential
confusion. Changing these units will automatically update all relevant data items.
Traffic units (input and output) can be changed from “PCU” to “Veh” (short for “vehicle”). The input
and output units are set separately allowing, for example input in vehicles, and output in PCU.
Please see section 14.4.14 for details of how to add new traffic types, and how to define PCU factors
for each traffic type (section 14.4.15).
Flow units can be changed from “per hour” to “per minute” – particularly useful if you wish to
compare TRANSYT to other products that have traditionally presented results in minutes, such as
ARCADY and PICADY.
Input traffic flows are not converted when units are changed – you should always
ensure you set the input units to reflect the flows you have entered.
All unit options are saved as part of the file (as opposed to user Preferences).

7.13.4 Sorting and grouping

Many screens show lists of arms, traffic stream, etc., as do generated reports and as does the Data
Outline itself. You can control the sorting of these lists via the Options>Sorting section of the Data
Outline (or via Main Menu > Data > Sorting…).
Note that the Data Grid screen also lets you sort by any column simply by clicking on the column
header.
To see the effect of these different sorting options, show a Data Grid of links, lock it, and then try
each sorting option using the Data Editor. You will also see the order of traffic streams, links,
controller streams and collections in the Data Outline change.
The Ignore Prefixes When Sorting option can be useful if using a naming convention. For example if
you have named priority nodes with a “P” prefix, the default sorting may list nodes in your file as
follows:
Turning on the Ignore Prefixes When Sorting option would change the order to the below:
Returning to normal mode but then changing Sorting Type to Alphabetical instead of Numerical
would change the order to the below (Stream 11 now comes before Stream 2)

Page 98
Note that all sorting options are saved as part of the file (as opposed to user preferences). You will
therefore see the same sorting of controller streams/traffic streams/links/collections and routes
every time you load the file.
7.13.5 Simulation Options

You can control the simulation process via the Options>Simulation options section of the Data
Outline. See section 23.13 for description of these options.
TRANSYT 15.5 saves data in files with a .T15 extension.
Output can be saved permanently in the form of Reports, which are generated by the Report
Generator. Reports are produced in the form of HTML documents for viewing within the viewer
built into TRANSYT and can also be converted to Word and PDF documents.
Files can be created, opened and saved via the standard New, Open, Save and Save As options in the
File menu. You can also open or import a file by dragging and dropping from Windows Explorer into
the main TRANSYT screen.
Several files can be open at once. The names of any open files are shown in buttons in the blue bar
at the bottom of the screen. To switch between files, click on the appropriate button.
The ability to open and view several files in this way is invaluable when comparing different versions
of the file, for example to study the effect of a small alteration to the junction. Alternatively
Tools>Compare Files or Data Sets can be used.
TRANSYT files can also be saved as Library Files, which can then be easily merged into networks from
within the network diagram or using the Merge Network facility. See section 25.3 for details on this.
To close a file, use the File>Close menu option, or right-click on file in the file selector bar. To close
all open files use the File>Close All files menu option.

7.14.1 Importing from older versions and from different products

TRANSYT 16 can import data from TRANSYT 15.5, TRANSYT 15, TRANSYT 14, TRANSYT 13, TRANSYT
12, TRANSYT 11 and TRANSYT 10 by simply using the standard File > Open menu or the Open icon
and selecting the relevant file extension from the bottom right-hand corner of the “Open” dialog
box.
TRANSYT file extensions are as follows:
“filename.T15”, “.T14” and “.T13” for TRANSYT 15.5, 15, 14, and 13 respectively.
“filename.DAT” for TRANSYT 12 and earlier.
See Chapter 34 for full details.
TRANSYT will also import data from a number of third party products such as TRANED 2, TRANSYT-
7F, LinSig 3 RTF files, SCOOT and SCATS. See the following Appendices and sections for more
information.
Import from TRANSYT 7-SET/10/11/12
Import from TRANSYT-7F
Appendix D – Import SCOOT data
Appendix E – Import SCATS data
Import LinSig report data
7.14.2 Files generated with different releases of TRANSYT 16
If a TRANSYT 16 file that is opened has been generated with a different release of TRANSYT to the
one currently being used, a message reports this. If the changes are substantial an option to
examine a report detailing the differences is also provided. This information may be of interest to
some users when they wish to know what kinds of changes are taking place, e.g. new data items
being created and old ones removed or changed.

Page 100
7.14.3 Exporting data to earlier TRANSYT releases

There is no facility to export a TRANSYT 15.5 file back to the file formats of earlier versions of
TRANSYT, including releases of TRANSYT 15 prior to TRANSYT 15.5. Because of this, we recommend
that anyone using TRANSYT 15 prior to TRANSYT 15.5 should update to the latest version of
TRANSYT 15 as soon as possible.
7.14.4 Duplicating a file

When a file is open, you can create a duplicate copy of the file that you can then make adjustments
to and compare to the original. To do this, use the File>Copy Into New File option. A new file will be
created, containing a copy of all data. The new file is not saved to disk until you use File>Save As.
This feature is very useful when you are trying various 'what if…?' and wish to avoid having to
manually save the file under many different names.
It is also possible to compare multiple files - see section 21.4.
7.14.5 Saving files without results

Occasionally you may find that the size of the saved file is very large. This can be due to large
amounts of results data being present in the file. For example, for some files, a full set of results
data will be stored for each traffic stream, for each collection, for each underlying path segment, for
each time step, for each time segment, and so on. In such cases you may wish to save the file via
File>Export>Save without results. This will strip out some results data before saving the file, leading
to a smaller file size. You will of course need to carry out an evaluation run of the file to re-populate
the file with the missing results when you subsequently load the file.
7.14.6 Opening a file's containing folder

Click on the File>Open Containing Folder to open the folder where the file is located in Windows
Explorer.
7.14.7 Saving results from TRANSYT runs

When you save a file, you save all the input data. If any of the analysis sets in the file have been run,
you will also save these results in the same file. When you next open this file in TRANSYT, you will
be able to jump straight to the results without having to re-run the traffic model.
The results of all previously run analysis sets are stored in the data file.
When you run a file, TRANSYT also produces a large quantity of data that is used to generate graphs
and animations. This data is not stored with the file, so an un-optimised run of any newly opened
files will be required to show this information.
If you wish to send a file to a client or colleague so that they can see your results, simply send them
your saved TRANSYT file. If they wish to see the animations they will need to carry out an evaluation
run of TRANSYT for each analysis set, to generate the required data. They will require either the

demonstration version of TRANSYT 16, or a registered OR unregistered version of the full product –
if a demo or unregistered version is used, the file can still be loaded, viewed, animated and run with
the current (un-editable) data. A demo version of TRANSYT 16 can be downloaded from
www.trlsoftware.co.uk.
Use this method when wishing to copy a complete grid of data:
The Copy button on the main toolbar will, where appropriate, copy data from the
currently active screen (the screen last clicked on) to the Windows clipboard. The data
can then be pasted into a word processor, spreadsheet etc. (Some screens also have
their own Copy buttons for specific purposes, or you can right-click in individual
windows/screens.)
The format of the data depends on the screen but columns and rows are generally separated by tabs
and new lines. In some cases, the Paste Special option in the word processor/spreadsheet can be
used to select between options of pasting text or a picture.
The Paste button will, in many cases, copy data from the clipboard into the currently
selected screen. This relies on the data being in the expected format for the screen;
the easiest way to determine the format is to press the Copy button on the same
screen and paste the contents into a spreadsheet or similar. Altering the data in the
spreadsheet and then copying exactly the same area and pasting back into TRANSYT
should then successfully replace the data in TRANSYT with the edited data.
Use this method for copying just parts of a grid of data:
In many cases you can also select a single item or multi-selection of any grid of data and right-click
to choose Copy. Alternatively, a CTRL+C shortcut can be used instead to copy.
Similarly, sections of any grid of data can be pasted back into the program. Pasting using the right
click menu will paste to an area the same size as the data in the clipboard starting at the location of
the right click.
This gives you a lot of freedom to copy and paste data out to a spreadsheet for example, edit it as
required and paste that section of data back in.
The Print and Print Preview buttons on the main toolbar will, where appropriate, print or show a
print preview screen for the currently active screen (the screen last clicked on). This applies to the
network diagram, the Report Viewer, and also various other screens such as graphs and the Timings
Diagram.
Use File>Print Setup to control the paper size and orientation.

Page 102
There is a standard Window menu on the main toolbar which will show a list of all currently open
windows and allow selection from this list. It also contains a Close All option which will close all
open windows.
You can also store custom window layouts. This allows you to save the layout of all the windows as
they currently appear, and quickly select the same layout the next time you use the program. Click
Window Layouts>Store Current Window Layout to assign a name to the current window layout (i.e.
the position and size of all windows as they currently appear). The layout will then appear in the
menu whenever you use TRANSYT. Layouts are saved as part of your user preferences, not in the
data file.
Layouts take account of the contents of data grids, in terms of which data fields are shown in the
grid and their order. However the actual content will obviously depend on the currently loaded file.
Stored layouts also take account of whether or not each window is inside or outside of the main
window, and also those layouts that make use of two separate monitors.
7.17.1 Window Manager

Use the menu option Window Layouts>Window Manager… option to display the
Window Manager. Alternatively, press the button on the main toolbar.
The Window Manager allows new window layouts to be added, renamed or deleted and also
provides quick access to any of the saved layouts. Double-click on one of the layouts to switch to it.
Any of the saved layouts can also be set as the default layout which will be used whenever you start
the program or start a new file (click Toggle default).
Depending on your version of Junctions, some built-in layouts may be already included. Layouts
may be specific to the version of TRANSYT used to save them.

Layouts can be exchanged with colleagues or other users of TRANSYT. Select the layout(s) that you
wish to share (select in the list with CTRL or SHIFT) and click Export to generate a file containing the
layout definitions. To import such a file, use the “Import layouts” button.
7.17.2 Taking windows out of TRANSYT

If you have dual monitor display you will benefit enormously from this new feature. By double-
clicking on the title bar of any window within TRANSYT, the window will become detached from the
main TRANSYT window and you can position it on the secondary monitor. Those windows that
benefit from being maximised, such as the network diagram, will also have a maximise button near
their top right-hand corner. Uniquely, the Network diagram also has a “Maximise Window” right-
click menu option to allow the diagram to be maximised when it is still within the TRANSYT window.
Double-clicking on the title bar a second time will return the window to inside the main TRANSYT
window.
This new feature gives you a lot more scope to set out your open windows to maximise productivity.
7.17.3 Docking system

A docking system is provided which allow individual windows to be ‘docked’ to the top, bottom, left
or right of the TRANSYT window area. Docked items remain on top at all times and therefore can
offer an alternative way of using the available space within the main TRANSYT window. It is
particularly useful if you have plenty of available window space, such as when using a large monitor
or multiple monitors.
7.17.3.1 How to dock and undock windows

To dock a window right-click on the Windows Title Bar and continue to hold the button down. The
TRANSYT window will be darkened, and you will also see a set of four brightly directional icons - If

Page 104
you move the cursor over one of the icons the screen will darken progressively to a dark blue in the
direction indicated by the icon. This indicates to which edge the docking will take place. Let go of
the mouse button to dock to the highlighted edge.
Having docked a screen this area will not be accessible to any other windows and any item opened
will appear in the remaining unallocated space. For most windows, the size of the docked window
can be changed to suit your preferences.
Multiple windows can be docked to one side of the TRANSYT window. For each docked item a
separate set of directional icons are displayed. This allows undocked items to be docked to any part
of the screen, including to the top, bottom, left or right of already docked items. When there are
already two or more items sharing one side of the main window, the position of the cursor over the
directional arrow determines where amongst the existing windows your window is placed. The
screenshot shows a screen about to be docked to the bottom of the Windows Manager, which,
along with the Data Outline, is already docked to the left-hand-side of the main window.
N.B. the best way to learn how the docking system works in practice is to experiment with it.
To un-dock a window, you simply double-click on its Title Bar. N.B. double-clicking a second time i.e.
after undocking it, will take the window outside of the main window.
Select File>Preferences from the main application menu to access a set of preferences which are
saved as part of your personal preferences (not in data files).

This screen also provides a number of utility options at the bottom-left of the screen. In particular,
click Reset suppressed messages to restore any message boxes where you have previously clicked
‘Do not show this message again’.
Some options are explained in this User Guide in the relevant section, but brief descriptions of
selected items are given below.
To reset all options to factory defaults, press the Defaults button. You can also use File>First time
use wizard to set certain common preferences.
Appearance:
Default Editor and Default Editor in NetCon: Use these two options to change what data-
entry screen is displayed when you double-click in the Data Editor and Network Diagram
(NetCon). You can choose between the data editor, special screen or data grid. Where a
special screen does not exist for the item that is double-clicked, the data editor is displayed
instead. This option allows you to favour your preferred method of data-entry.
Exhaustive Data Outline: When false, the data outline will not display the parent entry for
items that do not already exist in the current network. When true, it allows you to add such
items via the data editor.
Use rotated data grids by default: Self-explanatory
Window Font Scheme: Select from either “Medium” or “Small”. This allows you select a text
size that matches the size of your display and your personal requirements.

Page 106
General:
Audit Trail: Log everything for new files: The equivalent of this option is saved with the file,
but this allows the Audit Trail to be switched on by default for new files.
Audit Trail: Prompt to save for new files: The equivalent of this option is saved with the file,
but this allows, for new files, you will be prompted to save a status entry each time a file is
saved.
Library File folder path: Use this option to change the location where TRANSYT expects to
find the Library Files. This option could be used, say, to choose a central location for
company-approved Library Files.
Number of Undo points: Use this option to set the number of undo points. These allow you
to reverse changes you make to your file. Each undo point uses up memory so if you are
modelling very large networks and start to experience any memory shortage issues then
reducing this number (all the way to zero if necessary) is a very effective in reducing the
memory requirements of TRANSYT.
Use Advanced Mode by default for new files: Set this option to force all new files and
Library Files to start off in Advanced Mode. N.B. Library files will start off in Basic Mode only
if they have been originally saved as Basic Library files.
Localisation:
Cost Unit for new files: This allows you start new files with a cost unit other than the default
UK pound (£).
Default driving side: Use this option to set which driving side of the road you wish use for
new files. TRANSYT files can also be switched at any time using the “Mirror File” tool.
Phase/Stage Display Names: The UK terminology used to refer to stages and phases is not
used globally, e.g. common alternatives are to use “phase” to refer to a “UK stage” and
“Signal group” to refer to a “UK phase”. Use this option to choose one of the alternative
terminologies.
Please note that although most of the relevant labels within the GUI will change as soon as
you switch to a different set of Phase/Stage display names, you must close TRANSYT and
reopen it to fully complete the change.
SCATS split time: Use this option if you wish TRANSYT to display Australian stage split
percentages (i.e. percentage of the cycle time taken up each stage. The split (%) times are
reported in the “Resultant Stages” table. Please note that the split times can also directly
editable. Changes to the split percentages will indirectly change the stage duration and stage
end times. The Timings Wheels will also show split times as a percentage if this option is
selected.
US Terminology: If true, certain terms are replaced with American equivalents, e.g. “Arms”
becomes “Legs”.

Use triangular PDM option and defaults: This option determines if the triangular PDM
option is set for new files and library files. This file option can be found in the Traffic Options
section of the Data Outline.
Reports:
Font Size for reports: Select from either “Medium” or “Small”. This allows you select a
report text size that matches your personal requirements.
Import Settings From External Settings File: If set, the user-definable External Settings File is
used instead of the default local user.config file. This allows, say, a read-only preferences file
to be saved to an accessible network location, and hence the same preferences can be
centrally defined for all users within an organisation. See section 7.18.1 on how to transfer
the preferences file, rather than share it.
Reports Location Mode. If this is set to ‘use same location as input file’, then all reports will
be saved to a folder with the same name and location as the main TRANSYT data file.
Otherwise, if ‘use specified folder’ is selected, you can nominate a Reports Folder, which will
be used for all generated reports.
Run all Analysis/Demand Sets: If set, the report option “Show all analysis sets” will be set
automatically for new files.
Junction/Network Diagram:
3D models folder: Select a specific folder in which you keep your collection of 3D models.
This should be the ‘master folder in which each model has its own folder. This is because
each Collada model is made up of multiple files, and as such each should be kept separate
from other models by using its own folder.
No bend points for newly created items: If true, traffic streams and links are added by
simply clicking to set the start and end positions. If false each click adds a bend point, and
right-clicking sets the end position.
Prompt for IDs: If true, TRANSYT will ask for an ID for each newly created item. Otherwise,
they will be automatically set.
Safe Mode: Turn this on if you experience any problems with text rendering in the network
diagram.
Start network diagram Inside Application Window: Turn this on if you wish to have the
network diagram opening in its own Window on a permanent basis. Switching off this option
is useful when using multiple monitors, and you consistently use the network diagram on its
own monitor. This option can also be set within the network diagram on temporary basis.
Colours: Use these options to adjust the default colour scheme for various items.

Page 108
In addition to their use by the Task List, the “Error”, “Warning” and “Good” colours are also
used for various network diagram overlays in order to identify the various levels.
Use phase colours in timing diagram: The colour scheme is as follows:
Green unspecified; traffic, wig-wag
Blue pedestrian
Dark Green indicative arrow; filter
Pink bus; cycle; LRT; tram
Grey dummy
Signals:
Format of Phase ID: Auto-generated phases can be set to produce either Numbers or Letters
Format of Stage ID: Auto-generated stages can be set to produce either Numbers or Letters
Maximum number of auto-generated stages: The maximum number of auto-generated

stages preference can be set higher if you require more stages to be created.
Show TxC values: This preference tells TRANSYT to generate TxC values for each phase,
which are of use with Dutch ‘halfstarre’ applications.
Diagrams:
Depiction of Links on Red: controls how links that are red during a particular stage are
depicted in the Stage Sequence Diagrams.
Flow units for Flow graphs: Selects how the vertical axis of flow profile graphs should be
scaled - PCU/hr or PCU/step. Although the most useful is usually PCU/hr, it is sometimes
preferable to show PCU/step when trying to examine traffic behaviour on a step-by-step
basis over a small time period.
Flow units for Spatial graphs: Either the distance upstream from the stop line (in metres) or
the number of PCUs can be displayed on the y-axis of these graphs. The ability to switch
units is sometimes handy as it allows different graph types to be displayed with the same y-
axis units.
Link Connector Arrow Type: controls how arrow directions are automatically calculated in
the network diagram and also in Stage Sequence diagrams
Timings Diagram preferences: A selection of options that affect what is displayed and what
the diagram looks like can be set here as defaults.

Stage Sequence Diagram preferences: A selection of options that affect what is displayed
and what the diagram looks like can be set here as defaults.
Use Effective Greens in Graphs: this option is also available via the main Graphs button on
the application vertical toolbar. If this is turned off, then actual greens are used.
Aimsun Plug-In: See TRANSYT-Aimsun User Guide for details on this option.
7.18.1 Transferring user preferences

To transfer user settings between two copies of TRANSYT (for example different versions on the
same PC, or between different PCs or users), use the following procedure:
5. Show the Preferences screen

6. Click on the Open Preferences folder link at the bottom of the screen
7. Windows Explorer will open a folder where you will find a .config file. Make a copy of this
file.
8. On the target PC, repeat the above procedure and replace the .config file with the version
copied from the original PC.
Note that the above procedure only applies to settings that are visible in the File>Preferences
screen. All other settings are stored in the individual data files.

Page 110

Data Entry Page 111
TRANSYT 16 saves data as files with a .T16 extension. These data files save everything that can be
viewed and edited in the Data Outline (see 8.3).
TRANSYT does not save a separate output file. Instead, results are embedded in the data file and
saved along with input data. See saving results (section 7.14) for more details.
Please note that a number of input data items are only accessible when TRANSYT’s “Advanced
Mode” is set. See section 7.5 for details. Furthermore, some items can be ‘switch-off’ using the
Main Menu>Data>Model and Results Options list. See section 7.5.2 for details.
Output can be saved permanently in the form of Reports, which are generated by the Report
Generator. Reports are produced in the form of HTML documents, and so can be viewed in any web
browser (and most word processors), as well as the viewer built into TRANSYT and can also be
converted to Word and PDF documents. The generated PDF files are fully paginated.
See 7.14 for more details about file-handling.
Rather than construct junctions from scratch, you can choose to start off a new network with a
library file or merge one into their existing network. A small library of files is supplied with TRANSYT,
which can be supplemented by any files you wish to store as additional library files. TRL supplied
Library files are displayed in blue.

Page 112
Any TRANSYT files can be saved as a Library File (File > Save As Library File), which can be easily
merged into future networks from within the network diagram or using the Merge Network ( Add
Junction) facility. See section 25.3 (Adding a Junction (Merging Networks) for details on this. When
Library files are saved, a snapshot image of the network diagram is stored with the file so that a
preview screen can be provided when selecting the library files.
Once a library file is loaded into TRANSYT it can be edited and run like any other file. Saving the file
will save it as an ordinary TRANSYT file, but it can also be saved as a new user library file if you wish.
The only differences between a Library File and a normal TRANSYT file are that the
Library File contains a preview image AND it is stored in one of two specific Library
Folders – one for TRL-supplied Library Files, and one for your own Library Files.
If you open a Library File directly from one of these special Library Folders (<Install
Folder>TRANSYT 16/LibraryFiles and <Install Folder>TRANSYT 16/UserLibraryFiles)
please note that when you come to save it, any changes will be naturally saved to the
Library File itself. For this reason, only browse to and open files directly from this
folder, if you intend to edit the Library itself. At all other times, use the New File
button, Merge Network option or the network diagram button.
In addition to the ordinary Library Files, some of the pre-supplied Library Files are deemed to be
‘sacrosanct’ and cannot be altered or deleted. These files do not show up in the Library File folder,
but do appear in the Library List.
Data in TRANSYT is organised in a hierarchy, which can be viewed via the 'tree-view' style list in the
Data Outline screen. See section 8.3 for full details of this screen. Although use of the Data Outline
screen is not strictly necessary in order to view and edit files, it presents a summary of the data in
the file and provides a convenient way to access items within the file. At the same time, there are
many short-cuts within the program for rapidly accessing items; for example, a Traffic Stream can be
accessed by simply clicking on it in the network diagram rather than finding and selecting it in the
Data Outline. You can also use the main TRANSYT Go To menus to access certain items.
You can also use the Main Data, Signals Data, Links Data and Streams Data screens to access
commonly used data items.
Data in any part of the Data Outline can be accessed and edited in any order - there is no need to fill
in data in a specific order.
The screenshot below shows the general form of the data structure. Each entry in the tree-view is a
data item, and if the entry is shown in bold, then it has associated data item fields that can be edited
using the Data Editor Screen (8.5).

Data Entry Page 113
The first line in the tree-view shows the filename for the file being edited. (To change this, you need
to use the File>Save As menu option.)
 File Description contains a number of data item fields for describing the file, such as a title, site
(reference) number, job number, driving side, etc.
 Analysis Sets and Demand Sets contain definitions of analysis and demand sets, which allow you
to set up data for e.g. different periods of day, or different signal plans.
 TRANSYT Network contains the bulk of data and defines the network being modelled
 Options contain a number of additional, advanced options, which are saved with the file.
The first screenshot in this section shows the basic hierarchy expanded by one level, and shows that,
for example, TRANSYT Network contains Network Options, Controller Streams, Arms, Priority, and
Local Matrices.

Page 114
The following screenshot shows the hierarchy expanded to a deeper level, and shows the individual
controller Streams within the Controller Streams section, and so on. This list reflects the items that
exist within the chosen file. Other networks will display a number of other items.
To take this screen shot TRANSYT’s ‘Advanced/Detailed data items’ option has been switched on,
revealing the Advanced items such as Analysis Sets and Demand Sets.

Data Entry Page 115
To show/hide the Data Outline, click this button on the main toolbar.
The Data Outline is used to access all data items within the TRANSYT file. Items in bold have
associated data fields that can be edited in the Data Editor (see 8.5).
Clicking any item will show its data or highlight the item in all relevant screens that are currently
open, such as the Data Editor, Data Grids, Junction Diagram etc.
Double-clicking on any item will show the default editor (Data Editor or Data Grid, or special screen
according to the option set in File>Preferences. if it is not already shown.
If the editor is already shown but is locked to another item, then a new instance will be shown.
The Data Outline presents all data within the current TRANSYT file in a 'tree-view' format, where
each item 'belongs' to a parent item.
To navigate around the Data Outline, simply use the + and –

icons to expand and collapse items. When you click on a data
item, it is shown as being selected and also becomes the
TRANSYT Active Data Item. The Active Data Item determines
what is shown in many other TRANSYT screens, such as the Data
Editor screen and Data Grids. Similarly, the Active Data Item
can be set from many other screens, for example, by clicking on
an item in the network diagram. The Active Data Item is set in
this way whether or not the Data Outline itself is visible.
Double-click an item to show the Data Editor (or chosen screen

type) if it is not already shown.
See section 7.10 for more details about the Active Data Item
and how to use to set it using the main toolbar's
back/forwards/up/down buttons.
The Data Outline is also used to add new data items such as
new controller streams and arms, and to remove existing ones.
For example, to add a new arm, firstly select any of the existing
arms (or the Arm item), and then click the Add button. You can
also right-click on any valid item in the Data Outline for similar
options. You can also add/delete items via buttons in various
other screens, including the network diagram.

Page 116
 In some cases, TRANSYT will prevent you from deleting an item if it is the last item in the
group.
 When adding a new item, the new item's data fields are copied from the Active Data Item.
For example, if you select traffic stream 2 and then click Add, then the new traffic stream will
be added to the end of the list and the values of its data fields will be the same as those for
traffic stream 2. This means that you can easily make copies of existing items. To reset data
fields to their default values, simply use the Default values option on the Data Editor.
However, if you select Traffic Streams and then click Add, then a new traffic stream with
default properties will be added.
 If using the Data Outline to add a new Analysis Set or Demand Set, the new set will contain a
copy of all data for the current analysis/demand set.
 The font size used in both the Data Outline and the Data Editor can be changed by setting
File>Preferences>Window Font Scheme
To show/hide the Data Editor, click this button on the main toolbar, or double-click on a data
item.
The Data Editor is used to edit data item fields for the Active
Data Item.
As the Active Data Item is changed (either via the Data

Outline or from other screens such as the network diagram),
the Data Editor changes to show all the data fields for that
item. The top of the Data Outline shows the item that is
being edited – in the screenshot, a traffic stream is being
edited, specifically, Stream 1 on Arm 1.
See section 7.10 for more details about the Active Data Item
and how to use to set it using the main toolbar's
back/forwards/up/down buttons.
Each data field may be a tick-box (e.g. Is Give Way), a text-

box (e.g. Name, Saturation Flow) or a drop-down list (e.g.
Traffic Type). Some fields are set automatically by TRANSYT
and are either greyed out or hidden altogether – This is
because the data requirements vary depending on what
other options are chosen. There is no save button on the
Data Editor; values are saved automatically whenever you make a change, and any other open
screens will automatically update. To save a change, press Enter or Tab or click in any other data
field, or on any other screen. If you make a mistake, use the Undo/Redo buttons on the main
TRANSYT toolbar. Data Editor windows can be left open all the time – there is no need to close
them down after having made changes.

Data Entry Page 117
Clicking on any field will show a textual description of the field at the bottom of the screen, along
with its units, range and default value. Double clicking on any field (the label, not the text box) will
show a glossary screen, which can also be accessed via the main Help menu.
Click the Default values option to set all fields to their defaults.
If Auto-Run is turned on (see section 7.8), then changing any field will cause TRANSYT to carry out an
evaluation run of TRANSYT and refresh the results screens.
The Data Editor can be resized horizontally in order to make the text-boxes longer.
For convenience, right-clicking on the Main Menu “Data Grid” button will convert the currently
selected data editor into a data grid, and similarly right-clicking on the “Data Editor” button will
convert the currently selected data grid into a data editor.
The small icons shown to the right of some data fields are either reminders that the data field is
entered separately for each Analysis Set or Demand Set, or is available separately as a result for
each time segment.
Clicking on this icon also offers the ability to set whether the data is common between sets or not -
See section 13.5 for more detail on this.
The PgUp and PgDn keyboard keys can be used to slowly increment and decrement any currently
selected numerical value within the data editor.
See also: Padlock System (Section 7.11)
The network diagram shows a graphical representation of the network and lets you edit the network
in a graphical way, including the adding, deleting and connecting of controller streams, traffic
streams, pedestrian crossings, etc. It also shows output results, including signal states and
animation of queues and CTM data. See Network Diagram (chapter 11) for full details.
To show the Task List, click the Task List button on the main toolbar.
The Task List shows any warnings or errors in the current file. TRANSYT checks the data file every
time a change is made, and automatically updates the Task List. As soon as you 'fix' a problem, the
Task List will update and the error/warning should disappear. The Task List acts as a central
checklist that at any time shows you what needs to be done in order to run the file.

Page 118
The background colour of the task list button changes colour to indicate the presence of warnings or
errors – amber if there are any warnings; and red if there are any errors.
Note that the Task List shows problems associated with the data file before it is run in the optimiser.
Occasionally, errors may only come to light when you try to run the file, and these will be shown as
message boxes.
The Severity column displays either 'Warning', 'Error' or 'Info'. Errors prevent the file from running,
whereas warnings serve as reminders that you may want to double check something, but will not
prevent runs. Info items are simply for confirmation purposes. The Area, Item and Problem
columns indicate the exact nature of the problem. In most cases, double clicking in the row will
open the appropriate screen (or item in the Data Outline) where you can fix the problem.
By default, all three types of item are shown, but you hide items by toggling the three buttons at the
top of the screen items.
Clicking in any column in the header row will sort the grid by that column.
If the grid is too small to show the full text of a problem, then either resize the grid or else click on
the row and then hover over it to show the full text. (Alternatively, generate a report, since the Task
List items are shown at the top of the report.)
Select the Data Field finder from the Help menu or by pressing F3 at any time.
The Data Field Finder acts as a simple index to all data items in the program. It is useful when you
are not sure where a particular data item is located in the Data Outline. Enter a word or phrase to
search for and any data items that contain the word will be listed. Select an item from the list and
then double click the row or click Go to selected item to jump to the first occurrence of that item in
the Data Outline. Note that it is only the names of items that are searched for, not the actual values
of the data items.
As an example, if you have forgotten how to set the driving side (left/right), you can enter "Driving
Side" here to reveal that the driving side is located in the File Description part of the Data Outline.

Data Entry Page 119
Select Show hidden items option to reveal any items that are currently hidden. Hidden items can be
hidden from view in the GUI either because they are an Advanced item and the file is in Basic Mode,
or because none of that particular item is present in the data file, or a “Model and Results” Option is
set to hide it. The Description indicates why it is hidden.
Clicking Search help file will open the application User Guide and perform an automatic search, so
that you can search for further information on any topic.
To search the help file for a phrase (as opposed to a single word), use the search system
built into the help file, i.e. press F1 from anywhere in TRANSYT to show the help file, then use the
help file's search system.
In common with the rest of TRANSYT, bold items have associated data fields, and light green items
are results as opposed to input data items.

Page 120

Special data-entry screens Page 121
A series of screens each dedicated to a specific set of data are available. These screens can be used
as an alternative to the Data Outline and Data Editor. You may, in fact, prefer them as each of them
includes a number of convenient links and buttons that access related tools. These screens are
accessed via the main vertical toolbar button.
The data on these screens works in exactly the same way as the Data Editor, can be left visible, and
also synchronise with other TRANSYT screens. You can also lock the screen to a particular item.
The following dedicated screens are available:
 Main (common) data

 Controller stream (Signals) Data
 Traffic Streams Data
 Links Data
 (Pedestrian) Crossings Data
 Fuel Consumption - Accessed from a “Data” option on the Main Menu.
There are two user preferences that allow you change which editor screen is displayed
when you double-click either within Netcon (File>Preferences>1. Default Editor in NetCon) or in the
Data Outline (File>Preferences>1. Default Editor). In this way you can select which screens you
would prefer to use, including a mix of the two – You may find the Data Editor which is compact, is
better if you are using a small monitor, and the dedicated screens, which are wider, will be ideal if
using larger or multiple screens. There is also the option of defaulting to a data grid.
This screen allows access to data that is common to the whole network. Commonly used data
appears on the default visible tab (Main Data) and the rest split between the remaining tabs.
A number of blue hyperlinks are used to ensure access to all the remaining common data, without
having to use the data outline.

Page 122
The triangular PDM option is only available when either the related user preference is TRUE, or the
file option is already TRUE.
Network Summary results are given for the complete network and also separated into vehicular and
pedestrian results. Further results can be accessed using the “Results” button drop-down options
on the vertical toolbar.

The controller Streams Screen provides access to controller streams and their phases, stage libraries,
phase delays and stage sequences. These and other network objects can be added, deleted and
modified from here. Select the controller stream to view using the permanently visible list on the
left hand side, or via the Data Outline, or network diagram.
Apart from the Controller Stream Tab, the data within each tab is shown in form of a data grid.
These data grids work in exactly the same as any other Data Grid.
Some of the tabs have additional buttons which carry out useful actions such as “Create New
Phases…” and “Auto Generate Library Stages”.
Details of how this screen fits into the overall data-entry process for traffic signal data is given in
section 9.2.7, while a full description of the contents of each tab is given here in the following
sections:

Page 124
9.2.1 Controller Stream

The Controller stream tab shows the basic controller stream data such as its ID, name and
description. From this tab you can also change controller-specific optimisation options.
When changing the optimisation option, such as switching off “Allow Green Split
Optimisation”. This affects only this particular controller stream. The reported “optimisation level”
reports the combined effect of the controller-specific settings and the network-wide (common)
settings are, e.g. if at the network level the optimisation is set to “offsets only” then this will be
reflected in the optimisation level shown here. For the situation described, the disallowing of green
split optimisation will have no effect as it is, in effect, banned already.
Cycle time options are also accessed from this tab. By default, the cycle time used by the controller
stream will be “NetworkDefault” which is whatever the network-wide value is (Outline: Network
options > Network timings.) For convenience the cycle time used is reported on this tab. Change
the “Cycle Time Source” to “Manual” to set its own cycle time, or alternatively set it to “Controller
Stream” in order to reference another controller, from which it will get its cycle time from. In this
way you can set up multiple sub-networks each running on a single cycle time.
The two additional buttons provided offer advanced optimisation capabilities:
“Generate optimal sequence”: Use this option when you wish TRANSYT to provide you with an
optimal (isolated) set of timings (i.e. phase optimisation).
When using this option, there is no need to define stages, stage sequences and phase
delays as all of these are calculated for you. Any existing data will be replaced.
Pedestrian flows are not taken account of during phase optimisation. Suitable phase
minimums and maximums can be set to influence the results for phases controlling
pedestrian crossings.
Since the optimisation is based on the junction performance in isolation to the rest of
the network, no blocking back effects will be taken account of.
Having obtained this solution, a run of TRANSYT will then provide a good solution within the context
of the wider network, in terms of optimised green splits and offsets.
“Run Phase Optimiser with current sequence”: Use this option if you wish to use your own stage
sequence, but wish to optimise the phase lengths associated with this particular sequence. Phase
delays will be automatically added or removed in order to optimise the timings. Having obtained a
solution, a run of TRANSYT will then provide a good solution within the context of the wider
network, in terms of optimised green splits and offsets.

9.2.2 Phases
The Phases tab shows a grid of each Phase for the current controller stream. By default the
controller stream will be populated with two phases – A and B. To add or remove phases use the
two buttons provided. Alternatively you can right-click on a column-header of either of the phases.
The pop-up menu offers the options to either delete the phase you are on, add a copy of it, or add a
new phase.
You can change the phase properties, such as street minimum green time, maximum green time,
relative start displacement, relative end displacement, by clicking on individual grid items.
The phase type can be left as “not specified” or set to the most relevant type. Generally, the phase
type does not affect model behaviour. However, some phase types allow extra phase data to be
specified, such as a blackout period for “pedestrian phases” and amber times for “traffic” phases.
Blackout times affect the model, while amber times only do so if clearance times are being used to
calculate intergreens.
Phase types also allow you to more easily identify what the phase is for, or what it is controlling.
Different phase types are shown in different colours in the Timing Diagram if the user preference
“Use phase colours in timings diagram” is selected. Additionally, some warning messages depend
on the use of the phase, e.g. if a “pedestrian” phase is set to control vehicular traffic a warning will
be displayed in the task list.
For pedestrian phases a blackout time can be specified.
After setting the number of phases you will often want to set up the conflicts between phases. The
“Intergreen Matrix” button conveniently opens the intergreen matrix screen for you.

Page 126
9.2.3 Stage Library

The Stage Library tab shows a grid of each library stage for the current controller stream. By default
the controller stream will be populated with two library stages – Stage 1 and Stage 2. By default the
stages, will be ‘all-red’ i.e. no phases are running in them. To add or remove stages use the two
buttons provided. Newly created stages will by default have no phases running in them.
Alternatively you can add more stages by right-clicking on a column-header of either of the stages.
The pop-up menu offers the option to either delete the stage you are on, add a copy of it, or add a
new stage.
To define which phases run in each stage, click on the “Phases In Stages” grid cells and enter a
comma-separated list of phases. N.B. you can add phases that currently do not exist, but in order to
run TRANSYT you will also need, at some point, to create these phases.
The “Auto Generate Library Stages” button will automatically create in the “Stage Library” a
collection of all possible stages – a stage for each valid combination of all the phases that can run
together ( Outline: Controller Stream n>Stage Library). E.g. if you have four phases defined, where
phase A and C conflict and B and D conflict (as defined by your intergreen matrix), the stage library
generated for you will contain two stages - a stage 1 (phases A and B running) and a stage 2 (phase C
and D running).
The fourth button, “Interstages…” opens the interstage tab of the Intergreen Matrix screen, to let
you see the derived interstages.
9.2.4 (Phase) Delays

The Phase Delays tab shows a grid of phase delays for the current controller stream. By default the
grid is empty. To add or delete phase delays use the buttons provided. Alternatively you can add,
delete or copy them by right-clicking on a row-header (the grey area on the left of any row) of any of
the phase delays.

Having added a phase delay you need to specify whether or not it is a “losing” or “gaining” delay. A
gaining delay is one which delays the start of the phase relative the start of the stage, while a losing
delay is one which extends how long the phase runs after the end of the stage.
A phase gaining delay value (in seconds) can either be set to be an “absolute delay”, which is set
relative to the end of the previous stage or as a “relative” delay which is set relative to where it
would have started if the phase did not exist, i.e. as soon as possible after all intergreens have been
satisfied.
N.B. Phase delays can also be created and deleted directly on the timings diagram, and you may find
this easier to use. See section 16.3.2.
9.2.5 Stage Sequences

The Stage Sequences tab shows a grid of all the stage sequences associated with the current
controller stream. By default Stage Sequence 1 will already exist, which runs stages 1 and 2. By
default, this is also the currently selected sequence, indicated by an asterisk in the Timings diagram
and the Data Outline. Change the “Use Sequence” value to change which sequence TRANSYT will
use.
To add or remove sequences use the buttons provided. Alternatively right-click on a row-header
(the grey area on the left of any row) of either of the stages. The pop-up menu additionally offers
the option to copy a sequence.
To define which stages run in each sequence, click on the “Stage IDs” grid cells and enter a comma-
separated list of stages in the order in which you wish them to run. N.B. you can add stages that
currently do not exist – TRANSYT will automatically add them to your Stage Library. Note however,
that you will need to re-visit the new stages to define which phases run in them – by default they
will be blank – i.e. “all red” stages.
Addition buttons are also provided, in order to make it quick and easy to set up your sequences.
The “Auto Generate Sequences” button will automatically create the 10 simplest Stage Sequences
possible (given the already defined stages and conflicting and non-conflicting phases).

Page 128
The sequence offering the lowest “minimum possible cycle time” is selected automatically as the
current sequence. If none of these sequences are what you want, you can simply edit the one
closest to your requirements (or add a new one) and reset the controller data to use that sequence.
If you want to investigate the benefits of running alternative stage sequences, you
should decide which sequences you wish to run and disable the rest using the
“Exclude from analysis” checkboxes. Use the “Run All Sequences” button to select
either an Evaluation run or Optimised run of all the sequences.
TRANSYT will run each sequence and present a set of key results for each sequence. See below:
Tip: TRANSYT does not retain a full set of results for each sequence, so select the one you want by
double-clicking on the cell to the left of the sequence you want to use in TRANSYT, and then rerun
the model.

The other two buttons “Stage Sequence Diagram” and “Phase Timings Diagram” are simply short-
cuts to open the Stage Sequence Diagram and Timings Diagram respectively.
Multiple-cycling choices are also set from this screen using the dropdowns for stage each sequence.
9.2.6 Resultant (Stages and Green periods)

This tab provides easy access to all the resultant stages and green period data which has been
derived from the other data you’ve specified such as intergreens and stage definitions.
Stage start, stage end and split times can be directly entered using this screen. The ‘Call
to stage’ times (as used in TRANSYT 12 and earlier) can also be edited here, if the option to show
these has been selected.
The calculation of relative offsets (positive and negative) can be enabled either using the Offsets tab,
or globally using an advanced optimisation option (Outline: Network Options > Optimisation Options
> Offsets relative to master controller). See section 22.1 on how these appear in the TRANSYT
output.

Page 130
9.2.7 How to use (Controller Streams Screen)

Various screens are provided to allow signal data to entered, and subsequently edited. The Signals
Data Screen is particularly useful for when you want to enter all the signal data for a controller
stream from scratch, as it brings together in one screen all the facilities to set up your signal timings.
As a result it may well become your preferred method of entering such data. It not the only way
however - Details of the other signal data screens is detailed in chapter 16 – Working with Signals.
To make life easier when setting up standard junctions in a standard way, the following method is
suggested.
This method primarily uses the Signals Data Screen (as well as the intergreen matrix and the
network diagram):
1. Create your new controller stream, if needed, either in the network diagram or via the “Add
a new Controller Stream” button on the data outline.
2. In the network diagram associate the traffic streams with the new controller using the
connector tool. N.B. signalled traffic streams will automatically associate themselves with
the nearest controller.
3. Open the Controller Stream Data Screen and select the controller stream you wish to edit.
4. Select the Phases tab and click on “Create New Phases…” and specify the number of phases
you need. Tip: If you are not sure how many you may need it is not a problem – you can add
more or remove unused phases easily. Guessing high is marginally easier as unused ones can
be easily ignored or deleted at the end.
5. Select the controller stream in the network diagram. At this point the phases controlling
each traffic stream will be displayed. By default they will all be set to Phase A. Simply right-
click on each traffic stream or link to select the right phase.
6. Return to the Signals Data Screen and open the Intergreen Matrix screen by clicking the
“intergreen matrix”. Fill in the intergreens (first tab of the intergreen screen) in order to

define which phases conflict with each other, or use the provided tool to auto-generate both
conflicts and intergreens. (If you use the auto-generate option you should always use a
network diagram that is properly scaled, use curved connectors, and check the conflicts
and values that have been derived. These can be adjusted manually.) You only really need
to add the intergreens for the phase transitions you wish to use, but entering them all is
advisable if you are unsure of what your final stage sequence will be.
7. Select the Stage Library tab. Click “Auto Generate Stages”. This will generate a set of valid
library stages, each of which maximise the number of phases that can run in them.
8. Next, you can add phase delays by using the Delays tab, but this is best used in conjunction
with the Timings Diagram, and you may want to skip this stage until you have a valid stage
sequence.
9. Select the Stage Sequences Tab and click “Auto Generate Stages”. This will create up to 10 of
the simplest (smallest number of stages) stage sequences possible. Open either the Timings
Diagram or Stage Sequence Diagram to see each of them graphically. The show menu in the
stage sequence, or the data outline can be used to view each sequence.
10. Enter the sequence you wish to use in the “Use Sequence” box. Tip: The Tools menu of the
Stage Sequence diagram also allows you select the sequence to use.
11. Now open the Task List to check that your network does not have any errors. As long as
there are no errors you can now run your file with your chosen optimisation options set.
The Links Data Screen provides access to data associated with links, link modelling parameters,
shared stop lines (major and minor links), link flows and flow discrepancy information. Additionally,
summary results are also presented. Skip to section 9.4 if you are using traffic streams.
Select the link to view using the list on the left hand side, or via the Data Outline, or via the network
diagram. The list of links is visible from all tabs.
There are no particular differences between using this screen or the data editor to enter and edit
data. However, you may find is easier to specify data using this screen. Please read Chapter 3 to
find out how to construct a network using links in TRANSYT.
Details of the data items which are accessed via this screen are not described here as this is already
covered in various other chapters.
9.3.1 Link Data Tabs

The Links Data screen consists of up to 8 tabs as follows:

Page 132
 The Link tab allows the Link ID, name, description and traffic node to be set. It also allows
you to set the link length, traffic type, whether or not it has a saturation flow and whether or
not it is signalled and/or a give way. (see screen shot)
The “Modelling” tab is split into two sub-tabs:
The Modelling tab: Due to the amount of modelling data required, this is split between two sub-tabs
– The first sub-tab is primarily traffic related, i.e. the traffic model used can be selected as well as
queue storage values and various traffic model parameters. The second tab allows optimiser
weighting factors and queue limit and DoS penalties to be set, (see screen shots).

The Flows tab is split into a number of tabs. The first allows the link total flow to be defined. A link
consistency tool allows you to identify and investigate where any flow discrepancies exist. How to
use this feature is described in section 14.3.
The “Sources” tab shows a grid of each Source for the current link. If the link is an entry link, then
the grid will have a single row requiring either the cruise time or speed, otherwise it will have/need
as many rows as there are upstream (source) links. Add new sources by right-clicking on the row
header and selecting Add New Source.
The “Advanced” tab allows the specialist flow detector data values to be set.
The “Signals” tab allows you to set what controller stream and phase controls a signalled link. A
secondary phase can be specified when needed, such as when modelling a traffic filter.

Page 134
Because of the amount of give-way data and the hierarchy of movements and the conflicts
associated with them, the give-way data is split between two tabs – “General” and “Conflicts”.
The “General” tab allows data associated with the opposed traffic flow to be defined, as determining
whether or not you wish to use the step-wise opposed turn model.
The “Conflicts” tab allows each conflicting

(controlling) movement to be defined in terms
of the type of opposing item (i.e. is it a link or
link share) and how much to its traffic is
opposing. You also need to define here the
give-way parameters needed for the chosen
give-way model.
The Flares tab allows access to ‘quick’ flares.

Use the buttons at the bottom of the tab to add
or delete quick flares for the current link.
Shared links can be set up using the Shared-

stoplines tab. This screen shows which minor
links are sharing the same stop line, i.e. are part
of the same ‘link share’.

Results for each individual link can also be

examined using the Results tab. Blue
shortcuts are provided to give easy access to
the remaining link results.
The Traffic Streams Data Screen provides access to data associated with arms, traffic streams, lanes,
RR67 saturation flow calculations, modelling parameters, flows and flow discrepancy information.
Additionally, summary results are also presented.
Select the traffic stream to view using the list on the left hand side, or via the Data Outline, or
network diagram. The list of traffic streams is visible from all tabs.
Some tabs have additional features which carry out useful actions such as the traffic flow
consistency diagram on the Flows tab.
data. However, you may find is easier to specify data using this screen. Please read Chapter 3 to
find out how to construct a network using traffic streams in TRANSYT.
Details of the data items accessed via these tabs are not described here as this is already covered in
other chapters.
9.4.1 Traffic Stream Data Tabs

The Traffic Streams Data screen consists of up to 8 tabs:
 The Traffic Stream tab allows the Arm ID, name, description and traffic node to be set.
 The Traffic Streams tab allows the traffic stream length, traffic type, whether or not it has a
saturation flow and whether or not it is signalled and/or a give-way (see screen shot). The
arm properties, such as ID, name, description and associated traffic node are accessed via
the blue “Arm properties…” button.

Page 136
 The Lanes tab allows the number of lanes represented by each traffic stream to be set. It is
also used to determine how the lane saturation flow values are derived. (see screen shot)
 The Modelling tab: This is split between two sub-tabs – The first one is primarily traffic
related, i.e. the traffic model used can be selected as well as queue storage values and
various traffic model parameters. The second tab allows optimiser weighting factors and
queue limit and DoS penalties to be set, (see screen shots).

 The Signals tab allows the controlling phase(s) and its controller stream to be set (see screen
shot). An option allows a secondary phase to be specified, such as when modelling a traffic
filter. This tab is only visible if the traffic stream is signalled. The Signals Tab’s “Signals”
button takes you to the data for the referenced controller stream so that it is easy to make
changes to it, if needed.

Page 138
 The Flows tab allows the total flow to be checked. The Sources tab is used to specify the
cruise speed/time of the sources of the selected controller stream. A flow consistency
diagram is also provided to help you resolve any flow consistency issues, (see screen shot).
 The Give-way tab allows the conflicts between the selected traffic stream and other
opposing (controlling) traffic streams to be set. This is also split into two sub-tabs. N.B. This
tab is only visible if the traffic stream is a give-way, (see screen shot).
 The Normal Traffic, Bus and Trams tabs allow optimiser delay and stop weightings to be
applied. Which of these tabs are visible is determined by the traffic stream “traffic type”,
(see screen shot).

 The Results tab summaries the results for each controller stream, (see screen shot). The
Results tabs show the summary data, with convenient links to the remaining traffic stream
results (using the data editor).
The (Pedestrian) “Crossings” screen provides access to signalled pedestrian crossings and any
connectors (between crossings), crossing ‘sides’ and the conflicts (with traffic). Select the crossing
to view using the list on the left hand side, or via the Data Outline, or network diagram.
pedestrian crossing data. However, you may find is easier to specify data using this screen. Some
elements such as connectors between crossings are best added and deleted via the Network
Diagram. Please read Chapter 15 to find out how to model pedestrians in TRANSYT. This chapter
includes a full description of all the data items required by the pedestrian model.

Page 140
9.5.1 Crossing Data Tabs

The special Crossing Data screen consists of eight tabs as follows:
 The Crossing tab accesses data that is common to the whole crossing (see screen shot)
 The Side1 and Side 2 tabs accesses the data that is specific to the two sides of the crossing
 The Signals tab allows the controller stream controlling the crossing to be set
 The Conflicts tab allows the conflicts between pedestrians and vehicular traffic to be defined.
 The two Side Results tabs covering the results for each side of the crossing
 The All Connectors tab accesses the data for all connectors between crossings within the
network.
Details of the data items accessed via these tabs are not described here as this is already covered in
Chapter 15, but there are a few points worth mentioning here:
 All connectors throughout the network are displayed on the All Connectors tab – not just the
ones relevant to the selected crossing.
 Although it possible to add new connectors via this special screen, it is recommended that
connectors are established by connecting crossings via the network diagram. This removes
the need to know the specific format required to reference the pedestrian crossing “sides”
(see the screen shot below for an example).

In this example, there are four connectors listed. The first one in the list indicates that side 2 of
crossing P3 is connected to side 1 of crossing P4.
 The Signals Tab “View Signals” button takes you to the data for the referenced controller
stream so that it is easy to make changes to it, if needed.
 The Conflicts Tab displays the data in the form of a rotated data grid. If you have not
already specified any conflicts with vehicular traffic, by default, an incomplete (blank)
conflict will already be created for you, ready for you to amend. Additional conflicts can be
added using the button provided.
 The Results tabs show the summary pedestrian data, with convenient links to the remaining
pedestrian results (using the data editor).

Page 142

Data Grids Page 143
Data Grids provide a convenient way of viewing and editing several rows of data at one time. They
also allow you to manage large amounts of data in a concise and customisable manner. You can
display any number of data grid windows at one time, and the data you edit via Data Grids will
update and synchronise with the data outline and network diagram. Data grids can be used to
change multiple items to the same value at the same time. Data Grids can even be used to add and
delete items from the TRANSYT network.
The data shown in each Data Grid corresponds to the type of the current Active Item, and the
columns correspond to the items you would see in the Data Editor for that data item. For example if
you click in the Data Outline on any Traffic Stream (or click on a Traffic Stream in the network
diagram, or any other screen), then any Data Grid screens will show all properties (ID, Name,
Description, Saturation Flow, etc.) as well which Arm it belongs to, for ALL traffic streams in the file.
The Data Grid screen therefore gives you a convenient way to view and edit all items of any
particular type in the entire network.
If, in the Data Outline, you click on the Modelling subsection of a Traffic Stream, then any Data Grid
screens will change to show all Modelling properties for all Traffic Streams.

Page 144
To synchronise data grids (and the data outline) to a currently selected data item in one of the
special screens, such as the Main Data, or Controller Stream, you can use the Sync button on the
main menu. For example, if you open the “Delays” tab of the Controller Streams special screen and
click on any of the cells of the grid, the data grid (if already open) will not instantly change, but after
clicking on the Sync button it will change to show you the “Delays” data for every controller stream.
The same applies to any other item of data that can be selected. Note however that you can only
show one type of data at any one time and you cannot, e.g. show controller streams and links at the
same time. You can however customise the columns shown, as explained further below.
By using the padlock system (see section 7.11), you can show several Data Grids at once. This is a
convenient way to view both inputs and results simultaneously. The ability to customise the
contents of grids means that TRANSYT offers considerable flexibility for both data entry and results
viewing.
Click the Full-size button to toggle the top and bottom parts of the Data Grid screen on/off. Turning
them off can be useful if you are familiar with the data and want to save space on the screen.
For convenience, right-clicking on the Main Menu “Data Grid” button will convert the currently
selected data editor into a data grid, and similarly right-clicking on the “Data Editor” button will
convert the currently selected data grid into a data editor.
10.1.1 Selecting items

If working with for example a Data Grid showing all traffic streams, you can make any traffic stream
the current Active Item by clicking on the row header (the grey section at the far left of the row).
Any other windows showing links data will update accordingly.
You can make multiple selections by using the CTRL and/or SHIFT keys. When a row is highlighted,
the item is selected, and any other screens such as the network diagram will show the same
highlighting. E.g. in the screenshot below, some links in the Data Grid have been selected by clicking
in their row headers; the network diagram shows the same links highlighted in orange. This also

Data Grids Page 145
works the other way round, but only if the grid is not locked – click on items in the network diagram
to see them highlighted in the Data Grid.
10.1.2 Grid orientation

You may prefer to lay grids out vertically rather than horizontally as in the Full-size-mode example
below. To do this, toggle the Rotate Grid button. If you prefer, you can set the file preference
“Appearance >Use rotated data grids by default” so that it does this all the time.
10.1.3 Locking the grid

Please see section 7.11 for use of the padlock system.

Page 146
10.1.4 Editing single data items

Type directly into enabled cells in the grid to edit data and use the arrow keys or TAB/ENTER to
move around the grid. For multiple-choice data fields, you can press the first letter of the desired
option. Use the spacebar to toggle checkboxes on/off.
Some fields will be greyed out, blank and disabled. In general these will mirror the Data Editor,
although the appearance may seem different in Data Grids. E.g. Saturation Flow is greyed out if Has
Saturation Flow is not ticked; several columns including Saturation Flow will be greyed out if a link is
a minor shared link.
Not all data can be edited using Data Grids. For example intermediate data such as most of the
resultant stages data and link green period data is shown in grey to indicate they are derived from
other editable data, and cannot be changed directly, e.g. If “Auto Length” is ticked, then the length
of the traffic stream will be in grey. Other items may be greyed out or hidden entirely depending on
the state of other data values, or on the mode of operation TRANSYT is in.
As you enter data, the data and whole file are continuously validated and updated, and this can
result in other rows/columns in each Data Grid from disabling/enabling or changing, as you enter
data. Sometimes this is useful but if you wish to enter a large amount of data without continual
validation, press the Bulk Edit button. The Data Grid will then switch to an exclusive data-entry
mode and validation will be delayed until you press the Done button.
Note that with some items such as checkboxes you may need to move to a different row before the
change is updated.
10.1.5 Editing multiple data items

Occasionally you also may want to update multiple entries of the same data item with the same
value, e.g. you may wish to set all entry traffic streams to be the 200 metres long instead of 100.
Simply hold down the CTRL key while selecting what entries you wish to change (all of the same
type, i.e. same column). Now right-click to select the option “Edit All”. Type the new value and
press OK. Please note that there may be slight delay before the values are updated if changing a
large number of entries.
When changing either check boxes or dropdowns a small dialog screen will open, allowing you to
select the value you want to set the selected items to. See example screen shots below:

Data Grids Page 147
10.1.6 Using an external spreadsheet

You may find it more convenient to edit or obtain data using an external spreadsheet or any other
program. Copy data from any Data Grid to the clipboard using the main application Copy button,
which you can then paste into a spreadsheet. Once the data has been editing, make a selection in
the spreadsheet that covers the same area and then paste this into the Data Grid.
NB you cannot add in new items in this way; the items must exist in TRANSYT before you can paste
data.
10.1.7 Sorting and grouping rows

Each data grid show rows in the order specified in the sorting options – changed via “Main Menu >
Data > Sorting…”. These allow you to specify whether items should be sorted alphabetically or
numerically and also a number of other grouping options, such as grouping all shared links together.
You can also sort by any column by clicking on the column header, which will toggle between
ascending and descending order.
10.1.8 Adding/deleting rows

To add/delete rows, right-click on any row header. This will show a sub-menu where you can
choose to delete the current row or add a copy of the current row. You can also a new row, which
will use default values for all fields as opposed to copying the current row. For example if showing a
Data Grid of traffic streams, you can use this menu to add new traffic streams to the network and to
delete existing ones.
In some cases this menu contains an extra option: for example if you click on Sources on the Data
Outline and then right-click on a row-header, you can then select Add a New Source. This will add a
new source to the chosen traffic stream or link. These extra options are also useful for any situation
where none of the chosen item exists for the selected traffic stream etc.

Page 148
10.1.9 Customising Column layouts

You can swap columns by dragging column headers with the mouse.
Right-click on any column header to delete that column or to add any other column from the drop-
down menu of available items. Note that the available items include any data fields of the current
active data item plus any sub-items; e.g. if the Data Grid is showing Links, then you can add any field
from Links, Link Modelling, Link Flows, Give Way Data and so on. (You cannot however go the other
way round; if the data grid is showing Link Give Way Data then you cannot add fields from Link
Modelling).
You can also add fields by clicking Customise>Add Columns From Data Editor; as you click on fields in
the Data Editor, they will be added as columns to the Data Grid, until you turn off this mode.
For example to set up a Data Grid to show the ID, Saturation Flow and Length for all traffic streams,
follow these steps:
- Press the Data Grid button on the main toolbar to show a new Data Grid
- Click on any traffic stream in the Data Outline or in the network diagram. The Data Grid should
show all main fields for all traffic streams
- Lock the grid (N.B. single lock only – not double)
- In the Data Grid, select Customise /Remove All Fields
- In the Data Grid, right-click on a column header and use the drop-down menu to select the fields to
add:
In this example Saturation Flow and Traffic Stream Length have been selected.

Data Grids Page 149
The Data Grid should now look like the below:
You can save data grid layouts by selecting Customise>Store Current Layout as a Custom Grid. This
will prompt you to enter a name, and this layout will then be available in the Customise menu every
time you run the program. Note that the layout will only be applicable to the appropriate data type
(e.g. Traffic Streams, not Links), and will only be visible in the menu when the data grid is showing
this data type. The saved column layout does not store the fact that it applies to Traffic Streams and
not Links; you must select a Traffic Streams data grid before selecting a Traffic Streams layout. Data
Grid Layouts are saved to your user preferences; not in the file. TRANSYT is supplied with a number
of custom grids (see screen shot) which you can use, add to, or delete.
Select Customise >Custom Grids Manager access a screen where you can see all saved layouts and
rename/delete them. You can store multiple layouts for the same data item (e.g. Traffic Streams). If
you tick the IsDefault column then this layout becomes the default layout for that data item and will
be chosen automatically every time you show an appropriate Data Grid – in this way you will not
have to select it manually each time. Tick the Use In Reports checkbox if you would like the layout to
be used to generate tables when you generate reports. In this way you can set up your own
selection of data which will then be populated every time you run a report.
10.1.10 Mixing input and output data in Data Grids

TRANSYT grids offer the ability to mix both input and output data in a Data Grid. This allows you to
create exactly what output tables you want.

Page 150
When adding columns to Data Grids, you can only add items that are at the same level or at a higher
level of hierarchy in the tree as displayed in the Data Outline. You cannot add items that are nested
further into the hierarchy. The easiest way to understand this is to experiment with columns, but, it
means that if you want to mix inputs and outputs, you must start with a Data Grid of results, and
then add the inputs (not the other way round).
As an example, the steps below show how to set up a Data Grid to show a simple selection of inputs
and outputs:
 Show a Data Grid and click on Results: Total > Vehicle Summary for any traffic stream in the
Data Outline. The Data Grid will show summary results for all traffic streams.
 In the Data Grid, click the padlock icon once so that the grid will not change when you click
elsewhere in the Data Outline or other screens
 In the Data Grid, click Customise>Remove All Fields
 In the Data Grid, turn on Customise>Add Fields from current screen
 Show the Data Editor if it’s not already shown and click on Degree of Saturation (click the
label, not the text box). The Data Grid should add this column. In the Data Outline click
Results>Queues and Blocking and click on Mean Max Queue.
 In the Data Outline select any traffic stream and then in the Data Editor select Length. Then
select “Is Signal Controlled”.
The Data Grid should now look like this:
You can rearrange columns by dragging the headers with the mouse.
The custom grid can be included in reports by using the options to store and manage layouts in the
Customise menu. (See Section 21.1.3)

Data Grids Page 151
10.1.11 Viewing results and time segments

You can view Data Grids of results just as with any other data item. There are a couple of special
considerations:
To show results for all traffic streams, show a Data Grid and then click on the Results section of any
traffic stream in the Data Outline. (The screenshot below shows the Results>Vehicle Summary
section. You can build any combination of columns as explained above.) For these Data Grids,
TRANSYT adds a special extra row at the bottom of the grid that shows the total of all results for the
traffic streams in the data grid. By default, these will therefore be network totals, but, if you have
filtered the grid to show only those items selected in the network diagram, then the totals will be for
these items only. In this way the totals row serves as a useful mechanism for totalling any set of
results.
You cannot show results for all time segments for all traffic streams (or links) but, this information is
available in generated reports.
10.1.12 Filtering rows

The Filters menu provides a way to restrict the Data Grid to show only those items you have
specifically selected. This applies to any type of item. We recommend using the padlock system to
prevent Data Grids from switching to showing other data as you change screen – see section 7.11.
To remove the filter, click Filters>No Filter – or simply close down the Data Grid and open a new one.
In the screenshot below, a Links Data Grid has the Show Only Items in Current Selection mode
enabled. A rectangular selection has been made in the network diagram to select everything on the
west side of the network, so the Data Grid shows only these links. If there is no selection, then the
Data Grid will be empty.

Page 152

Network Diagram Page 153
In TRANSYT you can show one or more Network Diagram, each of which shows a graphical
representation of the current TRANSYT Network. It shows a depiction of all controller streams,
traffic nodes, links, and traffic streams, indicates their types and various other parameters, and can
be overlaid with a wide variety of data items, such as traffic flow and queue animations. Launch a
new Network diagram by clicking the Diagram button on the main vertical toolbar.
The network diagram can be used to build a network from scratch because it lets you add, delete
and connect traffic streams, controller streams and other items.
The network diagram layout is saved automatically as part of the main data file - there is no need to
manage separate files.2
Much of the diagram is self-explanatory and we recommend that you experiment with the various
features in the toolbars and in the various context-specific menus available by right-clicking on each
of the different items in the diagram.
In general, clicking on a controller stream, traffic node, arm, link, lane, traffic stream, source, OD
Matrix or Location will make that item become the current Active Item, and any other windows will
update to show data for that network item – e.g. the Timings Diagram, Data Editor, Stage Sequence
screen, Data Grids, and so on. Double-clicking on an item will often bring up an appropriate data
entry screen.
The buttons along the top horizontal toolbar control the view of the network and turn on and off
various overlays and other features. The icons in the bottom toolbar represent a set of tools which
you can use to add and connect network items. Each icon is accompanied by a brief text
description, in order to assist with identifying its purpose.
Traffic Streams and links are both colour-coded to allow quick identification of their type, while
shared minor links are shown with dashed lines; bus and tram links are shown with dotted lines.
Pedestrian crossing objects are described in section 15.6. The blue cones around traffic nodes
indicate which traffic streams (or links) are providing the traffic that travels through the traffic node.
The red boxes drawn around traffic streams (and links) when a controller stream is selected, are all
the items controlled by that controller. Automatically, traffic nodes that are signalised have a solid
outline, while unsignalled junctions have a dotted outline.
By default, each traffic stream (or link) also shows a set of “text” information. This default “text set”
can be redefined by you, but will initially show total flow and degree of saturation (assuming that
the file has been run at least once).
2
The only exceptions to this are when you reference background images and 3D Models.

Page 154
The network diagram should be highly responsive even with reasonably large networks. If you find
that it is jerky network dragging movements can be made less jerky by clicking the Fast button. If
the diagram still takes a long time to update, you may need to update your graphics driver and/or
graphics card. In some cases, changing (including reducing) the amount of hardware acceleration
for your graphics driver may help. Contact your IT department for assistance if required.
There is also a ‘safe mode’ that can be used if in the rare circumstances that you experience text
corruption or other graphics problems; select this via the main menu File>Preferences.
In terms of general usage, you may find that the diagram is more responsive if you close down any
other screens that you are not using, including the Data Editor. Also, if you have a lot of high quality
background images, then use the “Background” option to temporarily hide these images.
The diagram will automatically re-size to fit the window when you resize the window, or, you can
click on menu option View> Fit To Window.

Use your mouse wheel to Zoom in and out and Zoom to Rectangle modes to zoom in and out. (With
the latter, drag a rectangle on the diagram to zoom to.) You can also zoom in/out by using the
mouse centre wheel.
Use your mouse wheel to zoom in/out, or alternatively use View > Zoom and Zoom to Rectangle
modes to zoom in and out. (With the latter, drag a rectangle on the diagram to zoom to.)
Hold down your mouse wheel while moving your mouse around to pan around your network.
Alternatively you can switch to View > Pan mode, or use the scroll bars and/or arrow keys on your
keyboard.
If you wish to maximise the area available to displaying your network, there is the option View >
Hide toolbars. To recover the toolbars simply click on the blue “Show Toolbars” text in the top right-
hand corner of the window.
To jump to a particular network item (such as a traffic stream or controller), right-click in a blank
area, select Tools and select one of the “Go to” options. These Go To options are also available from
the main menu.
It is often convenient to keep the network diagram focused on the current item you are working on.
To do this, select the top toolbar option View > Always centre on current data item. While switched
on, the diagram will automatically centre on whatever item you select, say, via the data outline.
Often it is useful to be able to look at exactly the same ‘View’ of a Network as someone else. To this
end, the network diagram allows you to save “Views” within your TRANSYT file. To save a view,
firstly arrange your view of your network in the diagram and select the top toolbar option View >
Save Current View. You can give the view a name up to 50 characters long.
The menu option “View > Saved views” allows you to select one of your stored views. Views are
fully compatible with the diagram’s 3D mode, so that stored views retain whether or not you were
in 2D or 3D mode when you save it, as well as storing your exact viewpoint.

Page 156
The menu option “Manage saved views…” brings up a screen which allows you to individually set
views to be included in TRANSYT’s report.
The “Is Default” option allows one particular view to be defined as the view which is displayed when
the network diagram is opened. The “Landscape option can be ignored as it is currently not used by
TRANSYT.
The network can be printed using the main application Print and Print Preview buttons in the usual
way. In addition, you can use the Toggle Print Zone mode to show an outline overlay that
represents the current printer paper size. You can manoeuvre and zoom the network so that the
desired portion of the network fits inside this outline. Pressing the Print button will then print out
the same area. Print and Print Preview only work while in 2D.
You can also copy the diagram to the clipboard by using the usual Copy button the main application
toolbar or by using the right-click menu in a blank part of the network.
The right-click menu also gives access to an Export menu, where you can choose to export the
diagram in various formats, including AutoCAD (DXF) format.
When selecting either to copy or export any image as a bitmap you will be asked to enter a width in
pixels. This offers you the option to improve the image quality if the default 1000 pixels proves to
be inadequate. Normally 3000 pixels should be the most you will ever need.
See section 11.3 on how multiple views of your network can be stored, selected and also included in
a TRANSYT report.
Arms are represented by a thin line with bend-handles located at both ends. Arms act as containers
for traffic streams. Lanes are represented by a long rectangle running the length of the arm – one
for each lane. The downstream end of which coincides with the stop line or give-way line where
either exists.

A coloured rectangle, beyond the downstream end of the lanes, is used to represent a Traffic
Stream. This takes the form of a coloured rectangle that straddles all the lanes that are contained
within that traffic stream. It is also acts as a display location to show TRANSYT data - If signalled, it
will show the traffic stream’s saturation flow, by default. In the example shown above the
saturation flow for signalled traffic stream 1 is 1800.
Lanes belonging to the same traffic stream are further identified by the fact they are closer together
with each other, compared with when they are part of different traffic streams.
Different lane colours, bracket colours and bracket types are used to represent the various other
traffic stream types as follows:
Signalled give-way:
Give-way with a saturation Flow (i.e. a give-way-bottleneck):
Give-way:

Page 158
Has Saturation Flow (e.g. bottleneck):
Unrestricted (e.g. a traffic stream exiting the network). N.B. for Cell-transmission (CTM) traffic
streams the Cell Saturation flow still acts as a restriction at the upstream end.
Flares are naturally indicated by the positioning and length of the links and lanes.
Note how the give-way maximum flow (indicated by the lower case g) and saturation flow are
shown when appropriate, and both where both will apply.
11.5.1 Moving Lanes between Controller Streams and Arms

Sometimes it will be necessary to redefine which lanes are within which traffic streams, e.g. new
traffic streams are always created on the offside of any existing traffic streams – this may not be
what is desired.
Use the Move lanes mode to move lanes between different traffic streams, on the same arm or to a
different arm. Also use it to change the order of lanes.
To change the order of lanes within a traffic stream:
 Click on a lane you wish to move and then click on another lane on the same traffic stream.
The lane you are moving will be inserted below that of the other lane and all remaining lane
will shuffle up or down as a result. e.g. if there are four lanes and lane 4 is clicked and then
on lane 1, lane 4 will now be lane 1, lane 1 will become lane 2, lane 3 will become lane 4. If
lane 1 is clicked first and then lane 4, Lane 1 will now be lane 3, lane 2 will become lane 1,
lane 3 will become lane 2 and lane 4 will remain lane four.

To move a lane from one traffic stream and/or arm to another:
 Click on a lane you wish to move and then click on another lane on a different traffic stream.
The traffic stream will be moved from the current to the other traffic stream. N.B. if the lane
that is moved is the last one in its traffic stream, the original traffic stream will be deleted.
To separate a lane from its traffic stream to create its own traffic stream:
 Click on a lane you wish to move and then click on the network background. The traffic
stream will be moved from within the traffic stream into its own traffic stream, i.e. a new
traffic stream will be created.
11.5.2 Lane movements and traffic turn style

It can be useful to show on the network diagram the lane indication arrows that would exist in real
life. In order to assist you setting these up, TRANSYT by default automatically sets these up for you
based on the “traffic turn style” of each movement.
The “traffic turn style” is either “nearside”, “offside” or “straight, and is reported on each traffic
stream “source” (see screen shot below) – The source of each downstream traffic stream). This
particular data item is derived primarily to assist in the automatic calculation of estimated RR67
saturation flows. See 4.5.5.1 for further details on this. Examining the auto-set values shown in the
diagram can be used to help check that the RR67 saturation flow calculations are OK.
For fairly typical crossroads, and T-junctions the estimate of whether traffic is turning left, right or
straight is fairly easy and TRANSYT is likely to provide a good initial set of lane arrows for you, such
as those shown in the screen shot below of three approaches to a crossroads. (Note that in this
example the furthest offside lane from the south is for trams.)

Page 160
However, the automatic system cannot ever be perfect for a number of reasons. Firstly, lane
indication arrows will often reflect the rules governing the placement and selection of arrow types,
which do not necessarily match the physical turning movements that traffic make. Because of this,
the arrows in the network diagram can be edited manually. To do this, right-click on a lane and
switch off “Auto-set arrows”, (see screen shot) on any lanes you wish to change. The previously
greyed-out ‘arrow’ options will become editable. “Left”, “Right” and “Straight” arrows can now be
switched off and on manually.
The lane arrows selected via the network diagram have no effect on the calculation of
RR67 saturation flows – They are only cosmetic. However, when in auto-set mode, the arrows will
reflect the traffic turn styles that are used in the RR67 saturation flow calculations.

Arrows that are no longer “auto-set” will be shown in blue (instead of black) as a reminder that they
do not ‘necessarily’ reflect the traffic turn style values.
Links are represented by a thin line with bend-handles located at both ends. The link number is
within a semi-circle, and the stop lines of signalled links are represented by black square brackets,
located at the downstream end of each link. The saturation flow associated with each stop line is
shown resting along the node side of the bracket - In the example shown above the saturation flow
for link 2 is 1800.
Different link colours, bracket colours and bracket types are used to represent the other link types.
Although not shown here, the same colour scheme and brackets types are used for Arms, which are
shown.

Page 162
The green circles at the ends on each link or arm are called bend-handles, which serve as points
which you can grab with the mouse to move either end. You can add additional bend-handles along
the length of a link or arm in order to provide a point at which it can be bent.
Additional bend-handles are a consequence of splitting the link or traffic stream into multiple
“Sections”. To create an new “Section” right-click on the link and select “Add new Link Section” or
“Add new Arm section”. There is no limit to the number of sections/bend points you can add, so
links and arms can be made to curve along as detailed a path as you required. Use the same right-
click menu to remove sections or to straighten the link or arm.
Bend handles can be shown or hidden using the menu option Show > Bend Handles.
A controller stream in the network diagram is represented by a three-dimensional box.

The controller ID is indicated within the box, and when using the animation tool, it also
displays the stage that is currently running.
Like other objects, Controller Streams have their own right-click menu. These menu options allow
controller streams to be copied, added or deleted as well as offering a quick way to launch a variety
of related screens, such as the Timings Diagram. Timing Wheels can also be displayed via this menu.
Timing Wheels allow stage timings to be displayed and edited directly from within the Network
Diagram. They are particularly useful for making manual ‘tweaks’ to the timings. An example of one
is shown below:
The features and use of Timing Wheels are fully described in section 16.4

11.9.1 Selecting items

Simply click on any item in the diagram (traffic nodes, traffic streams, links, source connectors, etc.)
to select it. It will be shown with orange highlighting and any other relevant data screens (e.g. Data
Editor, Data Grids) will update to show data for this item, if appropriate.
To select multiple items, hold down the CTRL key.
To select a rectangular selection of items, use the top toolbar option Select > Rectangular Selection
and drag a rectangle on the diagram.
11.9.2 Moving items

To move an item in the diagram, simply click on it and drag with the mouse.
The green circles at the ends on each link or arm are default bend-handles, which serve as points
which you can grab with the mouse to move either end. Similar ‘handles’ also appear on the
Network Diagram Timing Wheels and on pedestrian crossings menu.
As you move a traffic node, you will notice that all connecting items also move with the node. To
avoid this happening, hold down the SHIFT key as you drag the node; the node will then move in
isolation. This method works whenever you don’t want attached items to move as well.
Similarly, as you move entry traffic streams (or links) via their outermost bend-handle, you will
notice that they pivot around the traffic node they are attached to. To avoid this happening, hold
down the SHIFT key as you drag the bend-handle; the link will then move in isolation.
Note that you can move stop lines, which has the effect of moving all items that share the stop line.
If several items are selected, then moving any of the selected items will move the entire group.
You can rotate an item, or a group of items, by firstly selecting them and then using the Rotate
Selection mode. The easiest way to do this is to use Select > Rectangular selection. The Rotate
mode is chosen by right-clicking in the selected area (N.B. watch the mouse cursor to ensure it is still
in this area) and choosing the menu option Tools> Rotate Selected items. The rotation is carried out
around the first point that you click on in this mode; drag the mouse in a circle to control the
amount of rotation.
To revert to a previous layout, use the Undo/Redo buttons in the main application Edit menu or
toolbar.

Page 164
11.9.3 Aligning to a grid

Turn on the Show Grid mode (Top Toolbar > Show > Grid) to show a grid that items will snap to as
you move them. You can also align everything to the grid by right-clicking in an empty part of the
diagram and selecting Tools>Align all items to grid.
11.9.4 Adjusting spacing

You can explode or contract everything in the diagram by clicking on the spacing button and the
dragging the mouse. This can be useful if needing to match the diagram to a background image.
Alternatively, you can right-click in a blank area and selecting Tools>Adjust network spacing. Enter a
number representing a percentage by which you wish to increase/decrease the spacing – e.g. 120%
to slightly increase the spacing between everything.
The lateral spacing between links and arms can also be adjusted - right-click in a blank area and
select Tools>Adjust link/arm spacing.
Tip: If you want your network background images to re-size at the same time as the
network, go to Diagram Menu> Options> Backgrounds tab, and set the “Scale with
drawing” option.
11.9.5 Changing properties of items

To change the properties of an item you can double-click on the item. This will bring up the screen
that you have defined as your “default Editor” (see File> Preferences) – Either a special screen
(default), a data editor, or a data grid.
Right-clicking on any item will show a menu appropriate to that item, from where you can access
certain commonly used items, such as a traffic stream’s control type.
Uniquely, the right-click menu for Lanes also incorporates the right-click menu for traffic streams.
This is in order to make it easier to access commonly edited traffic stream data.
Note that in some cases you may need to use the Data Outline to access exactly the item or sub-
item that you need.
Some screens, such as the Traffic Stream Data, Links Data and Controller Stream Data screens, will
update to show data for the currently selected item, as does the Data Editor.
11.9.6 Adding and deleting items

If the diagram already contains items, you can delete, make copies and add new items by right-
clicking on any existing item and choosing the appropriate Add… or Delete options. Multiple item

deletions are also possible by selecting all the items you wish to remove and then pressing the
Delete key.
Individual Timing Wheels can be added by using the right-click menu of a controller stream.
You can also add items by using the toolbox at the bottom of the network diagram. There are
various alternative ways to do this; some are described below. In general, to exit a mode, right-click
in a blank part of the diagram, or click on the (select) arrow button in the top toolbar.
 Click on the traffic node item and then click anywhere in the diagram to add the node to the
network. Continue to click to add more nodes, and right-click to exit ‘add’ mode
 Drag the traffic node icon onto the diagram to add a traffic node
 Click on the traffic stream or link toolbar item; click on the particular type of that item that
you want (signalled, unrestricted, etc.) and then click anywhere in the diagram to add an
item of that type. The first left click on the diagram determines where the upstream end of
the traffic stream will be located, and the second left click will determine where the
downstream (stop line end) is located. Note that this default behaviour differs from earlier
releases of TRANSYT 15.
 By default, the program will be in a mode to immediately start adding another item. Right-
click to exit this mode.
 If you want to add arm or link sections (i.e. bends) at the same time as you are adding the
arms and links, then you can click the mouse-wheel instead of right-click. Each mouse-wheel
click will add one arm/link section (i.e. a new ‘bend’ for the arm/link), until you right-click.
 Alternatively, to add bends you can disable the user preference “Junction/Network diagram
> No bend points for newly created items”. With this preference disabled, each mouse click

Page 166
will add one arm/link section (i.e. a new ‘bend’ for the arm/link), until you right-click. To add
a straight arm or link in this mode, click once to set the start point, again to set the end point,
and then right-click to finish.
N.B. when adding a traffic stream you are, in fact, adding a traffic stream within an arm. If
you want more than one traffic stream within an arm simply use either of the right-click “Add
copy traffic stream” or “Add new traffic stream” options.
N.B. Traffic streams and links will be automatically associated with the nearest Node (if there
are any) in the network. Additionally, if a traffic stream or link is signalled it will be
automatically associated with the nearest controller stream.
 Drag any of the individual traffic stream or link types onto the diagram to add an item of that
type (you will then need to reposition it)
 N.B. you do not need to necessarily use the different traffic stream or link types: you can add
any type and then right-click on the newly added item and use the menus to change the
control type, and/or double-click to edit other properties.
 An OD matrix can be created using the same two methods (drag or clicking) as described for
creating nodes. When an OD Matrix is created a single Location will also be created
automatically
 When creating additional Locations, select which OD matrix it will apply to first, then click or
drag the Location icon
You can also add arms, traffic nodes, links, etc. via the Data Outline, as with any other data item, in
which the new item will appear in an arbitrary position in the diagram. Note that the option to add
links via the data outline is hidden until you set the File Preference “Exhaustive Data Outline” to
true. Data Grids and some of the dedicated screens can also be used to add items.
By default, added items, such as traffic streams are given an unique ID. If you wish to specify
these yourself as you go, you can change the user preference “Junction/Network diagram >
Prompt for IDs”.
11.9.7 Merging Existing Files into your network

You can merge TRANSYT network files into your existing network via the Junction button on the
bottom toolbar. Existing files can be added to the network as many times as you like and at any
time. The use of existing files makes the construction of your network a lot quicker as it will often
be quickest to add a pre-prepared junction to your network than to start from scratch. To facilitate
this, a set of ‘building-blocks’ is provided with TRANSYT – A set of ‘Library’ Files.
11.9.8 Connecting items

Use the Connect bottom toolbar item to connect items in the following ways:

 Click on a traffic stream, lane, or link and then click on a traffic node to set that node as the
traffic node for that item. If the selected item is already connected to a traffic node, the new
node will replace the old node.
 Click on a traffic stream, lane, or link and then click on a controller stream to set that
controller stream as the controller stream controlling that item. If the item is already
connected to a controller stream, the new controller stream will replace the old controller
stream.
 Click on a link and then click on a second link to connect the first link to the second link. (I.e.,
the first link will then be an upstream link (or source) of the second link.)
 Click on a lane/traffic stream and then click on a second lane/traffic stream to connect the
traffic stream associated with the first lane/traffic stream to the traffic stream associated
with the second lane/traffic stream, (i.e. traffic streams are connected, rather than lanes.)
 Click on a link and then click on a connector to disconnect the existing source link for that
connector (if one exists) and connect the new link as the new source.
 Click on an OD Location and then click on a traffic stream/link to set that traffic stream/link
as an Entry for that particular Location. Click on a traffic stream/ link and then click on an OD
Location to set that traffic stream/link as an Exit for that particular Location. Note how the
order in which you attach the traffic stream/link to the location determines whether or not
the traffic stream/link is defined as an entry or exit for the selected Location.
Use the Share Links bottom toolbar item to set up shared stop lines. When in this mode, click on a
link and then click on a second link to assign the second link as a minor link of the first link. The first
link must already be a major shared link (which is true by implication if it is the only link at a stop
line). To ‘unshare’ a link, you can view its Properties and untick the Is Minor Shared Link property.
11.9.9 Shaping (source) connectors

It is possible to ‘curve’ source connectors in order to offer a more realistic visual path for traffic
through junctions and to help avoid unnecessary overlaps of connectors. Right-click on the source
connector and select Recurve - The connector is automatically split into a number of even-length
sections with bend–handles joining each section (similar to those on traffic streams and links) and
the connector is curved appropriately for the situation. A connector can be straightened again using
the Straighten right-click option.
Individual sections can be added and deleted using the right-click menu. Individual connector bend-
handles can each be manipulated to form whatever shape is required, but are hidden by default.
While the connector bend handles are hidden the shape of the connector curve cannot be directly
manipulated. Use the Top toolbar menu item Show>Connector bend handles to reveal these.
To quickly re-curve all source connectors in the network, right-click in the network diagram and
select Tools>Recurve All Sources. An equivalent option also exists to re-straighten them.

Page 168
Editing the position of some components of the network can sometimes result in unsatisfactory
curves. If this happens, simply use the Recurve option again, either on individual connectors or on
the whole network.
11.9.10 Splitting traffic streams or links

To make it easier to insert new junctions into an existing network, TRANSYT includes a “Split Arm” or
“split Link” right-click option on each Armand link.
When selected, this option will split the Arm into two Arms. A new unrestricted upstream arm is
created with the original upstream connections preserved. The existing Arm or Link will be fed by
the new unrestricted Arm or Link. Multiple traffic streams, lanes and their associated connections
will also be preserved during the split. Traffic streams that do not use “Auto length” will have their
“Length” split equally between the two traffic steams.
Other traffic stream or link data, such as delay/stop weighting factors, will be retained within the
downstream traffic stream. It is recommended that any queue limits you are using are reviewed.
11.9.11 Adding labels

You can add textual annotations to the diagram via the Label Bottom Toolbar option. In this mode,
click anywhere on the diagram and type the annotation. You can then move and resize the
annotation by dragging it as with any other item. To resize it, click on the label and then drag the
red handles as either end.

The toolbar at the top of the network diagram provides access to a number of extra modes and
menus where you can turn on various features and visualisations. Most of which are described in
the following sections.
11.10.1 Show (options)

The top toolbar Show menu lets you choose whether to display a variety of items. A number of
these are described below while the remaining ones are described in the following sub-sections.
Stop lines, bend handles, connectors, and connector bend handles can all be turned on and off from
the Show menu. Stop lines of signalled traffic streams and links are represented by black square
brackets, located at the downstream end.
The Show connectors as straight option will display all connectors as straight,
without losing the underlying shape of the connectors. This is useful when you
wish to temporarily straighten all connectors, but don’t want to lose your
underlying connector curves permanently.
++
11.10.1.1 Scale Ruler (and changing the scale of your network)

To find and display the scale ruler on the network diagram, right-click on the network diagram, and
select the option Tools>Go to Scale Ruler. The scale ruler can also be displayed or hidden using the
Top Toolbar>Show>Scale option. The default scale is 5 metres per small square; 50 for per big
square.

Page 170
If you are using a network background image(s) it may be desirable or necessary to change the scale
of the diagram to match that of the background image. It is essential to scale the diagram if you
intend to use any of the ‘auto-calculate’ options which require a scaled network in order to make
the correct calculations, such as traffic stream “Auto length” and the geometry-based intergreen
calculation tool.
Please note that if you are adding background images after having created a network (or part of
one) you may need to adjust the size and orientation of it relative to your network. This is done by
selecting your background image and using one of its two bend handles to adjust the size and
orientation of it relative to your existing network. You should do this before scaling the diagram.
To scale the network diagram, line the scale ruler up with an item on either a background image or
an item in the network of a known length (e.g. image scale, a building, etc.) and right-click on the
ruler. This will bring up the only option “Adjust Scale”. Click this and enter the length of the item
you are measuring. This changes the diagram scale to match that of the item you have chosen.
Once your network is fitted to your diagram, the Link/Stream Lengths view (section 11.10.11) can be
used to quickly check to see if you’ve forgotten to enter any of your traffic stream (or link) lengths.
11.10.1.2 Compass
A compass can be displayed or hidden using the Top Toolbar>Show>Compass option. Drag the bend
handle at the end of the compass to orientate and resize it.
11.10.1.3 Key
Show/hide the key by selecting the Top Toolbar>Show>Key option. The key, when visible, displays
the animation time within the cycle and which step within the cycle is current. This is particularly
useful when running animations – screen shots will include the key and hence offer information on
what time the image represents.
The key shows additional relevant/essential information, such as the type of overlay, and the
overlay colour scheme used.

11.10.1.4 Item Tooltips

The Network Diagram also has the option of displaying item tooltips. Virtually all network diagram
item have a tool tip which is displayed by leaving the cursor over the item to be examined. Each
tooltip is specific to each particular item. In addition to simply offering a quick way to access
information about the item, they have a number of other uses, e.g. they allow you identify an item
when it is too small to see its ID. In the case of the Errors and Warnings Overlay, they display a
description of each of error/warning as you hover over each item.
An example of the tool tooltip for a Lane is shown below. It shows the saturation flow value of the
lane itself, and additionally shows information about the traffic stream the lane is part of and also
identifies the Arm in which it belongs.
11.10.2 Show Upstreams / Show Downstreams

Turn on either Show Upstreams or Show Downstreams mode (Top Toolbar > Show > Link/Stream
under cursor) to check the direction of traffic flow along traffic streams (or links) and also to give an
overview of which streams or links feed into which other streams or links.
While in this mode, hover the mouse pointer over any traffic stream (or link) to show yellow arrows
on the upstreams or downstreams of that link or stream. Use the Reset option to come out of this
mode.
11.10.3 Controller stream boxes; flow and traffic node cones

Traffic Nodes are represented by circles. The Traffic Node cones show coloured cones indicating the
traffic node for each traffic stream (or link). You can also show “flow cones” highlighting the
connections between traffic streams (or links).
For clarity, you may wish to turn the cones off. For convenience, when a network item is selected
the cones associated with that item will still continue to be displayed, even when the cones for the
whole network are switched off.

Page 172
Each traffic stream’s signals are controlled (if relevant) by the associated controller stream. The
controller stream (red) boxes indicate (when this option is enabled) which controller stream are
associated with which traffic streams (or links) by displaying a red box enclosing the items it is
controlling, and also displaying their phases. This facility allows you to check that each controller is
controlling the right items.
11.10.4 Background – show and hide

Use the top toolbar Background options to select between showing the Network, the background
image(s) or a combination of both. Selection can be achieved either using the drop down list (click
on the down arrow) or by clicking on the icon itself to toggle between the options.
The option “Show backgrounds and numbers/overlays only” allows most network items to be
hidden while retaining the text sets and data overlays. This is particularly useful when displaying
animations of traffic flows (either in 2D or 3D) or when using Simulation Mode.
The Manage backgrounds… option offers a shortcut to the relevant part of the Diagram Options
screen - See section 11.11.2 on how to add backgrounds.
11.10.5 Diagram ‘Fast’ Mode

Use Fast Mode to turn off certain textual items to increase the drawing speed - Only ever needed for
the largest of networks.
11.10.6 Signals
The top toolbar Signals menu lets you display actual signal states for each traffic stream (or link), on
a variety of items. Use the Animation Controls screen to set the point within the cycle to display
signals for, or start the animation to animate the signals.
You may wish to use this in conjunction with the Timings Diagram, Stage Sequence screen or Timing
Wheels so that you can see the signal plans for one or more controller stream at the same time, as
in the screenshot shown.
Optionally (and by default), the current stage running at each controller stream is shown
underneath the controller stream number in brackets.
Starting red-with-amber times and end-of-green amber times will also be shown in addition to green
and ‘not green’ when the Main Menu > Data > Model and Results options “Display Red-with Amber”
and “Display End-of-green Amber” are enabled.

Signal stages can also be shown on the connector lines – This can help to identify signals which have
been incorrectly set up. E.g. green connectors that cross each other path may indicate this. It also
makes them easier to see, particularly for larger networks where you will tend to zoom out more.
It is also useful to be able to clearly see which phases are controlling which traffic streams. Selecting
the Always Show phases option displays throughout the network a circle on top of the stop line of
each signalled traffic stream indicating the controlling phase(s).
For convenience, when a controller stream is selected the phase circles associated with that
controller will be displayed, even when the option to show them for the whole network are
switched off. The circles also indicate their signal state when using the animation controls.
Tip: From within the Data Outline, selecting either an individual phase or a resultant stage, will
indicate which parts of the network are controlled by that item, by showing the relevant phase
circles. This facility is disabled when Always Show phases option is set.

Page 174
Use the Show Effective Greens option to show yellow arrows on any traffic stream (or link) whose
controlling traffic stream is showing a green signal, taking into account start/end displacements, for
the current point in the cycle. (Adjust the point in the cycle using the Animation Controls screen.) If
a traffic stream or link is not signalised then it is considered to be permanently green. This mode
can also be useful for displaying the differences between actual greens and effective greens, if you
combine it with the Show Signal States mode.
In the screenshot above, traffic stream C/1 towards the top left of the network is showing actual
red, but the yellow arrows indicate that traffic is still be crossing the stop line.
11.10.7 Highlighting normal traffic/bus/tram/pedestrians

Use this tool to fade out all items in the network other than the selected type. In this way you can
easily see where the normal traffic, bus, tram and pedestrian items are, as in the screenshot below,
where Highlight Bus Network has been chosen. To restore normal appearance, select Reset.
This facility interacts with the various “Flow Overlays”, to offer additional filtering for
these visual outputs.

11.10.8 Data (Overlays)

A variety of tools are available via the top toolbar Data menu for the visualisation of traffic stream
(and link) lengths, queues and traffic flows. To show queues or achieved flows, you must have
successfully run the file at least once. Use the Summary Results screen to check the status of this
“run data”. If no data is available, you can still select the options, but no queues/animation will be
visible.
Note that you can scale the relative width of all queue and animation bars via the network diagram
Options screen.
The following sections describe each of the available data overlays:

Page 176
11.10.9 Local Matrix Demand

Select this option to display the local OD Matrix demand by movement from each OD location.
This option can be combined with the “Flow overlays” described below.
11.10.10 Flow overlays

A variety of static visualisations are provided that will assist you in the design phase, model
construction phase and evaluation phases of your network. Some of the facilities provided offer
advantages over the use of a traditional lane flow diagram for the design phase. Other facilities are
particularly useful in diagnosing what is wrong with your new or existing designs.
11.10.10.1 Flow Type and Display Style

Firstly, you should choose what “Flow type” you wish to display. Secondly, you should choose the
“Display Style”. The display style offers you the choice of showing the flows in the form of a
bandwidth or using a series of coloured boxes, each of which displays the flows on each lane.

The flow types that can be displayed are as follows:
 None
 Demand, i.e. total flows as seen in the resultant tab of your OD matrices
 Demand (scaled), i.e. total flows having taken account of the vehicle flow scaling factor
 Achieved flow, i.e. what is ultimately in the network
 Lost flow (scaled demand minus achieved)
When using the Bandwidth display style, each traffic stream or link is overlaid with a yellow bar
with its width scaled according to the volume of flow. This makes it easy to confirm which parts of
the network carry the lightest and heaviest flows (relative to each other), and it is easy to spot
where traffic is being prevented from reaching parts of the network due to upstream
oversaturation.
You may wish to adjust the “Overlays Width Scaler” to adjust the width of the bars to suit your
needs.
Where a traffic stream represents more than one lane, the flows on the traffic streams
are split equally between the appropriate lanes.
In order to make the graphics easier to see, the lane background colours are replaced
with white when using the flow overlays.
Other overlays such as “Degree of Saturation” can still be used in combination with
the flow overlay boxes. Other combinations of overlays may not work so well as they
will tend to obscure each other, e.g. Mean Max Queues will obscure the flow overlay
boxes.

Page 178
The following screenshot shows a signalised roundabout with the Flow Type set to Demand and the
Display Style set to Bandwidth. You can clearly see that one of the main movements of traffic is
from location 1 to location 5.
The following screen shot shows the same signalised roundabout with the Flow Type set to Lost
Flow and the Display Style set to Boxes. You can see that a proportion of traffic travelling from the
left approach to the roundabout is failing to get through the junction as shown by the numbers
within the yellow boxes that appear at the stop line end of each lane. Each box that exists indicates
lost flow – The actual amount is written in each box.
You can also take advantage of the “text sets” to select data items that further assist you. For
example, you may find that setting the Text E (stop line text) to show “Calculated Capacity” and
setting Text A to either show “Calculated flow entering” or “Total flow” can be useful. Remember
you can save a particular “text set” for future use with any file.

11.10.10.2 Matrix Type

If you are one or more wide area matrices you can use this option to display flows for wide-area
matrices instead of for local matrices (default).
11.10.10.3 By origin or destination (Colour Coding)

If you wish to identify where traffic is coming from or going to within the OD Matrix zone you are
examining, you can select the colour coding option to show flows By origin or By destination.
Both the “achieved flow” and “lost flow” flow types require the file to be run first
because they reference the TRANSYT results
Furthermore, the first time you select both the flow type “achieved flow” and the
colour coding by “origin” or “destination” you will be asked to enable “Calculate
Results For Path Segments”. This option (described in section 22.4.4), needs to be
enabled in order that TRANSYT knows to store the data required for these particular
overlays. At least an evaluation run will also be required to repopulate the file with
the required data.

Page 180
The file should be re-run if you change anything that changes the results – This
includes changes to the flow allocation data.
The colour coding options are best described via a few screen shots:
The screen shot below illustrates colour coding By origin and using the display style Bandwidth –
You can see how there is a Kaleidoscope of colour on the exit from the network into location
indicating that the traffic on this exit is made up of a small amount of traffic from all origin locations.
You can also see that very little traffic from location 3 (cyan) turns left at the first junction.

The screen shot below illustrates By destination and using Bandwidth – You can see how all the
traffic to location 3 is now coloured cyan, matching the location colour.

Page 182
The screen shot below illustrates Demand, using By origin and using Boxes – You can see exactly
which lanes are taking the flows from each origin. This view is particularly useful at the junction
design stage, as you can easily see the effects of your choice of number of lanes and lane
movements. Remember that traffic streams with multiple lanes will have the flows shown split
evenly between the lanes.

The screen shot below illustrates Lost Flow, using By origin and using Boxes – You can see how easy
it is to identify where traffic is not getting through the junction – The approach at Location 1 is
slightly oversaturated leading to the missing traffic on a number of downstream lanes. These
discrepancies will appear on every downstream lane that is carrying traffic from the oversaturated
approach.
The location colours are automatically selected by TRANSYT, but can be edited using the “Locations”
tab of each OD Matrix.
11.10.10.4 Use of filters

Selecting the “Use Filters” option allows you to limit the visualisations to one specific local or wide-
area matrix. You can further filter the flow overlays to just one origin, or destination, or a
combination of both. This facility is particularly useful when you are wishing to investigate what
particular lanes are being used by particular sources or destinations. You will also be able to use this
to check whether or not flow allocation from your OD matrices to the network require manual
adjustment. The filtering works with all the other options, e.g. flow type, display style, and colour
coding.

Page 184
The screen shot below of part of a roundabout, shows flow (by origin) that is filtered to flow from
location 1. This illustrates poor allocation of traffic flows – Some traffic from location one is clearly
rotating all the way around the roundabout, instead of simply turning left – Indicated by traffic on
two circulating lanes approaching node 1. Some traffic is even travelling North (not shown) and
reappearing on the node 2 approach to complete their journey. This is due to the fact that none of
the allocation settings that would have prevented such unrealistic paths being generated have been
selected. Enabling the “limit paths by length” would solve this. This is just another illustration of the
investigative power of flow overlays.

The screen shot below of a roundabout illustrates flows by destination from location 1. This time
the flow allocation looks reasonable. Having used the lane balancing allocation mode, you can see
that traffic turning left to the pink destination is allocated to the lane on the left-most traffic stream,
avoiding the middle stop line lane. This is due to the high volume of traffic being allocated to the
lane on the middle traffic stream which is carrying traffic heading to location 5 (green).

Page 186
11.10.11 Link/Stream Lengths Mode

In this mode yellow bars are displayed on each link and traffic stream, the lengths corresponding to
their actual lengths. The scaling is based on that of the scale ruler. Use this display mode if you wish
to position the network to reflect real relative lengths of link and traffic stream.
In the screenshot below, traffic streams 1/1 and C/1 on the left-hand side of the junction are defined
as 100m long. Traffic stream 1/1 has been stretched to be longer than its real length so the yellow
bars stop short of the ends of the streams. Traffic stream C/1 is too short, – indicated by the yellow
bar showing a thicker section at one end. When the streams are positioned correctly, the lengths of
the yellow bars will exactly fit the streams, as in the case of traffic stream 2/1. This stream in fact
has had its “Auto Length” set to TRUE, ensuring its length will match that of the diagram.
For traffic streams (and links) with upstream sources such as Cx/1 in the diagram, the discrepancies
can also be seen along the source connectors. Often, it will not be possible to have all of these
lengths matching simultaneously since the lengths of the connectors can (and probably will) be
slightly different and the length is represented in TRANSYT by a single (average) value.
11.10.12 Mean Max Queues (MMQ)

In this mode orange bars are overlaid on each traffic stream (or link) to indicate the mean max
queue. The queue is shown as a proportion of the traffic stream (or link) length based on the
maximum queue storage, e.g. half the length will be orange if the queue is 5 and the maximum
queue storage is 10. If you specify your own maximum queue storage, this will be reflected in the
proportion of the traffic stream (or link) that is orange. Queues are never drawn longer than the
maximum queue storage – instead, a black bar is drawn at the end of the queue to indicate that the
queue is longer than drawn.

The mean maximum queue is only an approximate average of the maximum back of
queue that is likely to be encountered, and it will therefore be exceeded a significant
amount of the time.
The MMQ overlay includes the random component of queue.
11.10.13 Traffic (Queues and Occupancy) animation

This mode shows cell occupancy at each cell for the current point in the cycle time as set via the
Animation Controls screen. Additionally this mode is colour coded, such that queued traffic appears
in red, and the rest in blue.
Queues, flows and occupancy overlays only show the uniform component of these
items. They still offer useful insight into how the traffic in a network would behave.

Page 188
11.10.14 Queues
In this mode the uniform component of the queue on each traffic stream (or link) is shown. The
queues are shown at the moment in the cycle time as set in the Animation Controls screen, so you
can animate the queues by starting animation via this screen. It may also be useful to show signal
states at the same, as in the screenshot below.
What you see on a particular traffic stream (or link) depends on what traffic model it is using. If
PDM is being used, red and green bars are used to show the uniform component of the queue. If
CTM is used, then red ‘cell’ values are show instead showing where traffic is stationary. The queues
are shown at the moment in the cycle time as set in the Animation Controls screen, so you can
animate the queues by starting animation via this screen. It may also be useful to show signal states
at the same, as in the screenshot below.
The red bars (or cells) on each traffic stream (or link), represent stationary queues. These tend to
build up while the signal at the stop line is showing red. When the signal changes to green, the
position of the stationary queue moves upstream as traffic at the stop line begins to leave the
queue. Where PDM is used, the green part of the bar can be thought of as representing moving
traffic. In other words, the red bars show where the front and back of queue are located.
Queues, flows and occupancy overlays only show the uniform component of these
items. They still offer useful insight into how the traffic in a network would behave.
The uniform queue animation exactly matches the data shown in the Spatial Queue
Graphs.

11.10.15 Flows
This mode shows the flow rate along every traffic stream (or link) for the current point in the cycle
time, as set via the Animation Controls screen. For CTM traffic streams and links, the flow in each
CTM cell is shown. Where PDM is used, the traffic stream and links are split into a number of
sections – since PDM does not have ‘cells’ as such. One obvious difference between PDM animation
and that of CTM is that you are likely to spot traffic disappearing at the stop line rather than at the
point it reaches the back of a queue. This is a simply a reflection of how the PDM works – i.e. traffic
queueing vertically at the stop line.
The width of each green block is proportional to the flow at that point along the traffic stream (or
link). You can control the width scaling of the blocks via the Options screen (Options>Data
Overlays>Cell flow Size Scaler). Larger blocks show where the highest flows occur at the current
point in the cycle. They will be largest on links and traffic streams with the highest flows, and at
times where these are discharging the maximum amount of traffic, e.g. when a queue begins to
dissipate.
Please note that this mode shows no queues whatsoever – only moving traffic.
Despite the slightly ‘unrealistic’ nature of this output, it can assist in the interpretation of traffic flow
through complex junctions and larger networks.
It may often be easier to visualise the flow by showing them at the same time as the cell
occupancies. An alternative appearance is available by selecting Flows (arrow overlay), which will
use arrows for flows instead of blocks.
11.10.16 Occupancy
This mode shows cell occupancy at each cell for the current point in the cycle time as set via the
Animation Controls screen. The width of each blue block is proportional to the occupancy of that
cell. (Control the width scaling of the blocks via Options>Data Overlays>Cell flow Size Scaler.)
As you change the timeline via the Animation Controls screen, the cell occupancy blocks will move
through the network, and in this way you can easily visualise the movement of traffic through the
network. Blocking back effects are also easy seen.
Use the Interpolate Values option to give a smoother animation.

Page 190
The maximum occupancy of each cell is proportional to the traffic stream (or link) saturation flow,
and the pedestrian link has an arbitrarily high saturation flow. The resolution of CTM cells is
determined by the number of time steps in the model and the cruise speed of each link.
If the Stop line Saturation flow has been set to be different from the Cell Saturation Flow for a traffic
stream (or link), you will notice the difference between the width of a full cell at the stop line
compared with the rest of the CTM cells.
11.10.17 Flow sources (CTM only)

This mode will show red and green circles at the entry point of each CTM traffic stream and link.
Red circles on the entries indicate that the CTM occupancy and queue on the traffic stream (or link)
is greater than it can accommodate and that therefore traffic will be queueing before it enters the
network.

11.10.18 ‘Other Overlays

In addition to the main data that can be superimposed on the network diagram TRANSYT has a
collection of useful ‘other overlays’ (Top Toolbar > Data > Other Overlays). Only one overlay at a
time can be displayed. These overlays can be used in combination with the flow overlays.
Use the Value Comparison option to show blue highlighting on each traffic stream (or link), where
the depth of shading indicates the relative value of a chosen data field. By default, the data field is
set to Total Flow, so the deepest blues show the heaviest flows. You can control the sensitivity of
this feature via the Value Comparison Ramp slider (Top Toolbar>Options>Data Overlays.

Page 192
You can show visualisations of any other data item by switching on this mode and then clicking on
any data field in the Data Editor or a Data Grid screen. As long as the data field is numerical, the
network diagram will attempt to colour the blue overlay boxes according to the relative value of this
data field for each traffic stream and link. In the example below, the value comparison tool is
showing the relative values of Stop Weighting Multiplier for each traffic stream, and it is
immediately obvious that you have entered a high (or non-zero) stop weighting for 3 of them. (Note
that the pedestrian crossing is red because it happens to be excluded from the comparison.)

Select Flow Consistency to highlight any problems with flow consistency. Red or amber
links/sources indicate that there may be an inconsistency with the flows at these locations. See
Select Errors and Warnings to highlight in red/amber/green/grey any warnings, errors or

information tasks for each link, source and node. These correspond to the messages shown in the
Task List screen. In the screenshot below, a user has accidentally deleted the controller stream; all
the traffic streams which were controlled by this controller stream are then in an error state, as
indicated by the red colouring. The Task List will then show full details of the problems.
NB you can change the colours used from the default reds and greens via the User Preferences
screen.
Select Traffic Model Type to show the ‘active’ selected traffic model type for each traffic stream and
link. It is always the model type that is going to be used by TRANSYT that is shown, irrespective of
the locally defined value, i.e. the ‘active’ model type. The ‘active’ model type is not necessarily the
same as that selected for a specific link or traffic stream, since the network-wide options to force
TRANSYT to use a particular traffic model may have been selected.

Page 194
Select Optimisation Level to indicate on each traffic stream or link, what the
optimisation level is of its associated controller. This option is useful when reviewing
a network as optimisation level differences across a network can be easily missed.
A number of other overlays are also available covering the most used/important model results.
These are:
 Degree of Saturation
 Utilised Storage
 Practical Reserve Capacity
 Level of Service (LoS)
 Mean delay per Vehicle
 Mean stops per Vehicle
 Mean Journey Speed
 Optimisation Level

Each of the overlays use colour coding on the traffic streams and links to indicate which parts the
network have the best and worst results. Enable the key (“Show” Menu) in order to display the
colour-coding and value thresholds used for each overlay. The colour coding and value thresholds
are fixed, so that they offer an absolute evaluation of the Network, rather than a relative one.
background
There are a large number of options controlling the appearance of the network diagram, and you
can access these via the diagram Options screen. (Use the icon on the right-hand side of the main
toolbar.
Most items are self-explanatory and are not listed here other than the ones of particular interest
below, and the 3D options which are covered in chapter 12. Most tabs have a Defaults button,
which will restore the options on that tab to their default values.
Most diagram options are saved in the data file, so the same options will be used when you next
load the file.
Please also see the TRANSYT User Preferences screen for other options that may affect the
network diagram.

Page 196
11.11.1 Changing the appearance of the Network Diagram

Via the Appearance tab of the Options screen you can change the appearance of a variety of
network diagram items. Many of the options allow items to be resized, re-coloured, or widened.
Some of the items you are most likely to want to modify are described below:
 The foreground and background colours can be changed - A dark background and a light
foreground can be useful for high visibility visualisations.
 The “text sizes” sub-tab offers you the option to change the size of the text on traffic streams
and links.
 On traffic stream and links you have the option to display IDs or names or both. Adding a few
key names (e.g. road names or numbers) to arms can make it a lot easier to identify each
part of your network.
 It is sometime useful to set Lanes to be either transparent or opaque – especially when you
are using background images as well.
 The “connectors” sub-tab allows you to change connector widths and colours. This is
particularly useful if you are using background images.
 The “data overlays” sub-tab offers you the ability to change the height or width of many of
TRANSYT network diagram overlays. Please note that some sliders affect items in both 2D
and 3D modes, such as the “cell flow scaler”, while some affect only 3D – as indicated by
their names.
 User arrows only apply to links (traffic streams use a different arrow type), and can be
switched on so that you can set up arrows on each link showing which way traffic is allowed
to turn. Right-click on the link and select from a left, straight or right user movement. The
movement will be depicted using a blue arrow at the stop line.
11.11.2 Adding and manipulating background images

Add one or more background images via the Background tab. Select “Manage backgrounds…” from
the background dropdown menu and press the Add button to browse to a bitmap (bmp/gif/jpg
format), which will then be placed in the middle of the network diagram. Whenever you wish to

adjust the opacity, position and size of the image, you must select it in the list box. New images
will be automatically selected as you create them.
When selected the network diagram will jump to the location of the image, and will show the image
with a red outline and black handles, which you can use to move, orientate and resize it. Once you
are happy with its location, right-click to deselect it. Use the opacity slider to control how faint the
image is relative to the rest of the diagram.
Tip: It is well worth having at least one traffic stream within your network before adding any
backgrounds. You can then stretch your background image(s) so that a traffic stream’s lane width
matches approximately the width of a lane in your background.
You can add more than one image. For example, you may have several drawings of junctions which
you can superimpose on the diagram at the same time as an overview map. Adjust the opacity,
position and rotation of each image so that they overlay the relevant part of the network structure.
Selecting the “Scale with drawing” option will ensure that if you subsequently use
the right-click menu option “Adjust network spacing” all your background images
will be adjusted to match.
The images are embedded in the main TRANSYT data file; there is no need to save the image files
separately. Note this is NOT the case with 3D model images.
11.11.3 Showing textual data

Multiple “Text Sets” can be defined to store user preferences for displaying text on traffic streams
and links using the Text top toolbar menu. The “Manage Sets…” menu option offers a shortcut to
the relevant tab of the Options screen.

Page 198
A number of useful sets, including one selected as the default one is already set up when you first
install TRANSYT. These can be added to, adapted, or deleted. Use the “Manage sets…” shortcut to
access these options. From here you can also set the default set (see screen shot).
Text Sets are stored within the user’s preferences (.config file) so that they act as your personal
collection of sets, for use with all your files.
Within each set, settings are stored for traffic streams, links and connectors. Sub tabs are used to
set the data items separately for these items. There are four positions where data can be displayed
on traffic streams and five positions on links. The data displayed can be any TRANSYT data field (i.e.
any input data or output results).
For traffic streams, a data field can be shown at both ends (positions A and C), in the middle (B) and
also in front of the stop line symbol (E). Select the data fields to use by clicking on them in the Data
Editor (or a Data Grid) and then clicking the Select Field button. Alternatively, click on the dropdown
arrow next to the Select Field button to use the data tree structure instead. Tick the “2D” and/or
“3D” boxes to actually show the values on the diagram.
Similarly any data field can be shown on each link by setting up options in the Link Text sub-tab - A
data field can be shown at each corner of each link (A, B, C and D) as well as in front of the stop line
symbol.
Each “text set” can be selected using a button on the toolbar, either using the down arrow to select
or clicking on the symbol to toggle through each of the available sets.
To be reminded what items are being displayed, firstly ensure you have Show> Item Tooltips enabled
and then hover over the item to reveal the tooltip listing each item description.

Use the “Manage sets…” shortcut to set the default set (see screen shot).

Page 200

In TRANSYT 15 it is now possible to visualise the network in three dimensions as well as in two. This
has a number of very useful benefits, including the ability to present traffic model results in a more
understandable way to those who may be totally unfamiliar with TRANSYT, with the type of output
it produces and also may know little about traffic engineering.
Even those who are very familiar with TRANSYT can benefit from using 3D Mode, because…
 it allows the network, and its associated TRANSYT data, to be examined more easily.
 it more-easily fits the network on one screen
 you can more-easily examine the results by changing your view point of the network
 it puts the network ‘into context’ by adding network artefacts, such as street furniture,
buildings, trees, etc.
 it can display results in a more intuitive way
 it can emphasise particular outputs using 3D, while using 2D for the rest
3D mode is enabled by selecting the network diagram’s 3D menu option “Display diagram in 3D”
The screen shots below illustrate the effect of switching from 2D to 3D.

Page 202
Navigating around a network while in 3D mode is relatively easy
Orbit around current viewpoint: Move mouse with middle button (or mouse wheel) and SHIFT key
is down.
Move camera: Move mouse with middle button (or mouse wheel), OR use arrow keys
Zoom in/out: Scroll mouse wheel, OR use plus (+) and minus (-) keys
Move up/down vertically: Press PAGE UP/PAGE DOWN keys
These instructions are also available from the 3D menu option “3D mouse/keyboard controls…”.
While in 3D mode results such as text sets and overlays can be shown in the network diagram
exactly the same way as in 2D – i.e. drawn on the surface of the network. Additionally there are two
ways to display data in 3D, so that it stands proud of the network surface. The first method works in
conjunction with the ‘text sets’ (see Diagram Options > Text Sets) as described in section 12.2.1. The
second method shows 3D data that is more appropriately displayed along the complete length of
traffic streams (or links) – These are called ‘3D Blades’ and are described in section 12.2.2.

12.2.1 Text Set 3D ‘Bars’

Any item chosen to be part of a text set can be selected to appear in either 2D or 3D – Simply tick
the relevant boxes to display a vertical bar proportional to the value of the data. This, of course,
works only with numbers.
Select this…
…to give you this:
The screen shot shown above illustrates the use of the 3D text set ‘bars’. The degree of saturation is
shown by the vertical blue bars. The width and height of these can be changed using

Page 204
Options>Options>Data overlays>”3D bar base size” and “3D bar height scaler” sliders. The colour
can also be changed (Data Overlays>3D Bar colour).
Notice how both 2D and 3D items can be displayed at the same time – the red/yellow/green colour-
coded traffic streams is as a result of selecting the Practical Reserve Capacity ‘other’ overlay.
12.2.2 3D Blades
Any item chosen to be part of a text set can be selected to appear in either 2D or 3D – Simply tick
the relevant boxes to display a vertical bar proportional to the value of the data. This, of course
works only with numbers.
The width of these can be changed using Options>Appearance>Data overlays>”3D Blade Width”.
The “Cell Flow Size Scaler” slider also affects the height of the Flow blade while the Cell
Occupancy/Queue Size slider affects the height of the Occupancy, Queue and Traffic blades.
There is a choice of four 3D blades:
 Traffic Blades
 Flow
 Queue
 Occupancy
Each traffic stream or link (and connectors) is split into a number of cells. This naturally is the case
when using a CTM model – for PDM the traffic stream is split into sections and the flow or
occupancy is calculated for each point based on the PDM traffic model results. The traffic flow
flow/queue or occupancy for each cell during each time segment is drawn with a height relative to
the value of that data item, i.e. they can be animated over time using the Animate screen.
These blades each have an equivalent flow or spatial graph, as they are, in effect, showing the same
data. Although these animations only show the uniform component of the items shown, they retain
their usefulness in illustrating the general behaviour of traffic within a network or at a single
junction and can help considerably when carrying out diagnostic work on a file.
Examples of each of the blades are shown below:
Traffic blades (below): This shows both stopped traffic (in red) and the remaining traffic (in blue) in
the one blade overlay. Currently these blades are only shown on CTM traffic streams and links.

Flow blades (below): This shows where moving traffic is. Stationary traffic is omitted.
Queue blades (below): This shows only stationary traffic. Currently these blades are only shown on
CTM traffic streams and links.

Page 206
Occupancy blades (below): This blade uses just the one colour (blue) to indicate where traffic is. It
does not differentiate between queue and moving traffic.
The 3D mode can be enhanced by the addition of 3D models. The only model type that can be
referenced is the Collada (.DAE) format. Collada is an open standard (using XML Schema) that
facilitates the exchange of computer graphics including 3D imagery. As a result, there are a number
of tools/apps available that can be used to create your own 3D models and then save to in a Collada
(.DAE) format.
No models are supplied with TRANSYT, but a wide variety of models can be sourced from a number
of internet sites - Just search for “Collada” files.
Once you have created or downloaded your first models you will find that they are not
just a single file – The model is a collection of files including surface rendering
graphics that are required in addition to the model DAE file itself. However, most
models will be stored or downloaded as a single compressed file. You should un-
compress the contents of the file into a single folder and give that folder a unique

name. You should then ensure that all your model folders are located within the one
‘master’ folder. Finally to access these models you need to tell TRANSYT where this
‘master folder’ is (See left-hand screen shot below). This can also be set via
File>Preferences.
To add model to your network select “Add” from the Options>3D Models tab and select the DAE file
– This should be located in the “models” sub-folder of the particular folder used for that model. You
may add the same model multiple times into your network.
Unlike background images, these 3D models are only referenced within TRANSYT so
will only appear automatically in your TRANSYT file so long as the same models exists in the same
locations relative to the ‘master folder’. If you wish to send a file to a colleague or client and wish
to use3D models you will need to separately send them the individual folders containing you models
and then ask them to set their TRANSYT model folder to the folder in which they have copied these
to.
The 3D models are highlighted and manipulated in the same way as for backgrounds, i.e. the
network will ‘jump’ to the item (shown as a red framework) when you select it in then list. When
you add a new model it is automatically selected. To rotate or enlarge grab the red bend handles,
hold down the left mouse button and drag. Make sure that you have the 3D menu option “Show 3D
models” switched on if you are manipulating a 3D model.
To get rid of a reference to a model, select it in model list and press the “Remove” button or simply
select it in the network diagram and press the delete key. Model references can only be removed
one at a time.
Currently it is assumed that all models will start at height zero, i.e. they ‘site on the ground’ – You
may find some ready-created models that either start in mid-air, are on slopes, go below ground,
etc. There is no option in TRANSYT to change the height of such models, and without this ability,
you will probably find these particular models are not very useful in TRANSYT as they will look rather
odd.

Page 208
Although the network file size will be unaffected by the number of models referenced, you may find
that the use of a lot of 3D models may slow the performance of the Network Diagram. If this
happens there is a 3D menu option to hide them until you really need to display them.
It is sometimes useful to be able to reproduce a sequence of movements through a network so that

it can be repeated easily for demonstrative purposes, such as a presentation of results, or a training
session.
TRANSYT 15 allows a single “fly through” a network to be stored within the data file. To record one,
simply select the 3D option “Fly through…” to show a small dialog screen (see screen shot above).
Press Record to start recording any then click back to the network diagram to make your movements
of the network. You can use all the same keyboard and mouse options that you would normally use
to change your view point of the network over time, i.e. there are no special movement options
specific to the ‘fly through’ feature.
If a recorded ‘fly through’ already exists and you press the Record button, you will be asked if you
wish to overwrite the old one.
The pause button allows you to stop the recording temporarily. While paused, you can still change
the network position using all the same controls. One use of this feature is to store a presentation
that is a timed set of snapshots of the network – This can be achieved by recording pausing, moving
your viewpoint, and un-pausing to record the new view point, and to repeat this as many times as
needed. It is best to give each view plenty of time as when you play it back you can increase the
speed while it plays, but you cannot decrease it.
There is also a repeat button, so that you can leave an animation to play continuously in a loop.
Please note that all Network diagram display options and standard animation controls
can still be used in the middle of a recording, or a playback. These are NOT recorded.
This is because you are only recording the change in viewpoint and NOT what data is
displayed or animated – They are totally independent of each other.

If you wish to display particular data during a playback of a recorded ‘fly through’,
then for convenience you might want to save a text set (called “Fly Through”
perhaps?) containing your specific selection of data items to display.
Particularly long recordings will increase the size of your data file significantly.
Because this is NOT a video you can only play the fly through within the TRANSYT
network diagram. You cannot export it any video format file.

Page 210

Working with Analysis Sets, Demand Sets and Time Segments Page 211
Some items are only available if the current file is in Advanced Mode.
Analysis Sets allow you to store multiple sets of data within a single file, representing, for
example, different signal plans and references to different demand sets (see below).
Demand Sets allow you to store different sets of flow data, which can optionally be combined
together. Each Demand set is associated with a time of day (e.g. AM, PM, etc.) and also a scenario,
such as base development flows, or current/future years.
When a file is run, all combinations of Analysis and Demand Sets can be run automatically. In this
way, the results for each flow scenario, for each time of day and for each signal plan, can be
summarised together.
Time Segments are used to split a modelled time period into smaller time segments. For
example you can run the TRANSYT model over a 60 minute period using 4 time segments of 15 min
each. Flows need to be specified for each time segment. A set of results will be available for each
time segment, along with a set of overall ‘summary’ results representing the entire 60 minute
period.
N.B. please do not confuse Time Segments with Time Steps. Time Steps are used internally to
control the resolution of the model on a per-cycle basis and are independent of Time Segments.
At any time there is a currently selected Analysis Set, Demand Set and Time Segment. In Advanced
mode, these are always shown at the top of the main window. Click on the icon next to each one to
jump to the appropriate part of the Data Outline where you can edit the properties of the selected
set. The same icons are used throughout the Data Editor and other screens to indicate where a data
item is entered or is available for each Analysis Set / Demand Set / Time Segment.
To change the current set, select it via the drop-down list. Any screens that show data for each set
will then automatically update. You can also activate a set by clicking on it in the Data Outline.
In the Data Editor and Data Grids, any data item with an Analysis Set icon ( ), for example, can be
entered separately for each Analysis Set. The value shown on the screen for such a value is the
value for the CURRENT Analysis Set. A similar system applies to Demand Sets and Time Segments
(see section 13.5 for more detail on this).

Page 212
Make sure you understand the distinction between editing the definitions of
Analysis/Demand Sets versus editing the actual data for each set. E.g. you may have
an AM Peak and PM Peak Analysis Set, each of which contains a separate set of data.
Edit the traffic flows via the normal data entry screens, making sure that you have
selected the correct Analysis/Demand set via the drop-down menus on the main
program toolbar. The current analysis set and current demand set is also indicated
by the presence of an asterisk in the Data Outline
The Demand Set itself (e.g. time period start time, name, etc.) can be edited by
selecting the relevant Demand Set in the Demand Sets section of the Data Outline.
Alternatively, simply click on the Demand Set icon next to the Demand Set drop-down
selector.
When you add a new Analysis Set or a new Demand Set, the new set contains a copy
of all the data for the previously selected set. E.g., all traffic flows for a new Demand
Set will be a copy of the flows for the last selected Demand Set.
TIP: When working with multiple Analysis and/or Demand Sets, it can sometimes be useful to
confirm where, if any, the differences between sets are located. To do this, see section 21.4
(Comparing files and data sets)
Click this icon at the top of the screen to jump to the properties for the current Demand Set.
When you start a new file, the file contains a single Analysis Set. To rename analysis sets or to use
multiple analysis sets the file must be in Advanced Mode (Main Menu: > Data > Use Advanced
Mode). You can rename it by locating it in the Analysis Sets section of the Data Outline and then
using the Data Editor to set its properties.
The results from all runs of the traffic model can be stored within the same data file. To run
different Scenarios, you can either select each one in turn via the Analysis Set/Demand Set drop-
down menus and run each separately; or you can use one of the “Run all” dropdown options on the
main menu Evaluation Run and Full Run buttons to run all sets.

Add a new Analysis Set (via the Data Outline, or by right-click the icon next to the drop-down menu),
and notice that the drop-down menu at the top of the main TRANSYT window now lets you choose
between two Analysis Sets. To actually enter data for each Analysis Set, firstly select the Analysis Set
from this menu OR by clicking on it in the Data Outline, and then use the normal data editing
screens.
Often it will be the case that each Analysis Set represents a Signal Plan, which is not independent of
the traffic flows defined within the Demand Sets. By default, therefore, it is assumed you will want
to run specific Demand Sets with each Analysis Sets. To this end, the Analysis Set option “Use
specific Demand Set(s)” is set. In this situation, for each Analysis Set you must reference at least one
“Specific Demand Set” (e.g. enter ‘D2’ to use Demand Set 2, or ‘D2,D3’ to run those two sets in
turn). This determines the flows that will be used for this Analysis Set.
This is different to Junctions 9, where “Use specific Demand Set(s)” is not set by default.
In more complex scenarios it may of course be easier simply to save the different setups as different
files.
The data items that can be entered for each Analysis Set are easily identified within the data editor
by the ‘card stack’ symbol on the screen (see icon at start of this chapter). However, by default
these data items are initially shared between sets. You may notice that the network cycle time has a
light grey ‘card stack’ icon next to it – The ‘greying out’ indicates that it is a data item that is
currently shared across all analysis sets, but one which can be changed to be different between
analysis sets if required. See section 13.5 that explains how to do this.

Page 214
Click this icon at the top of the screen to jump to the properties for the current Demand Set.
When you start a new file, the file contains a single Demand Set. You can rename it by locating it in
the Demand Sets section of the Data Outline and then using the Data Editor to set its properties, or
click the icon next to the drop-down list. To add new Demand Sets, right-click the icon next to the
drop-down list, or use the Data Outline in the usual way.
Each Demand Set defines a separate set of flows. To actually enter data for each Demand Set, firstly
select the Demand Set from the dropdown menu OR by clicking on it in the Data Outline and then
use the normal data editing windows such as the Origin-Destination (OD Matrix Data) window.
Each Demand Set is intended to represent a set of flows that, typically, are for a particular year and
time period. Clearly there are many ways to use this system but in TRANSYT each Demand Set is
given a Scenario Name and a Time Period Name. The overall name of the Demand Set is formed
automatically from a combination of these two names. It is entirely up to you how these names are
used; the only restriction is that each Demand Set must have a unique name.
Some examples for Scenario Name are ‘2015’, ‘Observed’, ‘2021 Forecast’, ‘Development Flows’,
etc.
Some examples for Time Period Name are ‘AM’, ‘PM’, ‘Off-peak’, or blank. If the flows represent
extra development flows, to be added to other demand sets, then it may be that they do not have
any particular time period, in which case the time period name can be left blank.
See also section 13.3 “Analysis/Demand Sets and Summary Results” for an example of the use of
Analysis and Demand Sets.

If you need to add together multiple sets of flows, add a new Demand Set and tick the Composite
option; you can then enter the Demand Sets that you wish to add together to form this new
Demand Sets – e.g. enter “D1,D2,D3” to add together the flows for Demand Sets 1-3. A Demand Set
cannot refer to itself in this way, so you must always add a new Demand Set for this purpose. If the
currently selected Demand Set is composite in this way, then flows for individual movements will be
greyed out and will show the calculated total flow, as in the screenshot below.
Use the Start Time option to enter a time of day that the flows are for. (This is only used for
labelling purposes when showing time segments.)
Entry Flows can be entered for each time segment using OD Matrices. The data entered is for the
currently displayed Time Segment on the time-segment drop-down menu at the top of the main
window. The Summary Time Segment (when available) will always indicate zero flows, as no data is
specified for this drop-down selection.
TIP: If you wish to quickly raise the demand data flows, say, to test how robust your existing solution
is, a “vehicle flow scaling factor can be applied to all vehicular flows throughout the network (Outline:
Network Options > Traffic Options). This parameter, can either be set so that the same factor applies
to all analysis sets, or changed so that different factors are applied to each analysis set.

Page 216
When you start a new file and show the Summary Results window, results for the default Analysis
and Demand set are shown. Only if these results have been saved with the file, will these be shown
as up-to-date.
If you add more Analysis and Demand sets, then, by default, the Summary Results window will
always show the results from the CURRENT set only. To compare the results from different sets, you
need to select each in turn and, if necessary, re-run the file to refresh the Summary Results screen.
The Summary Results window can operate in a more powerful mode where all appropriate sets are
automatically shown together. Turn this on by choosing Show>Show All Analysis and Demand Sets.
(This mode is saved within the file itself) and by default is OFF.
As an example: start a new file, add a second Analysis Set by copying the existing one, and give each
Analysis set a different “Name”. Also change some of the timings in the first analysis set. Also
ensure that “Use specific Demand Sets” is switched OFF in each Analysis set - This option will be
explained later on. Turn on Show>Show All Analysis and Demand Sets in the Summary Results
screen: The grid will now show a table for each combination of Analysis and Demand set.
To begin with, the results for the new Analysis Set are shown with a red background to indicate that
the traffic model has not yet been run. The results will appear and the background change to green
as soon as you either run the set individually, or, click the dropdown on “Eval Run” and select “…Run
for all data sets” on the main toolbar. With this setup the, results for the two analysis sets are
both based on the demand data in the single demand set.

Now select the second Analysis set via the analysis set dropdown and click the “Full Run” button.
This will optimise just this selected set, leaving the first analysis set’s timings as they are. With this
setup, you can now compare the results of the original timings with the newly optimised ones.
13.3.1 Use specific Demand Sets

It is not uncommon to want to store and run sets representing different times of day, such as
AM/PM peak periods. Given that the demand during each peak is going to be different, the best
timings for each are also going to be different – hence you will continue to need the two analysis
sets to store and preserve these timings.
Continuing with the same file from the previous section, add a second Demand set. Name the
Analysis sets 1 and 2 as “AM” and “PM” respectively. Set the “Time Period Name” of demand sets 1
and 3 as “AM” and “PM” respectively. Set the Demand Set “Scenario name” to “2018” for both sets
In this situation you only want the AM timings to run with the AM traffic demand. To ensure this
happens, the Analysis Set has the option “Use specific Demand Sets”. Set these are shown:
Although not essential, when using the “Use specific Demand Sets” facility it can be useful to set the
colour of the sets to make it easier to see which analysis sets are referencing which demand sets.

Page 218
The colours only show up in the data set dropdowns and in the data outline. Set the Demand set
colours to match.
The Summary Results window will update to show the two results, split into separate tables – one
above the other. The results will appear and the background change to green as soon as you click
the dropdown on “Full Run” and select “…Run for all data sets” on the main toolbar. With this setup
the two results are based on the two peak periods, with each of them using different optimised
signal timings (within each analysis set).
Now add two more demand sets representing future years (and raise some of the OD flows), and in
each case set their “Time Period Name” to ‘PM’, and their scenario name to “2026”. The set
“Names” should now look like this in the data outline:
Change the first Analysis set “Specific Demand Set(s) to reference the two demand sets D1,D2 (i.e.
use a comma-separated list) and set the second set to reference D3,D4. See below:

The results for these sets will appear when you run each set or when you click “Run Eval > Run
>Evaluation Run for all sets”. The additional demand sets, translate into further rows in the table of
results.
Note that if instead you select “Full Run > Full Run for all sets” in order to optimise the timings,
TRANSYT will optimise the timings based on the first Demand Set and store the results, and then re-
optimise the timings based on the second Demand Set and store these results too.
However, although both sets of results can be ‘technically’ correct, the first set of results (for 2018)
will now be displayed with a red background. This is because since this scenario was run, the timings
have changed.
Tip: To avoid this effect when optimising timings for multiple demand sets, use as many analysis sets
as you have demand sets.

Page 220
Changing any data for a set will result in the relevant sections of the Summary Results window being
shown with a red background until this particular analysis and demand set are run again.
13.3.2 Optimise Specific Demand Sets:

Another situation you may wish to deal with, is one where you want to optimise timings for an
existing situation, and then apply a ‘pressure test’ on these timings, by seeing how these same
timings will cope with future year traffic volumes.
Continuing with the example from the previous section, switch on the “Optimise specific set” option
in both Analysis sets, and change the “Demand Set to optimise” to “D1” in Analysis Set 1 and “D3” in
Analysis Set 2, as shown below:
When you select “Full Run > Full Run for all sets”, TRANSYT will optimise the timings based on the
first Demand Set and store the results, and then run an evaluation run based on the second Demand
Set and store these results too. Because only one set of timings, is used for each time period, all the
results will be displayed as up-to-date (i.e. with a green background).
13.3.3 Other Demand Set and Analysis Set features

Run Automatically: The Demand Set option “Run Automatically” allows you to select and de-select
which sets you wish to have run when you select “Run for all sets”. In the example below the
demand set D4 (2022, PM) has been de-selected.

Include in Report: The Analysis Set option “Include in Report” allows you to select and de-select
which analyses you wish to have run when you select “Run for all sets”. Using the same file that was
used above to illustrate the use of the “Run Automatically” option, the screenshot below shows that
Analysis Set 2 has been excluded from the report.
TIP: Demand Set and Analysis Set definitions can easily be viewed and edited together by showing a
Data Grid and selecting any Demand Set or Analysis Set definition:

Page 222
To summarise: The grid shown in the Summary Results screen is formed from the defined Analysis
and Demand Sets and depends also on their Include in Report, Use Specific Demand Set and Run
Automatically properties respectively. There are various ways to set this up.
TIP: The Summary Results screen can automatically be included at the top of reports if the
appropriate option within the Report Viewer is selected.
If not using OD Matrices to allocate flows, the Total Flow and Source Flows for each link can be
entered separately for each Demand Set, using the Data Editor and/or Data Grids or via the Links
screen.
TRANSYT offers a mechanism that allows you to share data across multiple analysis sets and multiple
demand sets. Some data items are shared by default, but can be separated; some are permanently
shared; and others are permanently separated. Most of the categories make sense, while a few have
been categorised on a slightly more arbitrary basis.
How the system works is described in the flowing sections.
13.5.1 Analysis Sets

If there is more than one Analysis Set in the file, then any data field that can potentially take a
different value for each Analysis Set is shown with a ‘card stack’ icon in the Data Editor and Data
Grid screens. To begin with, these have a light grey colour.
For example, the vehicle flow and pedestrian flow scaling factors are shown with the light grey card
stack icon:

This means that although there are several Analysis Sets in the file, the same scaling factors are used
for each set. For instance if you change the vehicle flow scaling factor and then switch to a different
Analysis Set, the same value (the global value) will appear in all other Analysis Sets.
When you decide that a particular data field should be different in a particular Analysis Set, then
select the Analysis Set and then click the card stack icon. The icon will change to yellow (see screen
shot), to indicate that this Analysis Set uses its own value (independent value) compared to other
Analysis Sets. (The value for the data field itself will not actually be different until you go ahead and
enter a different value whilst the Analysis Set is selected.) Click it again if you subsequently decide
that you want to use the global value.
If there are several Analysis Sets then the icon for any given data field can take three states:
Light grey: the data is the same in all Analysis Sets. All Analysis Sets use the global
value for this data field.
Yellow: the data in the current Analysis Set is independent from any other set.
Dark grey: the current Analysis Set uses the global value but there are other Analysis
Sets in the file that use their own independent value.
Items that are permanently shared, such as signal timings, will show the yellow icon permanently.
Using this system, you can choose which data fields are actually different between Analysis Sets.
Until you do this for a given field, the data will be the same between all sets.
For example, you could set up two different calibration intercept corrections in two Analysis Sets
without worrying about the geometric data accidentally diverging between the two sets.
Data items that have a dependency on another, will change to the same status as the
item they have a dependency with, e.g. if saturation flow source is set to be different between sets,

Page 224
the Max flow (unopposed) for give-ways will automatically also become per set, as its value is
dependent on the saturation flow.
13.5.2 Demand Sets

If there is more than one Demand Set in the file, then some data fields ALWAYS take a different
value for each Demand Set. Such data includes O-D data and traffic demand data, since these are
the main reasons for using Demand Sets in the first place.
Certain other data fields that can potentially take a different value for each Demand Set are shown
with a ‘card stack + clock’ icon in the Data Editor and Data Grid screens. To begin with, these have a
light grey colour.
For example the walk-on-red pedestrian behaviour model requires you to specify a percentage of
pedestrians likely to be under 18. This data item and some other properties throughout the data file
have the light grey icon in their corners:
This means that although there are several Demand Sets in the file, this particular pedestrian
crossing data is used for each set. For instance, if you change the “percentage under 18s” and then
switch to a different Demand Set, the same value (the global value) will appear in all other Demand
Sets.
When you decide that a particular data field should be different in a particular Demand Set, then
select the Demand Set and then click the ‘card stack + clock’ icon. The icons will change to green, to
indicate that this Demand Set uses its own values (independent value) compared to other Demand
Sets. (The value for the data field itself will not actually be different until you go ahead and enter a
different value.) Click it again if you subsequently decide that you want to use the global value.

If there are several Demand Sets then the icon for any given data field can take three states:
Light grey: the data is the same in all Demand Sets. All Demand Sets use the global
value for this data field.
Green: the data in the current Demand Set is independent from any other set.
Dark grey: the current Demand Set uses the global value but there are other Demand
Sets in the file that use their own independent value.
Using this system, you can choose which data fields are actually different between Demand Sets.
Until you do this for a given field, the data will be the same between all sets.
For example, you could set up two different sets of fuel coefficients in two Demand Sets without
worrying about any of the other data accidentally diverging between the two sets.
In Analysis Set and Demand Set definitions, tick the Locked option if you have finished entering data
for the set and want to avoid accidentally altering data. In this mode, all relevant data fields will be
locked when this set is chosen. For example: create two Demand Sets, and lock one Demand Set
only. Now open the Local OD Matrix Data screen: the entry flows for the locked demand set will be
greyed out and disabled, but editable for the other demand set.
Although locking an Analysis set locks all signal timings, it does not prevent the timings
being changed if an optimised run is carried out. Furthermore, locking an Analysis Set does not lock
the data of the referenced demand set. Finally, if data is shared across sets these too can cause
changes.

Page 226
Optionally, you can assign a Colour to each Analysis and Demand Set. Edit the colour by double
clicking the colour in the Data Editor or a Data Grid. The colours are used in the Data Outline and in
the main Analysis/Demand Set dropdown menus. In large files this can be useful to separate out
categories of Demand Set, whilst working with the file. (They are not used in reports.) In the simple
example below, each analysis set and corresponding two demand sets, have been assigned specific
colours.
You can overrule any colours in a file and force the appearance to be the same as that used in earlier
versions of TRANSYT by turning off Data Outline>Options>Sorting and Display>Colour
Analysis/Demand Sets. A corresponding option in File>Preferences>Colours controls this setting for
new files.
The Time Segment drop-down menu at the top-right of the main window contains an entry for each
time segment. Displaying any set of results and then selecting a time segment from this menu will
then show the results for that time segment. Generally, you cannot see data or results of all the
time segments at the same time, e.g. within the Data Editor, but generated reports can optionally

show results for all time segments and for the summary time segment. A few specific data items
show values for all time segments where there is space to do so, in order to make the data entry
process quicker.
By default, a TRANSYT uses a single time segment which is the same length as the entire modelled
period. You can view and edit this via the Data Editor (Network Options>Network Timings section)
or via the Main Common Data screen. By default, there is a single time segment of 60 minutes,
giving a total modelled time period of 60 minutes.
To split the 60 minute period into 4 time segments of 15 minutes each, simply edit the Time
Segment Length and Number of Time Segments values.
Time varying traffic flows are allocated to the network using OD Matrices or directly onto links,
allowing flows to be specified for each time segment (See section 14.1.1).
The flow data for all time segments is stored within the existing set of OD Matrices, i.e.
you should not create separate OD Matrices for each time segment. To enter the flows for each
time segment, use the time segment dropdown menu at the top-right of the main window.
After running such a file, the Time Segment drop-down menu will show an entry for each time
segment, plus a special Summary item. Displaying any set of results (network results, or results for
individual links) will then show the results for the chosen time segment.

Page 228
The Summary time segment represents an overall set of results for the overall modelled period.
Results are aggregated in various ways (some are summed, others are averaged, a few are weighted
by flow, etc.); you can check these by using the Help>Glossary Screen option and clicking on any
result in the Data Editor. Not all data/results are available for the Summary time segment.
When running a file, the “Best PI” reported in the “Running Calculation” dialog and the
Summary Results P.I. will not match. This is because the “Best P.I.” value reported is always the
value used by the optimiser which is the TOTAL P.I. of all of the time segments combined. The value
shown in the Summary Results screen will be either the AVERAGE P.I. of all the segments or the
value of a currently selected time segment.

Many screens respond to the Copy and Paste buttons on the main toolbar. The format of the data
depends on the screen but can easily be seen by pressing Copy and then pasting the clipboard
contents into a spreadsheet or any text editor.
In addition, many screens respond to the Edit>Copy/Paste All options. These options select each
Demand Set on turn and then copy or paste data from the active screen. In this way, a collection of
data representing all Demand Sets can be pasted into a spreadsheet and edited within the
spreadsheet for subsequent pasting back into TRANSYT.
if you use this system to edit data, you can only edit the numerical values. You cannot
change the names or the structure of the Demand Sets.
To use this system, firstly go to the OD Matrix screen. If necessary, go to the tab within the screen
or click on a particular data grid. Then click Edit>Copy/Paste All to show the “Copy/Paste All” screen.
Choose an option and then click <Go>. If copying, the data will then be available on the clipboard
for pasting into another application or another TRANSYT file. If pasting, data will be taken from the
clipboard and pasted into the Demand screen (or whichever screen was active).
Only the data for the active tab within the OD Matrix Data screen will be copied, so for
example, if you want to copy both Entry Flows and Resultant Flows, this will require two copy and
paste operations.

Page 230
Current Demand Set, all time segments:
This operates on each time segment for the

currently active Demand Set. It is only useful if
the data of interest actually varies over time,
i.e. there is more than one time segment.
Data pasted into Excel from the O-D screen

will look similar to the example in the
screenshot. Immediately after pasting into
Excel it is useful to change the colour of the
pasted area. This makes it easy to identify the
area to be copied back into Junctions 9 later, if
required.
The numbers for all time segments can be

altered in Excel and then pasted back using the
Paste option, as long as exactly the same area
is copied from Excel, including all header
rows/columns and any blank rows/columns
that were included in the original operation.
Current time segment, all Demand Sets:
This works on data for each Demand Set, for

the current time segment. If the data does
not vary over time, then data will be for the
whole period.
Data pasted into Excel from the O-D screen

will look similar to the example in the
screenshot.
All Demand Sets, all time segments:
If data varies over time, then this option will

copy/paste data for each time segment, for
each Demand Set. Time segment data is
shown in rows, with each Demand Set in a
different column.

To use these features the file must be in Advanced Mode.
You may have traffic count data in Excel spreadsheets organised in such a way that makes it difficult
to copy and paste into TRANSYT. In this case, you can configure TRANSYT to read in data from
certain cells in the Excel spreadsheet. Once set up, this can speed up the data entry process
significantly. The configuration is saved within the TRANSYT file and so you can subsequently use
the same TRANSYT template file to read in data from different versions of the same spreadsheet.
There is some trade-off between the time taken to set up the link versus the time saved when
reading the data. This trade-off depends on the volume and complexity of the data and whether
you re-use the same configuration for several files. In some cases it may be quicker to simply
rearrange the data in Excel and then paste into TRANSYT using the normal copy/paste functions, or
enter manually, rather than configuring this link.
NOTE: The units used will be those currently selected in TRANSYT. (See Units for data input).
The procedure is demonstrated in the following example. For illustrative purposes this example
uses most of the features of the system but you do not need to use all of these features; you may
well find that you can configure the Excel link in a much simpler way.
The example spreadsheet is shown below. There is a group of flows for each time segment, set out
in the form of an OD Matrix (A to A, A to B, etc.). Data in the same format is available for two time
periods – ‘AM Peak’ and ‘PM Peak’ on two worksheets.

Page 232
To set up TRANSYT to read in this example data, use the following steps.
1. Make sure that the Excel file is saved, but

not open. It is a good idea to make a
backup copy of the file.
2. In TRANSYT, add the required number of

Demand Sets, set the time-segment
length, number of time segments and
number of OD locations and so on.
3. Go to Data>Read data from Excel… to

show the configuration screen. At the top
of this screen, browse to the Excel file and
click Open. This should launch the file in
Excel, which ideally you should position so
that you can see both Excel and TRANSYT
at the same time. TRANSYT will show
‘Connected’ at the top of the screen until
you close the file, either from TRANSYT or
by closing Excel.
1. Activate the AM Demand Set and in the Excel sheet for demand set, enter the name of the
corresponding worksheet in Excel. Repeat for the other Demand Sets. (If there is only one
Demand Set, or if you simply want to read from the current active worksheet in Excel, then
you can leave this field blank.)

2. In this example, data for each time segment located in grids, one beneath the other. Choose
‘Offset’ for the Excel time segments source option, and then enter a value of 9 for the Y
(up/down) component of the offset. This means that data for each successive time segment
in Excel is located nine rows below the previous time segment. By entering different values
for X (left/right) and Y (up/down), you can tell TRANSYT that blocks of time segment data are
separated by other distances.
Alternatively if time segment data is located in the same position but on different
worksheets, then choose ‘Separate sheets’ and then enter the worksheet names as a
comma-separated list in the Excel time segment sheets box. Or, choose the ‘None/Manual’
option and then set up the references for each time segment semi-manually by using the
tools described further below.
The time segments data source option is only relevant if the OD data in TRANSYT
have been set to vary over time (i.e. multiple time segments). Otherwise, leave this option
set to ‘None/Manual’.
3. The next step is to tell TRANSYT which cells in the spreadsheet correspond to which
movement. (The options set in the previous steps will save you having to repeat this for each
time segment and demand set.)
For instance, the demand data for the U-turn movement ‘A-A’ is located in cell C5 of the
spreadsheet and so the entry for the ‘A-A’ movement in the grid in TRANSYT should contain
the value “C5” (or the fully qualified Excel reference such as “Sheet1!C5”).
Make sure that the AM Demand Set is active and select the first time segment from the main
program dropdowns. Manually type “C5” into the top-left cell in the grid in TRANSYT. You
will see that it is automatically converted to ‘AM Peak’!C5, i.e. the fully qualified Excel
reference is generated from the demand set worksheet name.
Choose another time segment and you should see that the Excel references are
automatically set to the appropriate row of the spreadsheet, for each time segment.
You can continue to enter all Excel references for each movement (for the first demand set
and time segment) manually, or you can use the methods in the next step to speed up this
process.
4. Make sure that the AM Demand Set is active and select the first time segment from the main
program dropdowns. Click Clear all refs to remove any existing references (i.e. clear the
grid).
Tick Set reference when cell clicked in Excel. Click on different cells in Excel and notice that
the current cell in the movements grid in Junctions 9 updates to show the cell address. In
this way you can click in the grid in Junctions 9, then click in the cell in Excel that contains the
traffic data for this movement, and populate the references grid.

Page 234
you may need to click twice when switching to Excel: firstly to activate Excel and
secondly to click the cell.
If you also tick …and auto-progress, then the movement grid will move to the next item as
soon as you select a cell in Excel. In this way you can quickly set up all movements by simply
clicking on them in Excel, one after the other.
NOTE: Turn these options off as soon as you have completed the grid, to avoid accidentally
later overwriting the grid.
Whichever method you use, after setting up all movements, the demand grid for the first
time segment for this example should look like this:
Selecting a different time segment will show the same references but offset down by one or
more cells.
5. References for the other Demand Sets are not set automatically but can be set in one go by
clicking Copy refs from this demand set into all other demand sets. The references for all
items will be same as for the first set, but using the appropriate Excel worksheet prefixes (as
you defined in step 1). For example, the OD grid for the PM Demand Set for the 0845-0900
time segment will look like this:
6. At this stage (or before) it is a good idea to check the references. Click Highlight referenced
cell in Excel and click around the movements grid in TRANSYT, and select different Demand
Sets and time segments. With Excel visible at the same time you should see the
corresponding spreadsheet cell highlighted in yellow for demand data. Excel will switch to
different worksheets if necessary.

Click the Highlight all cells button to highlight ALL references. TRANSYT will temporarily
replace the data in Excel with the corresponding TRANSYT movement references. (In Excel
you may need to temporarily change the formatting or widen columns to read the full text.)
This allows you to quickly scan the spreadsheet to check that the links have been set up
correctly, and is especially useful if the data in Excel is positioned around a diagram or
similar. The highlighted cells show the TRANSYT Demand Set ID followed by the time
segment and then the movement ID.
To remove the highlights, click Clear highlighting. (In case you accidentally save the Excel
file with these highlights displayed, it is a good idea to make a backup of the Excel file as an
initial step.)
7. Once you are happy with the references, you can proceed to actually read the spreadsheet
data from Excel into TRANSYT. To do this click Read Data. If all goes well, the O-D screen
should automatically be populated with the correct data, for all time segments and all
Demand Sets, as shown below for the first time segment and Demand Set for the O-D data.

Page 236
8. If you save the TRANSYT file at this point (or before) you can treat it as a template file and
re-use it to read data from other Excel spreadsheets (assuming they are in the same
format) and thus quickly create new TRANSYT files for different projects.
Instead of using the methods above, you can of course simply manually enter Excel
references for each movement as required.
Your Excel file may resemble the example below where traffic data is located around a
schematic diagram. This is no different from the previous example – the data just happens
to be located in different positions. (In this example there is only a single time segment, so
the Excel time segment source option would be set to ‘None’.)

Working with Traffic Flows Page 237
In TRANSYT, traffic flows can be entered by using the Data Editor and/or Data Grids, as with most
other data items. Alternatively Local OD Matrices can be used to automatically assign flows to
traffic streams (or links). This is particularly useful when you only have origin-destination data and
are trying out alternative scenarios where traffic flows are going to change. Full details of how to
use this feature is in section 14.4.
Traffic streams flows MUST be allocated using Local OD Matrices.
If a traffic stream (or link) is fed by other traffic streams (or links), then it has one or more sources.
If a traffic stream (or link) is fed by no other traffic streams (or links) then it is an entry traffic stream
(or entry link) and has no sources. However, TRANSYT still needs a mechanism for entering values
such as cruise speed and bus parameters for entries, and so in these cases, entries are considered to
have a default Entry source. A default source shows slightly different data compared to a normal
source.
In the example below, Traffic Stream 21/1 is fed by traffic streams B1/1 and A1/1, so Traffic Stream
21/1 has two sources: Source 1 [Stream B1/1] and Source 2 [Stream A1/1]. These can be accessed
via the network diagram or the Data Outline, and each Source has a set of properties such as the
Total Flow and cruise speed etc.
In the same network, Traffic Stream B1/1 enters the network from outside, and so is an entry traffic
stream. It has no sources. However, clicking on the Sources section of Traffic Stream B1/1 will show
the properties for this item’s default Entry (Source), such as the entry cruise speed etc. (NB Entry

Page 238
cruise speed means the cruise speed along the whole traffic stream for traffic using this traffic
stream as an entry into the network - NOT the speed at the entrance.)
14.1.1 Time-varying Flows

To use time-varying profiles, you must set up the Network Timings options so that there is more
than one time segment (Outline: Network options>Network timings>Number of Time Segments) -
See section 13.8. You can then use the Time Segment selection dropdown located at the top right of
the main screen to select each time segment.
Flows are entered either via OD Matrices or can be entered directly on each link when Local OD
Matrices are not being used. Each method is described below:
14.1.1.1 Time-segment Flows using OD Matrices
Open your OD matrix and then select the required time segment. You can then enter data in the
usual way for that particular time segment. Select each time segment in turn to specify your OD
flows. Make sure that you specify data for every OD matrix in the network and for every time
segment. Varying flows can be applied to either traffic streams or link structures that use an OD
Matrix to allocate traffic to the network. If using this method, you cannot also use the ‘direct’
method that can be used with a link structure.
14.1.1.2 Time-segment Flows entered directly on each link
Each link and source has a property called Profile Type (Outline: Link n>Flows and Link n/Sources)
that allows you to define what type of time-varying flow data you wish to enter.

Changing Entry Profile Type to GAUSSIAN will take the average Total Flow (rate) that applies over
the modelled time period and will apply a normal curve to the traffic profile so that it fits a pre-
determined distribution – as used in the ODTAB option in ARCADY, PICADY and OSCADY PRO. (This
only works if you are using at least four time segments, and ideally six or more.) This is a convenient
way to model a typical peak curve without having to enter separate flows.
If you require more flexibility you can choose DIRECT as the profile type. Separate Total Flows boxes
will then be editable for each time segment. (See screenshots.)
Please note that the GAUSSIAN option is only available using the method described here. The
DIRECT type is the equivalent to entering time-varying flows via an OD Matrix.
14.1.1.3 Running and examining time-varying flow results

When you run the file, you should see the varying flows reflected in the Calculated Flow Entering
Link result for each time segment, as well as varying queues, delays and performance indices.
Use the time-segment dropdown to see results for each time segment. You can also see the results
for a “Summary Segment” which represents the average across all time segments.
When optimising the results given will be those for the best timings found that minimises the
combined P.I. of the network for all time segments combined, i.e. it offers the best overall single set
of signal timings. It does not separately optimise each time segment.

Page 240
Launch this screen via the Links button on the main vertical toolbar. Details of the currently selected
item are shown. The current link can be quickly changed using the link list on the left.
Select the “Flows” tab to reveal a set of sub-tabs. The first sub-tab “Flows” displays the Total Flow
on the link. This is only editable if you are not using an OD matrix to allocate flows to that link. A
Flow Consistency Tool is also embedded into this screen – This is described in section 14.3.
Accessed from “Flows” tab of both the Links Data Screen and the Traffic Streams screen, the flow
consistency tool shows details for the currently selected traffic stream (or link) and updates as you
change item. (You can change the current item by clicking on the blocks in the diagram, and in this
way you can trace your way through the network. Double-click on any block to go to the link or
source in the Data Outline/Data Editor.)
Since flows for traffic streams can only be specified using OD matrices, flows within the area of the
network covered by each OD Matrix will automatically be consistent as long as all the required
TRANSYT paths exist. However traffic flows across the boundaries of OD Matrices can still be
inconsistent – This is where the Flow Consistency Tool is still useful.

The screen is designed to show the flows in and out of each traffic stream or link, and any
inconsistencies with those flows; and also acts as a map of which items are connected to the current
items. In the screenshot, the current item (i.e. the link last clicked on in the network diagram or any
other screen) is Link 15, and this is shown in the centre of the diagram. Traffic on Link 15 flows into
Links 43 and x11 and is shown on the right. On the left, are shown the upstream link (4).
All other numbers represent flows on the link and on its upstream and downstream links. Some
numbers are the actual entered values; other numbers (generally in brackets) are calculated values
and show the computed contributions from each link. For details, hover the mouse-pointer over
any block to show a fuller description.
In the screenshot above, a user has entered a total flow of 100 PCU/hr on link 15. However, the
total flow entering the link at its upstream end is specified as 218. Since link 15 is fed only by this
one link, there is clearly a discrepancy in the flows which shows up as a warning in the task list and is
also indicated in the consistency tool. The rectangular block representing Link 15 is coloured red,
and the upstream that could equally be wrong is also coloured red.
TRANSYT (internally) scales the upstream flows so that the total upstream flow matches that of the
total flow on link 15. These scaled numbers are shown in brackets (100).

Page 242
An amber colour is also used to indicate where a discrepancy ‘might exist’ (see screen shot below).
This is usually the case where traffic leaving a network has not been modelled on a particular exit
link. It is, of course technically OK not to model where leaving traffic goes when using a link
structure, but TRANSYT has no way to know whether or not it is simply traffic leaving or a genuine
discrepancy.
You can now see that Link 45 has a flow of 681 PCU/hr, and that it has two downstream links 17 and
18. A user has specified that 324 PCU/hr flows from Link 45 to Link 17. This is consistent with Link
17 total flow. The flow is also consistent with link 18 and hence the downstream rectangular boxes
are green. However the total flow out of 45 is only 353 as opposed to the specified total flow of
681. Therefore there ‘may’ be an inconsistency (hence the yellow rectangle on Link 45, but the
missing traffic may simply have left the network. To avoid this uncertainly you can model all leaving
traffic on exit links.
Such warnings are also shown as information items in the Task List. If TRANSYT considers the flow
difference to be too great, then these will be shown as warnings/errors, and red colouring will be
used in the diagrams.
You can also visualise all flow warnings and errors in the network diagram, by selecting the Flow
Consistency ‘other overlay’.

Using Local OD Matrices (Toolbar>OD Flows) allows origin destination (OD) flows to be specified and
automatically allocated to links or traffic streams within a TRANSYT network. This avoids having to
manually allocate flows (total flows and source flows) to each traffic stream or link. For traffic
streams this is the only way to define traffic flows. It is particularly useful when modelling signalised
roundabouts and other small networks where flow counts are not available but origin-destination
flows are.
Figure 14-1 A highlighted OD Matrix path
Local OD flow allocation requires the use of a number of network diagram ‘items’ such as “Local OD
Matrices”, “Locations” and “Paths”:
 A “Local OD Matrix” (Toolbar>OD Flows) contains traffic flows between Origins and
Destinations which are defined as “Locations” in TRANSYT. Usually each junction will need
its own OD Matrix, although closely-space junctions and small networks can also be made to
share a matrix. Sharing of local matrices by more than one junction should only be
considered when the movements of traffic defined by the matrix is already known or can

Page 244
be easily predicted. Furthermore, The use of a local matrix to allocate flows to many
junctions is likely to lead to a very large underlying network structure which will slow
model runs appreciably.
 A “Location” is a user-defined traffic entry and exit point into and out of a section of the
network. There can be any number of locations, and normally at least two. Although both
vehicles and pedestrian flows can be specified using the same local matrix, each location can
only be associated with vehicles or pedestrians – not both.
 A “Path” defines the continuous route within a section of the network related to an
OD Matrix. Each path starts at a location and ends at a location. Therefore, a TRANSYT
“path” is a defined sequence of links between an OD pair (i.e. between one origin and one
destination Location). It contains only links that are consistent, i.e. each item is downstream
of the previous item. When using traffic streams instead of links an underlying equivalent
(hidden) structure of “path segments” is used.
The number of path segments is likely to increase exponentially

with the area covered by a single local matrix, and this will impact
on the run times of the traffic model. It is therefore worth
keeping an eye on the number of path segments displayed on the
right-hand side of the bottom status bar. If this gets particularly
large relative to the size of your real network, you should
consider reducing the areas covered by each local matrix.
Wide-area flow ‘assignment’ requires the use of a number of network diagram ‘items’ such as
“Wide-Area OD Matrices” and “Wide-Area Locations”:
 A “Wide-Area OD Matrix” contains traffic flows between Origins and Destinations which are
defined as “WIDE-AREA Locations”. While individual junctions, or small groups of closely
spaced junctions will use a ‘Local OD Matrix, the WIDE-AREA matrix can be used to populate
a number of local matrices using a WIDE-AREA set of traffic data in the form of a WIDE-AREA
matrix. The WIDE-AREA matrix is specifically designed for when movements of traffic
defined by the matrix cannot be easily predicted, usually because of the size of the area in
which it covers, resulting in delay becoming a far more important factor in driver’s choice of
“path”. More than one WIDE-AREA OD matrix can be specified within a TRANSYT network.
 A “WIDE-AREA Location” is a user-defined traffic entry and exit point into and out of a
section of the network populated with traffic from a WIDE-AREA Matrix. WIDE-AREA
locations feed traffic into the network in such a way as to populate any local matrices that
are defined as being under a WIDE-AREA matrix’s control. There can be any number of
WIDE-AREA locations (but with a minimum of two per WIDE-AREA matrix).
14.4.1 Local OD Matrices, locations and paths

Local OD matrices and locations are created in a similar way to creating links, arms and controller
streams. This is described in section 11.9.6. The OD matrix must be created first so that the

locations can then be associated with the OD Matrix. Please note that deleting an OD matrix will
also delete all of its associated locations and paths.
OD Matrix Location
Locations and paths can also be created manually from within the OD Matrix Data screen by
selecting the relevant tab, and right-clicking on the first column of the grid. Locations are also given
a colour automatically, which can be changed here. These are used by the flow overlays in the
network diagram.
Figure 14-2 Locations (for links and traffic streams)
On the rare occasion that you wish to specify the links or streams of a path directly, you must first
switch off the “Auto Calculate” local matrix option. The paths can then be specified by editing the
“path items” comma-separated list of stream or link IDs from within the “Paths” tab. The order
must ‘make sense’ i.e. the order must match how the links or streams are connected in TRANSYT.
When modelling single junctions, the first link or stream of any path is likely to be an entry link or
stream and the last link or stream likely to be an exit (from the network) link or stream.
Note that it will be far easier if you let TRANSYT create the collection of all possible paths for you.
The Auto Calculate option will continually re-calculate all possible paths based on the Network
connectivity. All paths between OD pairs are created, except those removed due the OD Matrix
options set (described below). If a path already exists its existing data will be used. The program
will report how many paths have been calculated.

Page 246
Figure 14-3 Auto Calculate path options
With the Auto Calculate option switched off you can alternatively use the Calculate Paths button
which calculates all possible paths on a one-off basis and the Clear Paths button to delete them all.
Paths names automatically include the origin and destination e.g. “Path A to B”. See section 14.4.4
for an explanation of the allocation options that can affect the generation of paths.
Furthermore, when Auto Calculate option switched off, although you can still see flow volumes
reported in, say, the network diagram, these flows will not be kept up-to-date and they rely on you
manually allocating the flows each time a relevant change to the network structure or flows
occurred.
14.4.2 WIDE-AREA OD Matrices

WIDE-AREA OD matrices are created in a similar way to ordinary OD Matrices. See section 14.4.6 for
a typical order of construction. The WIDE-AREA OD matrix must be created before the wide-area
locations are, so that the locations can then be associated with the matrix. Please note that deleting
a WIDE-AREA OD matrix will also delete all of its associated WIDE-AREA locations.
WIDE-AREA OD Matrix WIDE-AREA Location

Also note that a wide-area location should never be attached to a local location that is not feeding
into an ENTRY traffic stream or link. If this occurs by mistake, the flows in and out of the wide-area
location will not be assigned to the local matrix and will show up as a wide-area flow discrepancy on
the "resultant flows" tab.
14.4.3 Allocation Mode

TRANSYT offers a number of alternative ways to allocate traffic from OD Matrices to the network of
traffic streams or links. These allocation modes are as follows:
For local OD Matrices there are the following options:
Path equalisation: Wherever multiple paths are defined from a location to another location the
traffic travelling along that path is by default split equally between them – as the allocation mode
name implies. This equalisation also takes account of the “Allocation Type” associated with each
individual path which allows fixed and percentage flow values to be set. No account is taken of the
number of lanes. See section 14.4.7 for details.
Lane Balancing: When selected, this mode allocates traffic flow to TRANSYT paths, for a given OD
pair, in such a way as to ‘balance’ the flow-to-saturation-flow ratio (Y values) on the first
downstream signalled part of each path that connects that OD pair. See screen shot illustrating its
effect.
Note: For non-signalled paths the balancing is based on the restriction at the first item downstream
of the feeding Location. For give-ways the balancing is also based on the max flow value, and hence
it is based on the geometry of the situation, and not on the available capacity. If an entire path is
unrestricted it will attract all of the traffic between the two OD locations. Where multiple
unrestricted paths exist, the traffic will be distributed between them.
Figure 14-4 Flow allocation mode comparison
Internal traffic streams are not balanced – see exception to this for CPDM flares on entries. This
mode is useful for modelling single junctions (e.g. crossroads, staggers and roundabouts). It takes
account of the saturation flow of each traffic stream (max flow for give-ways), while it is NOT

Page 248
influenced by the travel time through the junction – which reflects reasonably well the nature of
decision making required by drivers who are travelling through a single junction and choosing the
most appropriate path through it. For situations where flared junctions have been modelled
explicitly using separate “flare” traffic streams the balancing process is still applied, ensuring
sensible balancing is achieved on the approaches to junctions. Lane Balancing assumes full
utilisation of Quick Flares.
User Equilibrium: When selected, traffic is ‘assigned’ to the network using

TRANSYT’s User Equilibrium assignment model. TRANSYT automatically keeps
the path structure up-to-date, but unlike when the “auto-calculate” option is
enabled, it does not automatically add traffic flows to the network – To do that
you need to press the Assign flows from Local Matrix” button. This is because
the assignment process is significantly slower than the normal flows allocation
process which is almost instant. Any changes you make to the flows will
require the Assign flows button to be pressed again.
The user-equilibrium model is described in more detail in section 27.10.
The flow allocation modes provided simply ‘aid’ the process of establishing suitable
traffic flows throughout the network. Inevitably there will be some situations where the allocation
of flows by these methods will not be suitable and in such situations you have the freedom to
specify flows in a more direct manner.
For WIDE-AREA OD Matrices there is no choice of allocation process – it uses Journey Time
Equilibrium Assignment – More detail of this process is provided in section 27.10.
The Journey Time (User) Equilibrium method assigns traffic to paths using an iterative process
which assigns traffic in such a way that the cost to traffic on each of the alternative routes is
equalised. This mode is most appropriate when applied to larger networks where simply balancing
flows based only on degree-of-saturation would not be good enough. This option is currently only
available through the use of a WIDE-AREA Matrix which feeds a set of local matrices (see section
14.4.2). More than one WIDE-AREA matrix can be used in order to feed multiple sets of matrices,
within the one network. If a local matrix is connected to more than one wide-area matrix it should
be noted that the assignment process only allocates flows from a single wide-area matrix at a time
and any newly assigned flows will therefore replace those from any previous assignments. See
section 27.10 for more detail on the Assignment model.
14.4.4 Flow allocation and flow assignment options

The local OD matrix data screen and wide-area matrix screen both have a number of other options
that influence how flows are allocated or assigned – These are set from the Local OD Matrix “Local
Matrix” tab or the Wide-Area matrices’ “General” tab as follows:
Allow Looped Past Exit Locations: Select this option to allow paths to be created that pass an exit
location. This option applies to Local Matrices only. This option is OFF by default.

Allow Looped Paths On Arms: Select this option to allow paths to be created that travel through the
same arm more than once. Details of why this may be required are the same as described for the
following option. This option is OFF by default.
Allow Looped Paths On Traffic Nodes: Select this option to allow paths to be created that travel
through the same traffic node more than once. A typical example of this is shown in Figure 14-5 – A
path from location 1 to 2 can be achieved by travelling around the whole roundabout and exiting at
the last-plus-one exit, i.e. a ‘wrap-around’ path. This type of path is not auto-generated when this
option is OFF. However, in some situations, such as in networks containing banned turns or extra-
large roundabouts this may be a valid and or required manoeuvre for traffic, hence the provision
within TRANSYT to allow them to be created automatically. Note however that this option is on by
default – This is because the option “Limit paths by length” is set on by default, and this now serves
a similar purpose, in that it also removes ‘wrap-around’ paths.
Figure 14-5 Allow looped paths on traffic nodes
Limit Paths By Length: Select this option to allow only paths that are a user-defined
factor longer than that of the shortest path to be created. The shortest path for each
traffic type will always be created. This option allows you to more easily remove
unrealistic paths and hence improve your results and speed up runs of TRANSYT. This
option is ON by default. Disabled paths for each traffic type are accounted for in
order to ensure that the last enabled path for a given traffic type is never removed.

Page 250
Path Length Limit Multiplier: Paths longer than this number times the shortest path
(between two locations) will not be created. By default, paths longer than the
shorted by 25% or more will not be generated.
Limit Paths By Number: Select this option to allow you to specify the maximum
number of paths created between any two locations. Again, this allows you to limit
the number of paths to only realistic ones, and hence also speed up runs of TRANSYT.
Path Number Limit: Sets the maximum number of paths that will be created
between two locations. Care should be taken when using this option as too small a
number here could result in the removal of some genuinely realistic paths for traffic.
Limit paths by flow: Paths containing less traffic than the low path flows threshold
will be disabled, and the flow redistributed to an alternative path. If no alternative
exists, the path will remain enabled. This option helps to reduce the complexity and
size of the underlying network structure, and hence can speed up run times. See the
next two images which demonstrate the effect. Paths disabled in this way are
identified by examining the “disabled type” value, which is only shown when
necessary.
Low path flow threshold: This is used by the “Limited paths by flow” option. This is
the threshold below which path flows can be redistributed.
++
Figure 14-6 Limit paths by flow OFF

++
Figure 14-7 Limit paths by flow ON
Having set the path options, you will often want to check that the created paths represent genuinely
realistic paths for traffic - The easiest way to do this is to use the TRANSYT 15 path filter option to
display the paths associated with just one particular source LOCATION at a time. By selecting each
path in your filtered list, you can then examine the network diagram which will highlight all of the
traffic streams or links of the selected path. You may also find that the network diagram’s “flow
overlays” can assist in identifying unwanted or missing paths.
You will not see the effect of the wide-area assignment path options on what paths are
created until the next assignment of flows has been carried out, i.e. the paths displayed and their
associated path flows and path journey times are that of the most recently carried out assignment.
Validation of the specified OD Matrix data is carried out by TRANSYT, and any errors or warnings will
show up in the Task List. E.g. all specified entry links must exit; all specified exit links must exist;
paths must be valid; all specified links must exist; start and end Locations must exist. Invalid paths
are ignored by the OD Matrix Data screen.
14.4.5 Sharing flows between OD Matrices

It is sometimes desirable to be able to use the flows specified in one local OD Matrix in another
matrix. This facility is useful for when you wish to model two or more design variants of the same
single junction or network within the one file, i.e. where you want to ensure the flows in both
networks are always the same.
To do this, you need to set the “Copy Flows” option in the “Local Matrix” tab of the local matrix that
will be using the flows of another matrix, and enter which local OD Matrix you wish to take the flows
from. In the “Entry Flows” tab the usable cells in the grid will be greyed out to indicate that they are
now read-only and are taking their values from another matrix.

Page 252
14.4.6 Typical order of construction

The OD Matrix Data screen is simple to use, but may appear complex the first time you use it. To
help you familiarise yourself with it, below is a typical order of actions required to make use of OD
Matrices:
Creating the model:
1) Create your network structure (e.g. traffic streams or links, traffic nodes (optional) and
controller streams (e.g. using the network diagram) in the usual way.
2) Specify the Traffic Type for each traffic stream and link.
3) Add a Local OD-Matrix by dragging it from the network diagram’s bottom toolbar.
4) Add local locations (also by dragging from the toolbar) – one for each flow entry/exit pair.
Typically this would be one for each approach to a roundabout. Each location acts as both an
origin AND a destination, e.g. traffic entering on Arm A of a roundabout and exiting on Arm A
use the same Location. (See screen shot).
5) Add exit traffic streams (or links) if the network does not already have them. Exit streams
and links can be set as “unrestricted” types as they are not being used to model any
restriction to traffic.
Please note that for CTM traffic streams and links, the cell saturation flow will still restrict
traffic entering these, so should still be set appropriately (see section 19.3).
6) Connect each Location to the link (or stream) it is feeding. In that order
7) Connect each exit link (or stream) to its destination Location. In that order
Allocating and assigning the flows:
Before defining any traffic flows you should consider whether or not you wish to use TRANSYT’s
user-equilibrium assignment process. For larger networks the use of this method should be
considered.

If you are planning to use it (i.e. use a Wide-Area matrix) please skip Step 8 as your local OD flows
will be determined by the wide-area flow assignment process. Step 9 onwards should also be
deferred until after the assignment process has been completed.
8) Double-click on the Local OD Matrix and add your origin-destination flows – i.e. specify the
entry flows for normal traffic, buses and trams.
9) Set the local matrix options (within the “Local Matrix” tab) that influence what paths are
generated, e.g. “Allow looped paths on traffic nodes”, “Limit paths by length”, etc.
10) “Disable” any unwanted paths within your local matrices. N.B. With the Auto-calculate
button on, all possible paths from each location to each other location will be created
automatically. Please note that these will include U-turns (if possible with the given network
connections) and also possibly inappropriate ‘wrap-around’ paths (if the network is
complex), hence the possible need to disable some paths. (Tip: Use the filter option to
display the paths for just one source or one destination at a time – it will make it far easier to
see if you are missing any paths or have ones you want to disable.)
11) Set the required Allocation Types of each path (see section 14.4.7). Leaving a path as
“Normal” will leave the OD Matrix to allocate the available entry flow for that particular
origin and destination using the chosen Allocation Mode.
12) Check the resultant flows (these are the flows are will be applied to the Source and Total
Flow data of the relevant links and streams).
At the end of this process you should now have a structure that will allow you to change the entry
flows in the local ODMatrix and see these automatically assigned to the relevant traffic stream (or
link). An example of the use of an OD Matrix on a signalised roundabout can be seen in chapter 30.
After having set your Allocation Types (and associated data) for each path,
you should avoid changing any of the OD Matrix options that affect the generation of paths – These
are the three “Local Matrix” tab options starting with “Allow…” and the two starting with “Limit
paths…”, plus their associated “limit” values. This is because you are likely to lose your Allocation
Type data if the new collection of paths generated are different from before.

Page 254
A few extra steps required when using a Wide-Area matrix:
Please follow the additional steps 12, 13 and 14 below:
13) Add a Wide-Area OD-Matrix by dragging it from the network diagram’s bottom toolbar.
Wide-Area matrices are shown in the network diagram as large lime-green squares.
14) Add Wide-Area locations (also by dragging from the toolbar) – one for each flow entry/exit
pair. Typically this would be a set of locations surrounding an area (wide-area) containing
more than one local matrices (see screen shot). Wide-Area locations are shown in the
network diagram as small lime-green pentagons.

15) Connect each Wide-area Location to the one local OD-Matrix Location that it is to feed
traffic into. In that order. (See screen shot.) The local location MUST feed a set of ENTRY
links or traffic streams.
WIDE-AREA Location Local Location
16) Specify your Wide-Area OD Flows (see the section 14.4.8)
17) Assign your Wide-Area flows, therefore populating your local OD matrices with traffic flows.
Note that there is no automatic assigning of Wide-Area OD flows - Use the Assignment Tool’s
“Assign from Wide-Area Matrix” button.
18) Optionally, you may wish to check how the flows have been assigned and, if necessary, apply
“assignment cost weightings” to some traffic streams or links (see section 14.4.10). These
allow you to influence any subsequent assignment that you carry out.
14.4.7 Specifying Local OD Flows

Flows are specified in more-or-less the same manner for both wide-area OD matrices and local OD
matrices, but for details specific to Wide-Area OD matrices see section 14.4.8.
Flows are specified by filling in the Entry Flows matrices for normal traffic and for buses, trams and
pedestrians if needed. Totals from and to each Location are automatically calculated for you. If no
enabled paths exist between any two local locations, the corresponding cell in the matrix will be
shown in pale yellow to indicate that it will NOT be possible to allocate the flow in that cell. This
helps to ensure that your network structure is as intended. You can still type in your ‘desired’ flows
however as you can still enter data in the pale yellow.
Once the flows have been entered, there are local OD options that allow flows to be allocated to
streams and links. A slider is provided to shrink and enlarge the matrix in order to allow the matrix
to cater for the smallest and largest numbers of origins and destinations.

Page 256
Figure 14-8 Entry Flow (Local) Matrix
With the Auto Calculate option switched on TRANSYT will assign local OD flows to the created paths
for you. Total Flows and Source Flows are continually updated to reflect the newly calculated flows.
Only flows on enabled paths are affected – all other flow data is left as they are.
 When one path exists, flow (from one Location to another) is automatically allocated
 When multiple paths (from one Location to another) exist, you must specify how the OD
Matrix is to split the flow.
 The splitting of flows between multiple paths is based on the Allocation Type. The available
Allocation Types are as follows:
o Normal: Split OD flow using selected “Allocation Mode” (default: Lane Balancing)
o Fixed: User specified fixed flow on this particular path. The wide-area assignment
process will not overwrite fixed flows.
o Percentage: A percentage of the OD flow uses this path
o Disabled: This path is disabled, which prevents any flows being allocated to it, i.e. its
flows will be set to zero. N.B. this does not necessarily mean no flows are assigned to
the links or streams on that path, as other paths might assign flows (i.e. resultant
flows) to these links or streams.
 Negative flows can be specified, allowing you subtract flows from a base
set of flows, through the use of a composite set to represent the resulting
(reduced or otherwise) flows.

With the Auto Calculate option switched off, the Reset Flows button can be used to set all path
flows to zero. The “Allocate Flows” button applies the flows to the links and streams. The allocation
of flows to links and streams involves adding the path flow to each link or stream the path passes
through. Connector flows (i.e. source flows) are updated in the same way.
Entry links and entry traffic streams that have other traffic passing through them have their Uniform
flow value set to the entry flow and the Uniform flow Source Name set to the OD Name to make it
clear what has been done.
Figure 14-9 Path Allocation Type
After allocating the flows to streams and links the resultant flow and flow differences are displayed –
see the Resultant Flows tab.
Where discrepancies are detected between the entry flow and the resultant flow, two numbers are
displayed in each cell of the grid. The top number is the sum of flows on paths between the ODs.
The number in brackets represents any discrepancy (resultant – entry) between the entry flow and
the resultant flow (i.e. those actually applied to links and streams). Discrepancies between allocated
flows and Entry Flows can arise for a number of reasons, e.g. if the only path between an OD pair is
disabled, resulting in the OD flows having nowhere to be assigned to.

Page 258
Figure 14-10 Resultant Flows (with one discrepancy shown)
14.4.7.1 Flow Allocation Types Example

These screen shot figures shown here display how Fixed Flow, Percentage Flow and Normal
Allocation each work in a simple case.
Figure 14-11 Simplest OD Matrix
A single flow of 500 is specified from location 1 to location 2.

Figure 14-12 Fixed, Percentage and Normal Allocation Types
Traffic Streams 1, 2 and 3 each have a different Allocation Types. Traffic Streams 4 and 5 are set to
“normal” – the same as for Traffic Stream 3. The selected Allocation Mode in this example is “Path
Equalisation”
Figure 14-13 Network Diagram showing allocated flows
Traffic Stream 1’s total flow is 150 as it is has been assigned a fixed flow of 150.
Traffic Stream 2’s total flow is 125 as it has been assigned 25% of the original 500 flow.
Traffic Stream 3, 4 and 5 each have a total flow of 75, which represents the equal proportioning of
the remaining 225 flow, i.e. 500 – 150 – 125.
An example of the use of Local OD Matrices on a signalised roundabout can be seen in chapter 30.

Page 260
14.4.8 Specifying Wide-area OD Flows

Flows are specified by filling in the Entry Flows matrices for normal traffic, buses and trams. Totals
from and to each wide-area Location are automatically calculated for you.
Once the flows have been entered, you can assign the traffic flows to the network by clicking on the
“Assign from Wide-area Matrix” button. This will assign just the traffic of the currently selected
wide-area matrix and currently selected time segment (if multiple time segments exist). The
assignment process replaces any exiting flows within the local matrices that are within the wide-
area, which in turn distribute the traffic to the network in the manner defined locally.
A slider is provided to shrink and enlarge the matrix in order to allow the matrix to cater for the
smallest and largest numbers of origins and destinations.
Figure 14-14 Entry Flow (Wide-area) Matrix
The flows specified within the wide-area must be assigned to the local matrices before they can
have any effect on the final TRANSYT run results - Unlike the Local OD Matrix (Flow Allocation)
screen, there is no Auto Calculate option.
After assigning the wide-area flows to the local matrices, the resultant flow and flow differences are
displayed – see the Resultant Flows tab.
The top number is the sum of flows on paths between the wide-area ODs. The numbers in brackets
represent any discrepancy (resultant – entry) between the entry flows and the resultant flows (i.e.
those actually applied to local OD matrices).
You can see any disparity between the current Wide-Area matrix flows and those that have been
assigned to the local matrices by examining the Resultant flow tab. If, for example, you change a
wide-area flow value you will immediately see the discrepancy show up as in the resultant flow tab.
This discrepancy will disappear after having carried out an assignment, assuming the traffic has a
way of travelling from wide-area location to location.

Figure 14-15 Wide-Area Resultant Flows
Discrepancies between the entry flows and those that are assigned to the local OD matrices can
arise whenever the physical path between a wide-area OD pair does not exist within the network.
Fixed flows on local OD matrices will not be overwritten by the wide-area assignment process so this
can also lead to further OD resultant flow discrepancies.
Disabled local OD matrix paths are taken account of (since v15.5.1). This provides a mechanism for
the assignment to take account of, for example, situations where a particular movement of traffic is
only available to buses.
The assignment process will always replace Local OD matrix flows that are ‘covered’ by
the wide-area matrix and will leave untouched those that aren’t, i.e. traffic defined as travelling
within the wide-area but never entering or leaving it for example.
Figure 14-16 Wide-Area Paths

Page 262
You can check that the created paths represent genuinely realistic paths for traffic by opening the
“Paths” tab and using the path filter option to display the paths associated with just one particular
source and destination LOCATION at a time (see Figure 14-16). By selecting each path in your
filtered list, you can then examine the network diagram which will highlight all of the traffic streams
or links of the selected path. You will find the highlighted paths easier to see if you switch off the
lane “opaque” option, and switch off many of the diagram “show” options and the text sets.
You will not see the effect of the wide-area assignment path options on what paths are
created until the next assignment of flows has been carried out, i.e. the paths displayed and their
associated path flows and path journey times are that of the most recently carried out assignment.
An example file showing the use of Wide-Area Assignment of flows is supplied with TRANSYT. This is
a variation of the “TRL1 – optimised” network.
14.4.9 Editing multiple data items

Just like with Data Grids, you can edit multiple items such as OD flows, or allocation types by making
a multiple selection and right-clicking to select “Edit All”. Type the new value and press OK. Please
note that there may be a slight delay before the values are updated if changing a large number of
entries. When changing either checkboxes or dropdowns a small dialog screen will open, allowing
you to select the value you want to set the selected items to.
14.4.10 Influencing wide-area flow assignment

Although there are options to influence the wide-area paths created between each location pair,
once these paths exist, how much traffic uses each one is determined by the UE assignment of flows
from the wide-area OD matrix. If you have information that is outside of TRANSYT that you believe
will affect wide-area path choice, you may wish to influence the assignment process to favour
particular paths. This can be done by applying “assignment cost weightings” on particular traffic
streams or links (see Figure 14-17).

Figure 14-17 Assignment cost weighting
Assignment Cost weighting (%): Adjusting the assignment cost weighting (Figure 14-17) will allow
you to increase or decrease the assignment cost to any traffic passing through this traffic stream or
link, and hence will add to the cost of any assignment path that makes use of it.
The default weighting of 100% means the calculated assignment cost will be used unchanged; a value
of 0% will mean there will be no costs incurred on this section of any wide-area paths that pass
through it. Negative percentage weightings will cause more traffic to be assigned to any wide-area
paths that pass through this particular traffic stream or link.
Assignment costs are only ever used during the assignment process so they only
influence the wide-area assignment and have no direct effect on other TRANSYT costs. The effect
that using the assignment has on the flow volumes used by TRANSYT, of course will affect many
TRANSYT results.
14.4.11 Local OD Matrices and Demand Sets

Local OD Matrices can be used in conjunction with multiple demand sets. Different entry flows can
be specified for each non-composite demand set. Composite demand sets (i.e. those based on
other demand sets) automatically populate their OD matrices with the entry flows specified in the
individual demand sets which will automatically provide a valid “composite” set of link flows.
Therefore, to model composite demand flows, e.g. base + development, or separate flows (e.g. am
and pm peaks) multiple demand sets should be used.

Page 264
14.4.12 Connecting the network at Local OD Matrix boundaries
When using multiple OD Matrices within one network care needs to be

taken – Traffic streams and links must not be associated with more than one OD Matrix. This could,
for example happen when attempting to model two adjacent junctions where the exit traffic stream
(or link) of one is an entry of the other. This will generate an error on the task list. Either the
doubly-referenced item should be split with unrestricted links (or traffic streams) to avoid an
overlap between the two OD matrices or a single combined OD matrix used for both junctions.
It is also recommended that each OD matrix should be limited to two or three junctions as those
covering larger areas will result in a large underlying network structure that can slow TRANSYT
down significantly.
14.4.12.1 Right and wrong examples of Local OD Matrix boundaries

When connecting one junction to another, the simplest, most easily understood, and the
recommended method is shown below.
If using a wide-area OD matrix to assign traffic to local matrices, section 14.4.12.2 should also be
read, as an additional consideration applies in this case.
Figure 14-18 Adjoined matrices – This is OK and recommended.
Figure 14-19 Adjoined matrices – OK too, but see wide-area OD considerations

Figure 14-20 Adjoined matrices – This is OK also*
*Note how all the traffic streams on one side of the boundary are attached to one location and all
the traffic streams on the other side are attached to another location.
Matching the number of traffic streams and lanes either side of the boundary between one OD
Matrix junction and another avoids any possible confusion, but can result in unnecessary network
items being created. It is also possible to end one matrix and start the new one at an existing break
in the network structure, say, at a lane gain or lane drop along a carriageway as shown in the
diagram immediately above, or where a traffic stream splits from one two-lane traffic stream to two
one-lane traffic streams, but this can make it slightly harder to spot any anomalies between traffic
flows either side of the boundary.
Crossing boundaries (switching OD matrices) within a junction itself is highly likely to lead to
overlaps (which will generate errors) or wrong allocation of flows, so should be avoided.
Another consideration also applies where there is a dual one-to-one connection between two traffic
streams across a local boundary (as seen with Arm 1Ax and Arm C in the Figure 14-21) the use of a
single local location as in this example will have the effect of losing the separateness of the two
connections across the boundary. This means the total volume of traffic flowing across the
boundary will be consistent but there is no guarantee that, say, the volume of traffic on traffic
stream 1Ax/1 will match that of C/1. This is because traffic from location 1 (which is the sum of the
traffic from both traffic streams on Arm 1Ax) is being reallocated by whatever allocation mode is
currently selected for that local OD matrix – either path equalisation or lane balancing. As far as
location 1 is concerned it is equivalent to the situation shown in Figure 14-22.
Figure 14-21 Local OD boundary

Page 266
Figure 14-22 Equivalent OD boundary
Therefore, if you wish to preserve the consistency of traffic across the two separate traffic streams
you need to create an additional location on either side of the boundary - see Figure 14-23. This
allows traffic to leave one local OD matrix via location 2A and 2B and to re-appear T locations 1A and
1B. It will depend largely on the real situation you are modelling whether or not the preservation of
consistency between traffic streams is relevant.
Figure 14-23 Alternative local OD boundaries
The diagram below illustrates an incorrect modelling solution, where the middle traffic streams, 3/1
and 3x/1 fall outside of the Local OD matrices on either side. This situation will result in the flow
profiles across the boundary being lost. To preserve the flow profiles across a boundary the traffic
streams associated with the Local Matrices must be adjacent to each other.
Figure 14-24 OD Matrices that are not adjacent

14.4.12.2 Connecting the network at WIDE-AREA OD Matrix boundaries

The part of the network defined within a wide-area should not be within any other wide-area
matrices, i.e. no overlaps. The entire network does NOT have to be within a wide-area. All entry
and exit points to the wide-area should have a wide-area location in order to ensure that all traffic
entering and leaving the area are taken account of. If, for example an entry-point is missed, the
likely outcome is that the traffic flows associated with this will not be modelled as existing within the
model. If, for example an exit point is missed then any traffic requiring to exit at that point will also
be missing from the model (i.e. they won’t be assigned) and there exists an inconsistency between
the wide-area matrix and the flows within the network.
14.4.13 Normal traffic, Bus and Tram Data

Entry flows can be specified separately for normal traffic, buses or trams. This facility is to allow
buses and trams to be modelled separately when using a traffic stream network structure –
previously separate minor shared links would have been used instead. The traffic stream method
offers a simpler and more intuitive way to specify bus and tram flows.
Figure 14-25 Normal traffic, Bus and Tram Data
Before specifying traffic flows within the OD Matrix for each of the traffic type, the relevant traffic
streams and links must be defined as carrying buses or trams. By default all new traffic streams (and
links) are set to traffic type “Normal”, i.e. neither a bus nor a tram. To allow a traffic stream to carry
buses as well as normal (all purpose) traffic, the traffic type should be set to “Normal, Bus” (see
Figure 14-26). All combinations of Normal, Bus and Tram are allowed on traffic streams. Links can
carry only one traffic type.

Page 268
OD Matrix paths for a particular traffic type only exist based on the definition of the
Traffic Types on each traffic stream, i.e. there will be no bus paths until the traffic streams have
been set to carry buses such that at least one path between two locations has been made possible.
In the screen shot Figure 14-25 six bus paths have been generated, although the actual network may
well contain many more which carry normal traffic.
Figure 14-26 Traffic Type selection
Whenever separate bus and trams flows are specified, TRANSYT models their flow profiles
separately while still allowing the performance of each traffic stream to be reported, which may or
may not contain different vehicle types. As explained elsewhere, it also allows weightings, bus/tram
speeds (Outline: Traffic Stream n > Sources > Bus Free Running Speed) and bus/tram stop data
(Outline: Traffic Stream n > Buses > Stationary Time) to be specified and applied appropriately -
either to all paths using a particular traffic stream or to each separate path using that traffic stream
by using the Per Path facility (e.g. Outline: Traffic Stream > Modelling > Buses > Per Path).
14.4.14 Specifying additional traffic types

Although TRANSYT offers the ability to specify bus, tram and pedestrian flow data separately to
“normal traffic”, this is because it needs to model these traffic types differently and/or separately.
However, the traffic counts that you have available, may have been provided to you in a number of
different formats, e.g. as total PCU, total vehicles, vehicle mix (lights and heavies), etc. This ‘mix’ of
traffic types does not necessarily need to be modelled separately and hence a facility to allow such
data to be specified directly in TRANSYT exists. The facility allows you to specify a mix of traffic
types, each with an associated “PCU Factor”. The PCU factors allow TRANSYT to always use and
report the number of PCU or vehicles throughout the network.

In addition to the ‘core’ traffic types described in section 14.4.13 (normal traffic , bus and tram)
which each have their own “path” structure, the “normal traffic” type can be split into a number of
extra traffic types. The traffic flows of these new traffic types are summed together to give total
“normal” traffic flows. By default, the “normal” traffic type is represented by just one set of flows
under the name “normal”. This can be renamed and added to, so that, for example you could have
“light” and “heavy” as two categories which together represent the sum total of the “normal”
traffic, as seen the screen shot.
Figure 14-27 Additional (Normal) Traffic Types
14.4.14.1 Adding and Renaming Traffic Types
New traffic types are added via the Data Outline. The steps required are:
1. Ensure your data file is in “Advanced” mode (as this facility is an “Advanced” one).
2. Go to Data Outline: Network Options>Traffic Options>Advanced>“Normal Traffic
Parameters”.
3. Click the “Add a new Traffic Type” button (You should now see that you have TWO traffic
types).
4. Double-click on one of them and rename it to whatever you want.
5. Rename the other one as well. For example you might choose “Light” and “Heavy”.
Please note, that it is best to keep the name as short as possible, while keeping it
recognisable. This is because some GUI screens and output tables work better with short
names.
6. If using Traffic Streams, and hence OD Matrices to allocate traffic to the network, you can
now open an OD Matrix where you will see that the “Normal” traffic type is split into your
new traffic types, and an additional tab called “Normal (Total) is also present. This extra

Page 270
read-only tab simply reports the sum of the different traffic types flows that make up the
total “Normal” traffic.
Figure 14-28 Adding extra traffic types -before and after
Figure 14-29 OD Matrix with ‘Light’ and ‘Heavy’ traffic types
14.4.15 Specifying PCU Factors for traffic types

PCU factors are specified via the Data Editor (Network Options>Traffic Options>Advanced). Within
the “Parameters” section of each of the traffic types in the data outline. This includes the “Bus”,
“Tram”, “Normal” and any additional “normal” traffic types, such as those shown below.

Figure 14-30 PCU factor for each Traffic Type
By default all traffic types in TRANSYT have a PCU factor of 1.0. This means that regardless of what
input or output units you choose for traffic flow, the results obtained will be the same. This also has
the simple implication that when importing older TRANSYT files (that do not contain any PCU
factors), the flow data used and how it is used will remain the same as before.
If you choose to specify PCU factors other than 1.0 (i.e. provide additional traffic flow information)
the choice of traffic input units will then make a difference to the results as TRANSYT will interpret
the traffic flows differently depending on the units. TRANSYT never tries to convert the actual data
supplied – changing units only changes how they are interpreted. If the flows you’ve entered are in
vehicles, you need to tell TRANSYT this, by setting the correct units, and PCU factors.
TRANSYT internally always maintains both the PCU flow and vehicle flow based on the supplied data,
the chosen units, and the PCU factors, so that it can always report and use the right one for the right
situation- PCUs for its capacity calculations and vehicles for its queue and delay calculations.
If you save a file with flow units in “Vehicles”, please be aware that if the
file is subsequently opened in a version of TRANSYT prior to version 15.1.0, it will not recognise the
fact that the data is in vehicles. This will result in an inconsistency between the flow data and the
saturation flows (still in PCU/hr) which TRANSYT will wrongly assume are in the same units. The PCU
factors in the original file will also be lost, which has the effect of changing the results, as mentioned
earlier. We therefore recommend that anyone passing a file to someone else ensures they are using
TRANSYT 15.1.0 or later.
14.4.15.1 Setting PCU Factors with Links and without OD Matrices

If you are using a Link structure you can similarly set up extra traffic types as explained in section
14.4.14, give them suitable PCU factors, and allocate flows via the Local OD Matrices. The total flow
values and source flow values will be populated by the OD Matrix (using its aggregated total flow) in

Page 272
the usual way. The link PCU factors and source PCU factors are additionally populated for you by
the OD Matrix so these cannot be edited directly.
If you choose not to use the Local OD matrices to allocate traffic to the network, TRANSYT will still
only allow you to specify a single total traffic flow on a link. If you wish to specify traffic in vehicles,
you will need to set PCU factors for the total flow and for each source flow. This information is
required so that TRANSYT will know how to convert the flows from vehicles to PCU and vice-versa.
Of course, you can always work throughout with PCUs, in which case you can simply leave all the
PCU factors set to 1.0.
Figure 14-31 Specifying PCU factors for Links
14.4.16 Pedestrian Data

The specifying of pedestrian flow data is described in detail on section 15.3
14.4.17 Journey Times

The OD Matrix and Path information is used by TRANSYT to calculate point-to-point journey times
which is always available via the “Journey Time” tab in the OD Matrix Data screen. Selecting the
“Use For Point to Point Table” OD Matrix option will result in an additional Journey Time table
appearing in the Report. Journey times are provided for all vehicles combined and also separately
for normal traffic, buses and trams.

When the auto-calculate option is used, the OD Journey Times calculated will be the flow-weighted
average of all path journey times between each pair of origins and destinations. A path journey time
is the sum of the traffic stream (or link) journey time for links on the path.
Figure 14-32 Producing point-to-point journey timings
If auto-calculate is NOT enabled, the OD Journey Time calculated is simply an average of each of the
possible journey times between each pair of origin and destination, i.e. not flow weighted. A
warning is printed with the table in this case. This limitation is simply because, with auto-calculate
switched off, TRANSYT does not have enough information to determine the specific path of traffic
along each possible route. Of course, if there is, however, only one route possible between each
origin and destination the result will be the same as the weighted average described above. When
using traffic streams unique routes are, by default, used, so the results will be same irrespective of
this option’s state.
In addition to the point-to-point journey times, TRANSYT now provides journey times for each
individual path. Again, journey times are provided for all vehicles combined and also separately for
normal traffic, buses and trams. This allows you to quickly evaluate the performance of your
junction or network with respect to a particular movement and type of vehicle within your network.
Sometimes you may wish to estimate the journey time across multiple local OD
matrices. This is reported in TRANSYT “Collections” as a “Route journey time”, but
only if the items in the collection form a valid ‘route’. If valid the data item “Is Route”
will be ticked.

Page 274
14.4.18 Journey distances

In addition to Journey times, Local OD Matrices also report the distances between each pair of OD
Locations. This can be useful to those using the UK government’s “transport users benefit appraisal”
(TUBA) software.
Each distance is the total length of all the path segments that make up a particular path between a
pair of locations. When multiple paths exist between the same pair of locations, the distances are
weighted by the traffic that has been allocated to each path.
This information is made available by switching on the relevant option in Main Menu > Data > Model
and Result options… The data is access from the “Distances” tab within each Local OD Matrix.
14.4.19 Additional features

The only output associated with paths are journey times, and the optional point-to-point journey
time tables. If you wish to examine particular paths in more detail the option
Tools>Collections>Convert Path to Route can be used to convert the currently selected Path into a
TRANSYT Collection. This then gives access to the ‘Collection’-based results in the Report.

Working with Pedestrians Page 275
Although many of the TRANSYT facilities that are used when modelling pedestrians are described
elsewhere in this User Guide, this chapter brings together conveniently in one place most of
information you require to model pedestrians.
Since the development of a pedestrian behaviour model for Transport for London (TfL), TRANSYT
can now accurately model the behaviour of pedestrians at traffic signals. Pedestrians crossing
during the red man are derived by the new model, as well as saturation flow rates during the green
man. In order to offer this capability TRANSYT requires you to enter various pedestrian-specific data
relating mainly to the nature of the crossing, such as crossing length and crossing width as well as
some extra vehicular traffic movement data. Some of TRANSYT’s existing data such as signal timings
is also reused by the model. The following sections describe in detail the data required and the
processes that need to be worked through to model pedestrians in the best way possible.
The new pedestrian behaviour model extends the capability of TRANSYT such that it can predict the
number of pedestrians that will cross during the red man as well as during the green man, i.e. the
level of non-compliance is predicted. Because of this, the model is sometimes referred to as the
“walk on red” model – both in this document and in TRANSYT. This model allows a far more
accurate calculation of pedestrian delay than was previously possible when the model had to
assume that pedestrians would always wait for the green man. The addition of a model to estimate
the saturation flow during green means that the pedestrian delay calculations are further improved.
The model has been derived from research based on the extensive analysis of
pedestrian behaviour in London only. Therefore, anyone wishing to use it to model pedestrian
behaviour at signals outside of London should consider the appropriateness of doing so. Changing
the “Vehicle bunching scaling factor” can be used to assist with calibration of the model for specific
crossings.
There is currently no dispersion model specific to pedestrians, but if you wish to change the effects
of the standard dispersion model the parameters are accessible for each side of each crossing (i.e.
each direction of travel) from the “Advanced” section of the “Side” data.
Detail of the pedestrian behaviour model output is described in section 15.6.

Page 276
A pedestrian network is constructed exclusively of pedestrian crossing objects.
15.2.1 Pedestrian Crossing Object

Pedestrians are modelled within their own network of pedestrian crossing objects. Use of
pedestrian crossing objects removes any need to set up a complex link structure, and have a number
of significant advantages over using a link structure as they:
1. represent both directions of flow

2. model walk-on-red behaviour
3. calculate pedestrian saturation flow
4. improve visual representation in the network diagram
5. significantly reduce network diagram ‘clutter’
6. simplify the data entry process
An example of a pedestrian crossing object can be seen in Figure 15-1.
Figure 15-1 Pedestrian Crossing object

The pedestrian crossing object (Figure 15-1) is drawn in the network diagram as a single line with
blue bend handles at each end. When the walk on red model is active, a symbol is shown at each
side of the crossing – The three white triangles represents the kerb, while the single triangle on the
left represents an island (pedestrian refuge).
The crossing object has two “sides” that are identified within TRANSYT as “Side 1” and “Side 2”.
Double-clicking on one side or the other will take you to the data entry for that side, while double-
clicking on the line between them will allow you access to the overall crossing data. This data is
explained more in section 15.4, while there is more information about the network diagram crossing
object in section 15.6.1.

15.2.2 Setting up a pedestrian crossing or network of crossings

It is fairly common practice to use a single pedestrian link in TRANSYT to straddle the vehicular links
or traffic streams in order to represent a crossing’s existence and the average green time it uses,
when the intention is to not model the pedestrians using it. In order to model pedestrian accurately
in TRANSYT a number of steps are required as follows:
1. Firstly, you need to model the pedestrian flow in both directions. For this you use a single
pedestrian crossing object, which automatically models and represents pedestrian flow in
both directions. These can be added in the usual way from the network diagram’s bottom
toolbar or via the data outline.
2. Secondly, where there is an island you need to model the movement from the kerb to the
island separately from the island to the destination kerb, i.e. two pedestrian crossing objects
should be used.
3. In order to model accurately the coordination of pedestrian flow across complex crossing
types (Figure 15-5), you will also need to connect each of the pedestrian crossing objects to
each other using “pedestrian crossing connectors”. These connectors are made in the same
way as for other objects in TRANSYT, but are different because they have properties of their
own. The distances between the crossings are represented by the pedestrian connectors –
no links are needed, although the connectors themselves will need their length and cruise
speed specified. The default cruise speed of pedestrians is 5.4 Km/h (1.5 m/s).
4. Flow data also needs to be allocated to the pedestrian network using a local OD Matrix – see
section 15.3 for full details.
5. Finally, the pedestrian crossing object data needs to be set correctly for the crossing, for each
“side” of the crossing and for their associated conflicts with traffic – see section 15.4. Each
crossing “side” is used in TRANSYT as the ‘source’ of pedestrians (fed from an OD Location).
15.2.3 Collection of crossing scenarios

There are a number of different pedestrian crossing scenarios that TRANSYT can model. These are
best described by illustration:

Page 278
Figure 15-2 Approach with no island

Notice how a single pedestrian crossing object is used to represent pedestrians crossing in both
directions. The use of a Local OD Matrix to allocate flows to the crossing is not optional. The
equivalent link structure would have needed at least two links and if an OD Matrix was used, four.
Figure 15-3 Approach with straight-through island

Where an island exists the two movements - from-kerb-to-island and island-to-kerb - need to be
modelled separately (Figure 15-3). The platooning effect of the first half of the crossing and
progression of pedestrians to the kerb of the next crossing is taken account of in the model by
connecting the two pedestrian crossings together.
Figure 15-4 Approach with staggered crossing (and separate phasing)

Modelling of a staggered crossing (Figure 15-4) involves using two pedestrian crossing objects – one
for each side of the road. Unlike the straight-through island, the crossings either side of the island
are likely to be controlled by different phases as illustrated in Figure 15-4. The signal timings are set
up in the normal way. The connector between the two crossings is also created in the usual way.
The distance travelled and time taken by pedestrians to travel along the island between the
crossings is accounted for accommodated within the connector which requires both a length and
cruise speed to be specified.

Page 280
Figure 15-5 Split-approach with four crossings
The flexibility of the TRANSYT network structure allows it to model a wide variety of pedestrian
crossing situations. An example of a ‘complex’ crossing situation is illustrated in Figure 15-5 which
is a T-junction with a split approach on the arm of the T, and includes four separate pedestrian
crossings. Each crossing can be set up as described in the way described for the earlier examples.
The distances walked by some pedestrians to reach each kerb is not necessarily the same. In order
to ensure that reasonably accurate progression of pedestrians across the junction is achieved it is
recommended that fairly accurate lengths are specified on each pedestrian crossing connector.

15.2.4 Pedestrian Links (Imported only)

Pedestrian links, as used in versions of TRANSYT prior to 15, can be imported and tolerated, but no
new pedestrian links can be created within TRANSYT itself. These are most likely to exist only to
indicate the existence of a crossing and which phase it is controlled by - Usually the pedestrians
themselves are not being modelled.
When imported pedestrian links exist in a network the flows (pedestrians) on these links have a
nominal PCU value of 1.0. Wherever input or output values are show in figures in units of PCU (or
derivatives of) you should interpret these as Pedestrians for pedestrian links. It is not necessary to
assign a 'real' PCU value (such as 0.2) to pedestrians since they do not mix with other traffic, and it is
the relation between the stream's flow and its saturation flow that is important.
All results screens will show results for pedestrian links just as with vehicular links. In the report
pedestrian links are indicated using the letter ‘P’. As pedestrian links do not make use of the new
pedestrian behaviour model results associated with them should be interpreted with caution.
Unless pedestrian flows are very high, the delays and other results are likely to be very low.
However, the results still give indications as to the performance of the pedestrian links, and are
therefore a way of assessing and comparing provision for pedestrian passage. The Average Delay
result indicates the average time an average pedestrian has to wait to cross the road; the Queue at
end of Red represents the average number of pedestrians waiting to cross the road when the
pedestrian green signal starts.
The above all assumes that pedestrians cross only at the assigned crossing points and that they do
not display human characteristics such as giving up waiting, finding alternative crossing points,
crossing in gaps between vehicles or generally changing their minds. Because of this, we
recommend that you convert pedestrian links within imported files into pedestrian crossings as it
will allow you to more accurately model pedestrian behaviour.
Pedestrian flows for a pedestrian crossing object must be allocated using a Local OD Matrix. The
flows are specified in a similar way to vehicular traffic, but using the “Pedestrian” tab (Figure 15-6).
This allows one OD matrix to be used for both vehicular traffic and pedestrians.
The pedestrian tab will only be visible once there is at least one pedestrian crossing or
pedestrian link in the network.

Page 282
Although not necessary, it is also possible to use separate OD matrices for pedestrian and vehicle
flows.
Full details of how to allocate flows to TRANSYT generally is covered in other parts of the User
Guide, e.g. chapter 14.
Figure 15-6 Pedestrian flow and the OD Matrix Data screen
The “Local Matrix tab option “Allow Paths Past Exit Locations” will often need to be
switched off, as it will be fairly common to wish to model pedestrians passing pedestrian exit points
(i.e. other locations) before leaving the network. In Figure 15-7 note how pedestrians walking from
Location 8 to Location 5 will need to walk past Location 7 without exiting the network.
Wide-Area matrices and the assignment model can only be used for vehicular traffic.
Figure 15-7 A typical pedestrian network of four crossings

Situations where pedestrians from different locations (or other crossings)

merge onto one crossing or where pedestrians diverge from one crossing
to more than one location or crossing is allowed. However, pedestrian
crossings (and associated connectors) should not be used to form loops
within the pedestrian network. This will lead to inconsistencies in the
pedestrian flows values allocated to the network.
In the example shown in Figure 15-7 note how there is no loop formed as
there are no connectors between the crossings. They are connected only
via the locations.
Pedestrian crossing objects are either created by using the pedestrian crossing icon on the
bottom toolbar of the network diagram, or by creating a pedestrian crossing object via the data
outline.
Optionally, you can select “Allow Walk on Red”. With this option selected, TRANSYT will use a
pedestrian behaviour model which estimates what opportunities there is for pedestrians to cross
during the red man, and how often they will make use of these opportunities to cross. This offers
improved results compared with simply assuming pedestrians only cross during the green man
period.
Irrespective of whether or not you are using the walk-on-red model, you can specify the length of
the crossing. This input parameter can be ignored if you are not using the walk-on-red model and
also do not wish to model the progression of pedestrians through the network.
The data described below represents the requirements of the walk-on-red model. If the walk-on red
model is not used, then the data requirements are reduced and the unnecessary items are hidden
from view.
In addition to using the Data Editor, data entry can be carried out using a dedicated crossing data
screen (described in section 9.5), which is accessed from the main vertical toolbar.

Page 284
Figure 15-8 Pedestrian Crossing data
A pedestrian crossing object requires the following data items:
 “Length (m)” is simply the length of the crossing from a pedestrian perspective.
 “Cruise Speed (kph) or Cruise Time (seconds). This value should be set to the average speed
of pedestrians on the crossing. A ‘typical’ value for this has been provided as a default, but it
is recommended that this is changed when local information is available.
The walk-on-red model requires the following extra data items:
 “Number of lanes” are the number of lanes of traffic that pedestrians have to cross in one
go. Only include the lanes relevant to the pedestrian leg being modelled by the crossing
object, i.e. do not include lanes on the far side of an island as they are part of a separate leg.
 “Crossing width (m) is the distance between the two rows of crossing studs. If crossing studs
are not present the crossing width should be measured using your own judgement.
 “Vehicle bunching scaling factor” (%) can be used to calibrate the pedestrian model. The
value of this factor will affect the amount of platooning of the vehicular traffic passing over
the pedestrian crossing. A value of 100% will result in the default level of platooning to be
assumed. Values above 100% should be used to model where platooning of traffic is above
average.
Please note that the bunching factor’s effect on pedestrian delay will also depend on vehicle
flow and saturation flow. The calculated pedestrian delay depends on the availability of gaps
suitable for pedestrians to cross within. Furthermore, the availability of these gaps is
dependent on both the headway (derived from the relevant saturation flows) and also the
proportion of bunching.

Figure 15-9 Pedestrian crossing “Side” data
Additionally you need to specify data that is specific to each side of the crossing (see Figure 15-9).
As previously mentioned, one side of the crossing is nominally called “Side 1” and the other “Side 2”.
Where possible, when “Side 2” must have the opposite value to “Side 1”, this will be made read-only
on Side 2 and is set automatically.
The data for each side is as follows:
 “First Vehicle Direction” is the direction of vehicles that is immediately experienced as

pedestrians step off the kerb. The vehicle direction is either “Into Junction”, “Out Of
Junction” or “Isolated Crossing”. Note: This item should not be confused with the similar
value that is specified per conflict. The option “Isolated crossing” should be chosen where
the first vehicle direction is going to be “Into Junction” for both sides of the crossing, i.e.
when it is an isolated crossing.
 “Pedestrian Crossing Style” defines whether the link represents pedestrians about to cross
from the kerb to an island, island to kerb, or kerb to kerb. Note: Occasionally crossings from
island to island will exist. In these circumstances we recommend you choose which island is
the largest and treat it as equivalent to a kerb, i.e. select either kerb to island or island to
kerb.
 Pedestrian Look Direction” is the direction pedestrians have to look to see approaching
vehicles prior to stepping off the kerb, e.g. “Look Left and Right” should be selected if
pedestrians are crossing two-way traffic, i.e. when there is no central reserve.
The model also requires information about the type of pedestrians crossing. These are split into
four categories. Since the categories are mutually exclusive (by definition) the proportions will
therefore add up to 1, so only three of the four categories are required – the other is implied. These
are:
 “Pedestrian Under 18s” enter the proportion of pedestrians you consider are under the age
of 18 and not impaired.

Page 286
 “Pedestrian Over 60” enter the proportion of pedestrians you consider are over 60 years old
and not impaired.
 “Pedestrian Impaired” enter the proportion of pedestrians you consider are obviously slower
than you would expect them be for their apparent age.
Please use your own judgement when evaluation which category each pedestrian falls within. The
more pedestrians that are used to calculate these proportions the more accurate this particular data
item will be.
Additionally you will need to specify what signal phase controls the crossing, and also add a blackout
period on each pedestrian phase – see section 15.4.1.
Finally you need to set up what conflicts exists between pedestrians and vehicular traffic – see
Section 15.4.2. In this particular model vehicles never yield to pedestrians.
15.4.1 Signal Data

Signal data is set up for pedestrians in more-or-less the same way as it is for vehicular traffic (Figure
15-11). Full details of working with signals can be found in Chapter 16. You will need to reference
the controller stream and phase that controls it. The phase should be specified as a pedestrian
phase – Use the “View Signals” button to get to the phase data.
Figure 15-10 Controlling Phase

Figure 15-11 Phase data with blackout time
Setting a phase type as “Pedestrians allows you to set a phase “Blackout Time (s)” - This is the only
signal data requirement, over-and-above that of a normal vehicular phase, that is needed by the
pedestrian behaviour model. This value is used to calculate the effective green time for pedestrians
for use by the pedestrian behaviour model. Figure 15-12 illustrates how the blackout period
appears in the Timings Diagram – as a black extension to the end of the green period. Any other
‘effects’ that might influence the effective green time can still be specified using a relative start or
end displacement value in the usual way. These will be added to the adjustment already made by
the blackout time.
Figure 15-12 Blackout time and associated effective green

Page 288
15.4.2 Setting up conflicts

The pedestrian crossing object also requires the conflicts with vehicular traffic to be defined. Each
separate conflict needs to be defined. Conflicts can be added by selecting the Conflicts section of a
Pedestrian Crossing and then using the Add a new Conflict button.
The following data is required for each conflict (see Figure 15-13):
Figure 15-13 Conflict Data
“Controlling Type” select whether pedestrians are yielding to a LinkShare (major link + its associated
minor links) or to a traffic stream.
“Controlling Link/Traffic Stream” reference the link ID or Traffic Stream ID to which

pedestrians are giving way to. The pedestrian model works with both TRANSYT’s link network
structure and traffic stream structures, i.e. the opposing traffic can be represented by either
traffic streams or links.
“Vehicle Direction” is the direction of vehicles referred to by this conflict. The vehicle direction is
either “Into Junction” or “Out Of Junction”. This item should not be confused with the similarly
named “First Vehicle Direction”, as these values are used for completely different purposes.
It helps to know what this value is used for, as it helps you check you have chosen the
right option - This data tells TRANSYT which vehicular cyclic flow profile to use.
If “Out of junction” is selected, TRANSYT will use the cyclic flow into the downstream
link (or traffic stream). If “Into junction” is selected, TRANSYT will use the cyclic flow
of the combined outflows of the upstreams.

Where traffic conflicting with pedestrians is leaving the junction, you should
reference the traffic stream or link immediately downstream of the crossing and
specify the “Vehicle Direction” as “OutOfJunction”.
“Vehicle Saturation Flow” is required only if the vehicle direction is “Out of Junction”. This value
should be the estimated maximum flow rate at the point that the crossing exists. For “Into
Junction” situations this value is ignored as the required data can be gleaned from existing traffic
data.
“Vehicle clearance Time (seconds)” is the time for traffic, referred to by this conflict, to clear the
crossing. This is to ensure that a suitable offset in the flow profile at the crossing is used by the
pedestrian model. Where the traffic being fed into the controlling link is from several sources an
average value should be applied - Ideally a weighted average.
Please note that for larger junctions you may wish to introduce an additional ‘stub’ link
between the feeding upstream links and the downstream link (i.e. those either side of the crossing).
This new link becomes the conflicting link (as far as the crossing object is concerned). This will allow
the differing times it takes traffic to travel to get to a point where they are conflicting with
pedestrians at the crossing to be taken account of. However, this will only be necessary for the
largest of junctions where there are significant differences in the vehicle clearance times.
In TRANSYT you have the choice as to whether or not pedestrian delays contribute to the calculation
of the Network Performance Index and to the network results. For individual pedestrian crossing
“sides”, this is specified by using the “Modelling” Data option “Exclude from results calculation”
(Outline: Pedestrian Crossing n > Side 1 > Modelling”).
You have this choice irrespective of whether or not you are using the pedestrian walk-on-red model.
The only difference is that if you have chosen to use the walk-on-red model, it’s more likely you will
also want to INCLUDE pedestrian delay in the P.I. and hence influence the optimiser to provide
optimised timings that offer the best multi-modal performance.
Because “Exclude From Results Calculation” is specified on a crossing side by crossing side basis, you
can ensure that only those crossings you wish to influence the signal timings are included in the
calculation. Individual results such as delays will still be shown, but they will no longer contribute to
any of the network results.
A global setting for “Exclude pedestrians from results calculation” is also available for convenience,
so that you can exclude all pedestrian crossings/links from the P.I. calculation, no matter what the
local value is set to (Outline: Network Options>Traffic Options>Advanced).

Page 290
Additionally, if you do not want to model the crossings (i.e. you have only added
them to indicate their presence) the global option “Exclude pedestrians from traffic
model” can be set. When this option is set, no crossings in the network will be
modelled (i.e. no results for them), and this gives the benefit of slightly faster model
runs.
For those crossings sides included in the P.I. calculation the cost of pedestrian delay is calculated
using the “Pedestrian monetary value of delay”. (Outline: Network Options>Economics). See Figure
15-14.
Figure 15-14 Pedestrian Delay costs
Delay weighting (%): Adjusting the delay weighting (Figure 15-15) will allow you to increase or
decrease the cost of delay and hence importance given to the pedestrian delay on individual sides of
individual crossings. Higher values will encourage the optimiser to reduce delays if possible at the
expense of others.
Figure 15-15 Pedestrian gap-accepting penalty

Has Ped Gap Accepting Penalty: Additionally, the TRANSYT optimisers can also be influenced
through the use of cost penalties. When using the walk-on-red model a penalty can be applied to
the proportion of pedestrians over a user-defined limit that is crossing during the gap accepting
period. This period excludes the before-green and after-green periods (defined by the model). This
can be used to influence the optimiser to reduce this particular type of non-compliance with the
green man (and relatively safe periods either side) and hence potentially improve the safety of
pedestrians. Since the penalty is only applied to the excess, high penalty costs are usually needed.
You may also find that setting the limit slightly lower or higher than you want to achieve will help
you achieve the desired outcome.
Degree of Saturation Penalties: Although not part of the crossing object data, the use of degree of
saturation penalties may also be of use. Because the degree of saturation reported for each side of
the crossing relates only to the pedestrian green period (green man), the optimiser can be
encouraged to offer longer pedestrian greens by applying a limit to the DoS with an appropriate
penalty.
Max Queue Storage and Has Queue Limit: These two parameters work in exactly the same way as
those for traffic streams and links. They have been made to work with pedestrian crossings in case
they prove useful for particular modelling circumstances.
15.6.1 Pedestrian Crossing Objects

Pedestrian crossing objects are drawn in the network diagram in a distinctive way to ensure they are
easily recognised and they also have a number of unique features. An example of a crossing object
is shown in Figure 15-17.
Double-clicking on one side or the other will take you to the data entry for that side, while double-
clicking on the line between them will allow you access to the overall crossing data. Right-click
menus also exist for both the crossing and for the sides of the crossing that reveal a menu of useful
items, including the option to change some data items, reveal graphs and add, delete or copy the
selected crossing.
Mean Max Queues can be displayed using the same Top Toolbar Data option as used for vehicle
MMQs.
Figure 15-16 Pedestrian Crossing object with pedestrian MMQs

Page 292
The “Queues” network diagram overlay (Top Toolbar > Data > Queues) can be selected to display
average pedestrian queues at each end of the pedestrian crossings for the current time step – They
can be animated over time. Each queueing pedestrian is represented by a single red square. Up to
three rows of queueing pedestrians are drawn. The first two rows (nearest the kerb) expand to
contain a maximum of 6 pedestrians each, while the back row contains the remainder of the queue.
The “Flows” overlay displays the flow of pedestrians across crossings and along connectors between
crossings. When animating flows over time, the pedestrian flows in each direction (green blocks)
are kept separate by displaying them on the top and bottom of the line that crosses the road as
shown in Figure 15-17.
Figure 15-17 Pedestrian Crossing object with pedestrian queues and flows
The “Traffic” overlay displays both queuing pedestrians and pedestrian flow over time.
The bars at either end of the crossing indicate the state of the signals, and the direction that
pedestrians have to look when crossing (as specified by you) is also indicated.
The “Flows” overlay displays only the moving traffic, i.e. no queues.
Both of these overlays distribute the flow across both the connectors and the links and traffic
stream lengths. This enhances the animation of flows such that the conflict between pedestrians
and vehicles can be more easily seen. See Figure 15-18.

Figure 15-18 Conflicting pedestrians and vehicles using PDM Cell Flows
TRANSYT pedestrian results are presented in the Results section of the data outline as follows:
Results are presented for each of the two sides of the crossing – the point at which pedestrians can
experience delays to their journey.
A “pedestrian summary” contains a collection of some of the key output values associated with the
crossing. The remaining sub-sections over similar results to that for vehicles. When using a data
grid to examine the results for all pedestrian crossings, TRANSYT automatically filters out all but the
pedestrian crossing data. (See Figure 15-19).
All summary items also appear in the other topic-based sub-sections.
Figure 15-19 Presentation of pedestrian results using a Data Grid

Most output values related to pedestrians are shown with the appropriate units.
However, wherever TRANSYT refers to input or output values as “per PCU” or “PCU/hr” where they

Page 294
relate to both vehicles and pedestrians, these should be read as “per pedestrian” where it is
appropriate to do so.
The key outputs that are unique to the walk-on-red model are as follows:
Calculated Sat Flow (Peds/hr)
The pedestrian saturation flow is the maximum rate at which pedestrians cross when opposing
traffic is stopped and it applies to the GREEN+BLACKOUT period. The pedestrian saturation flow
increases with the numbers of pedestrians waiting to cross. To ensure that unreasonably high
saturation flows are not used, the pedestrian saturation flow is also capped. The cap is based on the
crossing width and an assumed upper limit for pedestrian flow of 82 persons per minute per metre
(Department for Culture Media and Sport, 2008).
Flow during Green (Peds/hr)
Flow during After Green (Peds/hr)
Flow during Gap Accepting (Peds/hr)
Flow during Before Green (Peds /hr)
The above four flow rates are shown only for pedestrian crossings using the walk-on-red pedestrian
model. The cycle is split up into four different time periods each representing a significantly
different scenario for pedestrians wishing to cross. The flows indicate the predicted volume of
pedestrians crossing during each of these periods. The time periods are calculated internally within
TRANSYT. N.B. “Green” is a reference to the green man period.
Ped Gap Accepting Penalty (£ per hour) – shown for pedestrian walk-on-red links only
This is the penalty cost added to the P.I. as a result of the level of pedestrian gap-accepting set by you
being exceeded.
For full details of the TRANSYT results see section 22.2.
15.6.2 Pedestrian Links (Imported only)

Links which are defined as pedestrian links can only exist within TRANSYT from having been
imported from an existing file. This capability is retained simply to allow pedestrian crossing data to
be retained. It is recommended that such pedestrian crossings are remodelled/replaced using the
new pedestrian crossing objects. Pedestrian links that imported are drawn differently in the network
diagram in order to differentiate them from ordinary (vehicular) links. A white arrow is used to
indicate the direction of travel of pedestrians represented by the link. Example shown below:

Working with traffic signals Page 295
This section briefly describes some important points to be aware of when working with signals in
TRANSYT 16, especially for users who may be used to earlier versions of TRANSYT. For more general
concepts, and background on the TRANSYT signals optimiser, please see elsewhere in this User
Guide.
Signals data can be viewed and (in some cases) edited using the Data Outline and Data Editor, as
with any other data. In addition, several screens provide graphical viewing and (in some cases)
editing. These screens are the Timings Diagram, the Stage Sequence Diagram, and the Intergreen
Matrix screen. Timing Wheels also offer stage editing and viewing within the network diagram.
We recommend using the Timings Diagram and accessing stages and link green periods by clicking
and double-clicking on the relevant parts of that diagram. Individual Timing Wheels (see 16.4) are a
useful way to view and edit stage timings within the network diagram. Finally, the signals data
screen (see 9.2) is particularly useful for defining all aspects of your signal timings quickly and easily.
16.1.1 Network (Default) Cycle Time

Controller streams, by default, use the network cycle time (Outline: Network Options>Network
Timings). The cycle time defines the rate at which controller streams throughout the network
repeat their stage sequence.
The “Restrict to SCOOT Cycle Time” allows you to limit your selection of cycle time to those
compatible with SCOOT. An error will appear on the task list when this option is set and the time is
not compatible.
For details on Time Segments see section 13.8.

Page 296
16.1.2 Signals representation

TRANSYT has adopted a single straightforward approach to representing signal timings in a way that
matches the data traffic engineers or planners will generally have to hand and helps to ensure that
novice users set up their signals correctly. Generally, the Signal data entered, such as phase
constraints and intergreens, act as a set of constraints on what stages, stage sequences, and signal
timings are possible and valid. Various tools are provided to generate suitable staging arrangements
and valid timings. These valid phases, library stages, sequences and associated timings can be
viewed and edited graphically.
A controller stream object exists that contains all the signal timing data, such as phases, library
stages, stage sequences and signal timings. Under the Properties controller data item, additional
non-modelling data can also be stored, such as manufacturer, model, site number, etc.
A phase is a separate item within the controller stream which has its own properties. Signalled
controlled links and traffic streams reference the phase(s) that control them.
The screenshot below shows the TRANSYT Timings Diagram.
Stages are shown in blue and interstage periods are shown as blank areas. Interstage times are
derived from the phase-to-phase intergreens that you specify. The Intergreens show up as green
diagonal lines. The stage start and end timings are written along the top of the diagram, along with
the duration of each of the stages (in seconds) in brackets. Interstage values are also shown, in
brackets, between each stage.
Phase green times can extend beyond stage starts/ends via link-losing or gaining delays. The
diagram can be edited using the mouse, while certain data may also be entered numerically such as
phase delays, which phases run in which stages, stage end times, and even the stage sequence.
Note that in this example; stage 5 ends as soon as the first phase (phase L) running in that stage
ends, as is consistent with standard stage definitions, and phases C and D have 8 second phase-
losing delays. Similarly both stage 1 (phase B) and stage 2 (phases A, E and F) have phase losing
delays.

16.1.3 Actual / effective greens

In TRANSYT, actual greens and effective greens are explicitly shown as separate values, wherever
possible. In TRANSYT, stages and link timings are always viewed and manipulated using actual
timings. Optionally, you may overlay the effective timings, which are shown in the Timings diagram
as lighter coloured bars above each actual green block. In the screenshot below, each link’s
effective green starts and ends a few seconds after its actual green.
16.1.4 Dummy Phases and Dummy Links

If you wish to explicitly model separate stages even if no new phase begins, TRANSYT will allow you
to do this. Therefore, this particular reason to use dummy links in versions of TRANSYT prior to
TRANSYT 14, is no longer required. Defined stages will be preserved even after optimisation and will
not be deleted or merged together, i.e. stages are regarded as sacrosanct.
The TRANSYT optimisers do not optimise phase delays. However, if the optimisation of
a particular phase delay is critical to your requirements then this is possible by modelling it as a
separate stage. In the example above, stage 3 has been created to model a phase losing delay on
stage 1 (phase A). TRANSYT will optimise this extra stage like any other stage. Care should be taken
with respect to intergreens when using this method.

Page 298
16.1.4.1 Dummy Phases

You can define any Phase as a Dummy Phase (Outline: Controller steam n>Phases>Phase n> Type).
This is useful when you will wish to define an actual Dummy Phase (i.e. a phase that exists only in
the signal controller and is not connected up to any traffic signals). When this property is set, the
phase will show up in a special colour in the Timings Diagram (see Phase A in screen shot), and
warning messages will occur if you subsequently add a non-dummy phase to the same stage in
which the dummy phase is running.
16.1.5 Global vs relative start/end displacements

In TRANSYT, global values for start and end displacements are set up using the Data Outline in
Network Options>Signals Options. These affect every signalised link in the network. In addition, the
green periods of each phase can have its own Relative Start/End Displacement entered, which will
be added to the global values. If a phase had more than one green period, the relative
displacements will apply to all of them.
16.1.6 Amber times

An “advanced” option allow you to set a network-wide starting red-with-amber time (Outline:
Network Options>Signals Options>Advanced) and for each phase, an end-of-green amber time
(Outline: Controller Stream x > Phase x).
When the amber options are enabled via the Main Menu > Data > Model and Results options the
amber times will be displayed in TRANSYT for all phases except pedestrian phases, in the following
locations:
 Data Outline / Data Editor

 Timing Diagram (see the following screen shot)
 Network Diagram Animations (whenever any signal states are shown)
 Report (in the Signals > Input > “Phase Data” table)

For details of using amber times in the Intergreen matrix please see section 16.5.6.
16.1.7 Controller Streams

TRANSYT uses (signal) controller streams rather than a signal controller object. A signal controller is
represented by a collection of one or more controller streams, i.e. a signal controller with parallel
stage streams would have multiple controller streams. Each controller stream will control one
junction (or part of a complex junction, such as a signalised roundabout or a linked staggered
junction).
The TRANSYT controller stream contains all the signal control data associated with the junction (or
part thereof) it is controlling.
16.1.8 Stage Library

Each controller stream has a Stage Library (Outline: Controller stream n>Stage Library) which
contains all the stages that currently exist within that controller stream. Library Stages can be
defined manually or you can use “Auto Generate Library Stages” either from the Signals Data Screen
or from the Tools menu of the Timings diagram to generate a full set of all possible valid stages. To
manually define which phases run in a stage either enter a comma-separated list of phases that run
in that stage or use the Stage Sequence diagram to redefine the stage.

Page 300
The redefining of a stage within a particular sequence will change the definition of the library stage
and hence the definition of any sequence that uses that library stage too. If you do not
want this to happen then create a brand new stage first and then reference that in your sequence.
If any of the stage IDs referenced in the current stage sequence do not exist, this will result in an
error, preventing TRANSYT from running until either the reference to the missing stage is removed
from the sequence or the stage added to the library.
The nominal ‘first stage’ in the current stage sequence is indicated by a ‘+’ sign next to the
sequence.
16.1.9 Stage Sequences

Each controller stream has a current Stage Sequence and also a set of alternative stage sequences.
The currently used sequence is indicated in the Data Outline, Timings Diagram and the Stage
Sequence Diagram with an asterisk. The current sequence is a property of the controller stream and
can be changed at any time to reference/use a different sequence - This can be set quickly via the
Tools menu of the Stage Sequence Diagram. The selected sequence must exist for TRANSYT to run.
A missing sequence will NOT be generated for you (unlike referenced Stages within the current
sequence).
Stages Sequences can be defined manually or you can use “Auto Generate Sequences” either from
the Signals Data Screen or from the Tools menu of the Timings diagram to generate a set of the top
ten shortest sequences. For details of other stage and sequence generation options please see the
Timings Diagram (section 16.3).
To manually define which stages run in a sequence either enter a comma-separated list of stages
(Outline: Stage Sequences/Stage Sequence n) or use the Stage Sequence Diagram to re-define
stages, add new library stages to the sequence or re-arrange the order of existing ones. For full
details on how to do this please see section 16.7.

16.1.10 Stage numbering

Like many items, stages have IDs. The stage number is simply the stage number. For any operation
where TRANSYT requires to automatically generate a stage TRANSYT will simply choose the next
available number stage numbers starting with stage 1 (i.e. if stages 1 and 2 already exist TRANSYT
will create a stage 3, and then a 4 if necessary, and so on.
16.1.11 Base / non-base stages

If a controller stream is double-cycled then each stage is repeated twice during each cycle. (In
TRANSYT, controller streams can also be triple or quadruple cycled.) When viewing diagrams and
data in TRANSYT, a distinction is made between the ‘original’ stages, and the repeat stages. The
original stages are referred to as base stages, and can be edited and deleted etc. When the file is
run, TRANSYT will add non-base stages, which cannot be edited. Non-base stages are drawn in
fainter colours in the timing diagram, as shown below.
The screenshot below also shows that, at this double cycled node, there are six stages: 3 base stages
plus 3 non-base stages. You will notice how the stage sequence is repeated.
16.1.12 Full optimisation vs evaluation mode

You may either run the signal timings exactly as you enter them, or you can enter an initial set of
timings and then optimise them.
To run timings exactly as you enter them (evaluation mode), use the main menu “Eval Run” button.
(This is equivalent to turning off the Enable Optimisation option either in the Main Data screen or in
Outline> Network Options>Optimisation Options.)

Page 302
To optimise timings, select Enable Optimisation, and chose the Optimisation Level you wish to use.
To read more on optimisation levels go to section 28.2.2.
If you turn on “Auto Distribute” then TRANSYT will also calculate an initial set of timings which it will
then subsequently optimise, instead of simply optimising the current set of timings. By using “Auto
Distribute”, you can leave all signal timings at arbitrary values, and only need to specify which
phases run in which stages, define a stage sequence and set the controller stream to reference that
sequence.
For information on the use of the “out profile accuracy” parameter go to section 28.2.3.
During optimisation TRANSYT does not attempt to calculate the actual stage order or
which traffic stream and links should run in each stage. However, various tools are available in the
Timings Diagram which allows sequence and stage orders to be optimised if required, similar to the
facilities provided in TRL’s isolated junction design and evaluation tool - OSCADY PRO.
16.1.13 Common errors

The Task List may show errors such as:
1. Controller Stream 1 Stage 2 starts too soon to allow for required interstage length of 30s.
The interstage is derived from the intergreens and phase delays so it is these that should be
checked first if this error message appears. Clicking the “Repair timings” will usually fix this.
2. Controller Stream n Stage m minimum green 7s violated
For such controller streams, check that the relevant stage has a minimum green defined, and
extend the green time until this minimum is satisfied. Alternatively use the “Repair Timings”
button on the Timings Diagram to redistribute the green periods.

3. Start and end lags (including displacements) are such that green period could violate stage
min greens. Does the start lag (including displacement) exceed the stage minimum? Is the
stage minimum zero?
For such links, check that the relevant stage has a minimum green defined, and that this
minimum green is not so short that the stage could run for less time than the link’s start lag.
(This would mean that the link could start after the stage finishes.)
4. Controller Stream n: Minimum required cycle time is YYYs which exceeds network cycle time
of ZZZs
This coomonly occurs immediately after having changed the current stage sequence from
single cycle to double, triple or quadruple cycled. If you wish to keep your multi-cycling
selection you will need to increase the default cycle time.
The various parameters used to defined signal timings are described here, in no particular order, by
means of a few simple examples. We suggest experimenting by using the Signals Data Screen and
Timings Diagram, and entering various data.
16.2.1 Timings with and without phase intergreens or phase delays

Phase intergreens and phase delays are an integral part of defining signal timings, as they act as
constraints on the TRANSYT optimiser, as well as on what timings are deemed to be valid or not.
They also affect the behaviour of the Timings Diagram as the manual manipulation of the timings
(phase green periods and stages) will be influenced and restricted by them. They, in effect, define
the transition from one stage to another.
The example diagram below shows timings within the Timings Diagram. It contains no intergreens
or phase delays. You will notice that there is no gap between stage 1 ending and stage 2 starting. In
order to introduce a delay between one phase ending and another starting you need to either
specify an intergreen (using the Intergreen Matrix - shown in the diagram) or specify a phase gaining
delay (see section 16.6), to model the fact that a phase is to start later than would otherwise be the
case - Phase B in this example.

Page 304
In TRANSYT the gap between the stages will either have to contain a phase delay or an intergreen as
shown below.*
or…
It is up to you whether or not they specify a full set of intergreens or just those related to the phase-
to-phase transitions that are active. It is however, often useful to define a full matrix as it will mean
that subsequent changes to stage orders can be achieved with relative ease. Furthermore, a full
intergreen matrix is required if you are planning to use any of TRANSYT’s phase and stage order
optimisation features.

The following example shows the timings for controller stream 1 after phase optimisation.
 The current stage sequence is indicated by an asterisk next to the sequence
 The stages of the current stage sequence are shown using blue blocks. Stages of unused
sequences are shown in yellow, while interstages are shown in light-brown. The colour
scheme makes it more obvious what you are looking at.
 Stage 1 runs from 25s to 53s; Stage 2 runs from 58-15s (rapping around the end of the
diagram).
 Phase C has a phase-losing delay of 5s (shown by the darker shading) If a phase was to start
later than the other phases running in that stage a phase gaining delay would be needed.
 TRANSYT stores phase gaining and losing delays explicitly in the data file. This allows them to
be created, deleted and edited both graphically and directly. (See screen shot of phase delays
below.)
 When the file is run, the intergreens and phase delays will maintain the gaps between the
stages, as they act as constraints on what the optimiser can do. In this example all the
optimiser can do is rotate the diagram (i.e. change the offset) or extend the length of one or
more stages at the expense of one or more of the remaining stages.

Page 306
In the screen shot above phase A is now adjusted to start at 9s later than it needs to, it is shown
with a phase-gaining delay (the dotted line, in the diagram above). This particular gaining delay is
specified as being “absolute” to the end of active intergreen, so is defined as a phase gaining delay
with a 14 second “absolute” delay.
16.2.2 Multiple-cycling of stage sequences

If a stage sequence for the controller stream in this example is specified as being double-cycled (via
the Data Outline; Controller Stream>Stage Sequences>Stage Sequence n>”Multiple cycling”), the
timings could look like this.
TRANSYT multiple cycling is applied to individual Stage Sequences instead of to the Controller
Stream (as was the case in all previous versions of TRANSYT). This offers more flexibility in specifying
different possible timing solutions.

A full set of repeated stages have been created, and by default, are at their minimum length (which
happens to be 1 s in this example). The timings now clearly break a number of rules resulting in the
error list. Errors prevent the file running, so need to be resolved first. Simply pressing the “Repair
Timings” button will redistribute the green periods in such a way as to obtain valid timings. The file
can now be run. The timings after the repair are as follows:
If errors remain AFTER repairing the timings it is likely this is because the phase or stage minimums
cannot be satisfied within the cycle time, now that you have double the number of stages. If this is
the case, it will also show up as an additional error.

Page 308
16.2.3 Stage values

Most stage values are calculated automatically, but you can adjust the timings of the stage by
dragging the edges or the centre of the blue blocks in the Timings Diagram.
To change the offset, without changing the existing green timings, you can either drag any blank
area that is between any of the stages or anywhere within the blue blocks (N.B. not on top of the
green phases).
To extend or reduce the length of a stage you can drag the edge of a blue block. (N.B. not the end of
a green phase)
 Stage Start and Stage End values are filled in automatically as you move the stages around
using the Timings Diagram, but you can also, if you wish, directly edit them in the normal
way (using the Data Editor or Data Grids). You can edit Stage End timings via the “Stage
Sequence” data, while both stage start and stage ends can be edited via “Resultant Stages >
Stage n”.
 In the Stage Sequence shown, stage 1 ends at 49 seconds and stage 2 at 26 seconds. The
stage start times are defined by the intergreens and phase delays.
 A variety of resultant stage data is presented in the controller stream data under “Resultant
Stages”. Most of these values are read-only and only presented for reference as they may be
of interest to some users.
 For those familiar with using percentage split times (e.g. in Australia) to define what
percentage of the cycle is taken up by each stage, these can be displayed/edited in the data
editor (and using timing wheels) by switching on the option
File>Preferences>2.Localisation>SCATS split time.
 Stage Start, Stage End and Stage Minimums can be edited directly. Note that the editing of
percentage split times will alter both the stage duration and the stage end times, while
retaining the existing stage start times.

 If you need to re-enter data from, say, a printout of your signal timings this can be done
easily by changing directly the editable data under “Resultant Stages” - The standard stage
definition Stage Start and Stage End times can be modified. When doing this, it can be
useful to use a data grid and to also have the Timings Diagram open at the same time so that
you can see the changes graphically as you make them.
TRANSYT has calculated that the Stage Minimum for Stage 2 is 7s, in this case because Phase
A has a minimum green of 7s (entered via Controller Stream>Phases>Phase B). In some cases
this calculation is more complex – e.g. Stage 1 could be shorter, because phase A could
satisfy its minimum green outside of Stage 1. Because of this, TRANSYT allows you can enter
your own stage minimum. Note that this is done via the User Stage Minimum box (Data
Outline>Controller Stream n>Stage Library>Library Stage), even though the value is also
displayed in the Resultant Stage Data as a resultant value. If the user-specified value is
smaller than the calculated value, it will be ignored; if it is larger than the calculated value,
then it will be used in preference. The Stage Minimum box always shows the value that
TRANSYT will actually use.
 If a phase runs in consecutive stages, then TRANSYT may be unable to calculate a stage
minimum, and will use a one for this value, in which case you should enter your own value.
If you wish to see resultant Stage Data that uses TRANSYT 12 definitions you must
switch these on (see Main Menu>Data>Model and Results options >“Display
TRANSYT 12 Style Timings”). These will appear in the data editor prefixed with
‘TRANSYT’ – e.g. “Call to Stage” (i.e. the start of an old TRANSYT 12 stage).
The Inclusive Stage Minimum is calculated automatically as the Stage Minimum +

Preceding Interstage. This represents the minimum length of the stage + interstage
and is the main constraint used by the signals optimiser.

Page 310
The minimum preceding Interstage can be shown using diagonal shading on the
timings diagram (switch on via Appearance>Show minimum preceding interstages).
This represents the smallest preceding interstage that is allowed, given phase
intergreen constraints.
You can also use the Controller Streams (Signals) Data screen to conveniently view, edit, add and
delete stages, phases, phase delays and stage sequences at any controller stream:
16.2.4 Phase Green Periods

Phase green period values are all calculated automatically from other data such as phase delays and
stage timings, and are only filled in for reference. You may choose to ignore these values.
The timings of the green periods are adjusted by dragging the edges of the green blocks in the
Timings Diagram. This will have the effect of adding or removing phase gaining and phase losing
delays (see 16.3.2) It can also indirectly affect the timings of other phases, e.g. by introducing or
extending a phase delay the following stage may have to start later to satisfy the defined
intergreens. This in turn will mean phases running in that stage will also be changed. The easiest
way to see this effect is to try it yourself.
Optionally, TRANSYT Starting/Ending Stage, TRANSYT Start Lag and TRANSYT Minimum Start Lag
can be reported – These are enabled via the Model and Result options.

Phase A has only one green period in this example. It runs from 30s - 50s, i.e. with a duration of 20s.
It cannot run earlier since it is constrained by the intergreens from Phases D and E to Phase A, but
could start later if a phase gaining delay was to be added.
16.2.5 Filter phases

In order to accommodate filter situations, such as the nearside filter arrow illustrated below, each
traffic stream or link can be controlled by up to two phases. The second phase can be activated and
reference from the “Signals” tab of the Traffic Streams Data Screen (“Phase2 Enabled” and “Phase
2”).
The illustrated example (see screenshots) shows how the left-turning traffic approaching on Arm B is
able to make use of a filter (Phase E) due to the opposite approach having a banned right-turn
movement. The nearside lane of two has been set to run during both phase D and phase E, as
illustrated in the timing diagram (shown).

Page 312
Filter phases are terminated with the associated full phase. This aspect of design is not captured
within TRANSYT so you will need to ensure you end the filter and the full aspect signal phase at the
same time.
16.2.6 Accounting for Turn on Red

In many countries vehicles are permitted to take a nearside turn at a traffic light showing a red
signal, when the way is clear. Although in many cases it will be safest to assume no such vehicle
benefit from such a facility when predicting future performance, in some circumstances you may still
wish to evaluate the performance of a signalled junction by taking account of this benefit to traffic.
TRANSYT has a rudimentary system for modelling such occasions.

Both traffic streams and links can be set up to allow traffic to turn on a red signal, by enabling the
option “Allow nearside turn on red” (Outline: Traffic Streams > Traffic Stream). This is an advanced
item. Enabling this option allows you to specify a maximum flow rate over the stop line during red.
‘Red’ is defined in this case as “NOT effective green”, so excludes time naturally used by traffic, say,
in the amber time after the end of the actual green signal.
The flow of traffic during red can be observed in a cycle flow profile (CFP) graph.
If, for example you are aware (i.e. have measured or predicted) how many vehicles benefit from this
facility in real life ‘per red period’ you will need to estimate the max flow required to achieve this
value. Note that the resultant flow rate will also depend on the traffic demand during red (i.e. what
traffic is still queuing or arriving during red).
The resultant traffic flow during red is reported as “Flow On Red (PCU per cycle)” (Data Outline:
Total Results > Flows and Signals).

Page 314
This facility is limited to traffic streams and links that contain only nearside turning
traffic. If the traffic stream or link contains other movements a task list error message will appear.
The Timings Diagram illustrates, for each controller, the timings for each phase and shows the stages
that each phase runs in. It also shows which traffic streams (or links) are controlled by which
phases.
Furthermore, it illustrates other important points about the way phases and stages ‘fit together’. It
can be used in conjunction with the Intergreen Matrix, Stage Sequence screens and Network
Diagram Timing Wheels (see 16.4).
You can show several Timings Diagrams at once and can lock each screen to show data for a
particular controller stream by using the padlock.
The Timings Diagram not only shows timings for the current (active) stage sequence but also can be
used to view any unused sequences and also, via the Interstage Matrix, all possible stage transitions.
Different colours are used to represent the stages, to make it easier to identify which of the three
types of timings you are looking at - Stages of the current stage sequence are shown using blue
blocks; stages of unused sequences are shown in yellow; while interstages are shown in light-brown.
Examples are shown below:
Repair Timings: An additional button is provided to allow invalid timings to be repaired. This will re-
distribute timings evenly between the stages in order to try to satisfy any phase delays, intergreens
and stage and phase minimums.
The remaining features of the Timings Diagram are described in the following sections.

16.3.1 Menu Items

Appearance>show effective greens: this shows the effective greens as a lighter green above the
actual green. Notice how the blue pedestrian phase’s effective green is the same as its actual value.
Appearance>show losing/gaining delays: this shows the phase losing and phase gaining delays: the
losing delays are indicated by the darker green band that will appear after the end of a stage; the
phase gaining delay shows up as a dashed line before the beginning of a stage. This option is ‘on’ by
default. Additionally, the relative delay (shown) or absolute delay is written as text to make it easier
to see how long each delay is.
Appearance>show minimum preceding interstage: TRANSYT calculates a minimum value for the
preceding interstage in order to prevent stages from overlapping. This minimum can be displayed as
a hatched area between the stages. The minimum preceding interstage will normally be the same
as the actual value. This option is ‘off’ by default.

Page 316
Appearance>show stage minima: TRANSYT calculates a minimum value for the stage length. This
minimum can be displayed as a hatched area, starting on the left-hand end of the stage. This option
is ‘off’ by default.
Appearance>show controlled link and traffic streams: this switches to showing one phase for each
traffic stream (or link) (resulting in the same phases being shown multiple times in many case)
rather than the default of showing each phase only once. When showing each phase only once, the
right-hand column indicates the number of traffic streams (or links) the phase is controlling (as
shown in the screen shot below). If blank, it is controlling nothing. When showing links and traffic
streams it shows the controlled item’s ID.
Appearance>Indicate Phases on or below minimum: When enabled, TRANSYT underlines in black

those phases on their minimum. Phase lengths below their minimum are underlined in red, unless
the “Auto redistribute” option is enabled, in which case they are shown in amber. The amber colour
indicates that an optimised run is available to try to repair this situation.

Appearance>show ALL intergreens: the intergreens that are relevant to a particular stage change are
always shown. This option shows all the other intergreens that have been specified in the intergreen
matrix. Default is ‘off’
Appearance>show zero length intergreens: intergreens that are of zero length (i.e. define a conflict
only) are shown optionally when this option is selected. Default is ‘off’.
Appearance>show flat colours: the shading of stages can be shown either using a flat colour or
graduated. Default is ‘on’.
Appearance>show phase key: If the “Show phase colours in timings diagram” user preference is
enabled this option is available, and when selected, it will show a key for the phase colours.
Appearance>show error / warnings list: if screen space is required this list can be hidden. This
option can also be toggled on and off using the blue text at the bottom of the diagram. N.B. the
blue text itself is hidden if there are no errors or warnings
---------------------------------------------------
Tools>calculate phase intergreens From phase timings>conflicts only
and…
Tools>calculate link intergreens from phase timings>conflicts and timings:
These two options allow the timing data to be used to work out phase conflicts and intergreens.
This facility is also available from the intergreen matrix, where it is fully explained – See section 16.5
N.B. the timings diagram will add phase delays automatically as you manipulate phase timings. You
may wish to delete some of them, particularly the phase gaining delays which are only created
because of the lack of intergreens, which you have now added.
---------------------------------------------------

Page 318
Tools>Phase Optimiser>This controller and Tools>Phase Optimiser>All controllers: calculates the best
possible stages, staging arrangement and phase delays to minimise delay either for the current
controller stream or for all controller streams in the network. Although the results are based on the
isolated performance of the controller streams, the process will give a very good optimised starting
point to which the TRANSYT optimisation routines can be applied, in order to optimise green times
and offsets while taking account of controller stream network performance.
---------------------------------------------------
Tools>reduce cycle time to minimum: Sets the currently selected controller streams “Cycle time
source” to “manual” (you will be prompted to do this or to reject) and its local “cycle time” set to
the minimum possible cycle time, for the current stage sequence.
Tools>convert all stages to base stages: when TRANSYT runs, repeated ‘virtual’ stages will be added
if a controller stream is to be double-cycled. These stages are copies of the original stages (known
as base stages). This option converts these copies into base stages.
Tools>remove non-essential gaining delays: This option removes any phase gaining delays that have
become redundant due to changes in the intergreens or staging arrangement.
---------------------------------------------------
Tools>auto generate library stages: automatically creates in the “Stage Library” a collection of all
possible stages – a stage for each valid combination of all the phases that can run together ( Outline:
Controller Stream n>Stage Library).
Tools>auto generate sequences: automatically creates up to 10 of the shortest possible Stage

Sequences (given the already defined stages and conflicting and non-conflicting phases) and
automatically sets the “current sequence” as the one offering the lowest “minimum possible cycle
time”.
---------------------------------------------------
Tools>reset green periods: this option will set up each phase running in its own stage, with zero
intergreens and all stages being the same length.

Tools>reset and create new stages: firstly this option will request that you enter the number of
stages required. Then it will remove all the current staging and create the specified number of
stages (Stages 1 up n, where n is the requested number of stages). Any phases that happen to run in
any of the new stages will remain so.
16.3.2 Manipulating items

Stages cannot be created or deleted by dragging – it is assuming that you wish to keep the stage and
stage order as it is, and only manipulate the timings in other respects. Controller Offsets are
changed by simply dragging the blue area of the stage to the left or right using the mouse. While
dragging items, other items will be pushed out of the way, in order that constraints such as
intergreens are not broken.
Additional behaviour is as follows:
 Drag the middle of a stage or interstage to change the controller’s offset
 Drag the start/end of a phase’s green period to extend or shorten it (i.e. create/destroy
phase delays). N.B. to remove a phase gaining delay you will need to right-click and
select the option “Remove Delay”.
 Drag the start/end of a stage to extend or shorten it
 Use the options in the Tools menu to auto generate Library Stages and Stage Sequences;
reset stages/green periods, or create a specific number of stages.
 Right-click on a stage to show a context menu to add a new stage, remove the stage,
change the phases running during the stage, or to ‘trim interstage’. (Trimming an
interstage removes any phase delays so that all phases run as determined solely by the
stage timings and intergreens).
 Right-click on a stage while horizontally level with another phase to quickly select
Enable Phase ? in Library Stage ?.
 Right-click anywhere in the diagram to select “Add phase losing delays.

Page 320
 Right-click on a phase to show a context menu that allows you to remove it from the stage,
remove the green period
 Right-click anywhere in the diagram and select “Add phase losing delays”. This option will
automatically populate your timings with phase losing delays where they can be added
without moving the start of any stages. In the example illustrated above, see the before and
after effects of applying this option.
 Remember that if you make a mistake, just use the Undo/Redo buttons.
16.3.3 Entering signals data

The various options listed above are available so that you can manipulate the phases, intergreens,
and stage data as you see fit. However, to make life easier when setting up standard junctions in a
standard way, the following guide is suggested. There are two recommended ways to set up a
junction from scratch.

The first uses primarily the Signals Data Screen (as well as the intergreen matrix and the network
diagram): This method is described in a sub-section of part of the manual covering the use of the
Signals Data Screen – see section 9.2. This is likely to be your preferred method.
The second uses a mixture of the Signals Data screen, intergreen matrix and the network diagram
as follows:
1. Create your new controller stream, if needed, either in the network diagram or via the “Add
a new Controller Stream” button on the data outline.
2. In the network diagram associate the traffic streams with the new controller using the
connector tool. N.B. Traffic streams will be automatically associated with the nearest
controller stream, so that’s why it’s worth creating them first.
3. Right-click on the Controller Stream and select the option to show the Phase Timings
Diagram.
4. From the Tools menu click on “Create New Phases” and specify the number of phases you
need. Tip: If you are not sure how many you may need it is not a problem – you can add
more or remove unused phases easily. Guessing high is marginally easier as unused ones can
be easily ignored or deleted at the end.
5. Select the controller stream in the network diagram. At this point the phases controlling
each traffic stream will be displayed. By default they will all be set to Phase A. Simply right-
click on each traffic stream or link to select the right phase.
6. Optionally: If you are using a background image of your junction, you may want to set out
your network diagram to match the geometry of the situation in real life. If are able to scale
the diagram too, this will allow the option of deriving both conflicts and intergreens
automatically from the diagram - See the next step.
7. Open the Intergreen Matrix screen on the vertical toolbar. Fill in the intergreens (first tab of
the intergreen screen) in order to define which phases conflict with each other. You only
need to add the intergreens for the phase transitions you wish to use, but entering them all
is advisable if you are unsure of what your final stage sequence will be. N.B. if you have
carried out the previous step you can get TRANSYT to derive conflicts and intergreens for
you, based on the scaled diagram geometries.
8. On the Tools Menu select “Auto Generate Library Stages” to generate a set of valid library
stages, each of which maximise the number of phases that can run in them.
Alternative 1: To manually set up the stages you want, use the Tools item “Reset and Create
New Stages” to create the number of stages you want. Then right-click on each stage in the
Timings Diagram to select which phases run in which stage.
Alternative 2: You can also use the stage sequence diagram to define which phases run in
which stages by double-clicking on each traffic stream (or link).

Page 322
Alternative 3: Create the number of stages you want by selecting your controller stream in
the data outline, and then click on “Stage Library” and use the “Add a new Library Stage”.
Then click on each library stage to directly specify which phases run in each stage by entering
a comma-separate list of “Phases In Stage”.
Note how your stage starts and end times are changed for you, so that the specified
intergreens are resolved automatically as you add each phase to each stage.
9. Next, you can add phase delays (if needed) by dragging the end points of the green periods in
the timings diagram. You may often want to skip this stage until you have your final stage
sequence.
Alternative 1: Use the Delays tab in the Signals data Screen. This is still best used in
conjunction with the Timings Diagram.
Alternative 2: Use the data outline and data editor to enter your phase delays.
10. On the Tools Menu select “Auto Generate Sequences”. This will create up to 10 of the
simplest (smallest number of stages) stage sequences possible. To examine each sequence,
open the stage sequence diagram and select each sequence from the “Show” menu.
Alternatively use the data outline to select each one in turn.
11. Using either the data outline, the “stage Sequences” tab of the controller stream screen, or
the “Tools” menu of the stage sequence diagram, set the “Use Sequence” to the sequence
you wish to use. Note: By default, the one offering the lowest minimum possible cycle time
will have already been selected as the current sequence.
12. Now open the Task List to check that your network does not have any errors. As long as
there are no errors you can now run your file with your chosen optimisation options set.
16.3.4 Control of two junctions using a single controller stream

When there are two junctions closely spaced that have internal stop lines, it may be that they would
be controlled by a single controller stream. Below is an example showing just such a case. This
situation is easily modelled - the green cones illustrate the fact that all signalled arms are controlled
by the one controller stream 1.

To setup one controller stream to control two traffic nodes, select each traffic stream entering the
two traffic nodes and set there “Controller Stream” to the same controller ID.
Once this has been done, link greens, intergreens, stages etc. can be specified in the normal way.
16.3.5 Using the Timings Diagram with the clipboard

There are various options in the Clipboard menu to copy the current set of timings to the clipboard,
from where you can paste it into a spreadsheet etc., and to paste in timings.
In particular, if you have a specific set of link timings and wish to enter them directly into TRANSYT,
then an easy way is to enter them in e.g. Microsoft Excel, and then use the Clipboard>Paste Link
Timings option. TRANSYT will calculate the corresponding stage timings.
For example, the timings above give the below when the clipboard option is used:
Phase Start1 End1 Start2 End2 Start3 End3 Start4 End4

Page 324
A 25 74
B 25 69
C 79 94
D 99 20
E 99 20
F 79 94
If the timings are adjusted using Excel to those below (reduced length of stage 1 by 10s), and the
Clipboard>Paste… option used, the Timings Diagram will appear as shown below. N.B. do not mix
up the link orders.
Phase Start1 End1 Start2 End2 Start3 End3 Start4 End4
A 25 64
B 25 59
C 69 94
D 99 20
E 99 20
F 69 94
In this example you will notice that the timing changes have been changed in such a way as to retain
the current intergreens. If this is not done TRANSYT will add phase delays as required in order to
ensure the specified intergreens are maintained.
Timing wheels allow the stage timings of a control stream to be displayed and edited directly from
within the Network Diagram. The controller stream offset can also be adjusted. Timing wheels are
not intended as a full alternative to the Timings Diagram but simply a convenient alternative to it.
Right-click on the controller stream and select “Show Timing Wheel”. Select this option again to
hide it. Timings wheels can be shown for as many controller streams as you like.

The wheels can be manipulated as follows:
 Click and Drag the centre of the wheel to move it
 Drag the green bend handle located at the top of the wheel away from the wheel to
enlarge the wheel and the opposite way to reduce its size
 hide it by right-clicking on the timing wheel itself
 “Repair Timings” using the right-click menu option
 Double-click in the centre of the wheel to display the timing diagram.
The timing wheels consist of three concentric circles. The inner circle displays the cycle time of the
controller stream that the wheel is representing. The middle ring shows the signal stages (coloured
blue) and interstages (white). When an animation is running a blue ‘second hand’ is also displayed
that shows the current time within the cycle. The outside ring is reserved for the signal timings - The
numbers in brackets are the duration of each of the stages (in seconds), and the other are the start
and stage times of each of the stages.
Select the user preference SCATS split times to show stage durations as the percentage of the cycle,
instead of seconds. Please remember that these are based on a stage definition that includes the
following interstage. (See example below.)
Timing wheels are also tolerant of multi-cycled stage sequences (see example below).

Page 326
16.4.1 Changing Stage timings and offsets

Either the stage start time or end time can be changed using the timing wheel. Click anywhere on
the separating line at the end or start of a stage. The line will turn red and a red dot appears
indicating that you have selected that item to edit. You can then use your mouse to drag the timing
for forward or back. The difference between the new value and the original is displayed. You cannot
change the interstage from here, so any change to a stage start will result in the same change to the
preceding stage end, and vice versa.
Offset: Rotate (wheel) to change
Start of stage 2: Rotate to change
The stage offset is indicated by a small black dot at the located at the start of stage 1. Select and
drag the dot in either a clockwise or anticlockwise direction to change the signal offset.
In order for any signal timing changes to be reflected in the results you will need to
either carry out an evaluation run manually or switch on the auto-run facility.

Click this button on the main vertical toolbar to show a new Intergreen Matrix screen.
The Intergreen Matrix screen shows the matrix for the current signalised controller stream. You can
show more than one at once. Use the padlock to lock it to a particular controller stream.
The Intergreen Matrix screen defines which phases are compatible with each other phase (i.e. which
phase pairs can run together in the same stage.) If two or more phases are compatible with each
other, then there is no conflict between the phases and it is possible for those phases to run
together in the same stage. The matrix is symmetrical, so that if Phase B is compatible with Phase F,
then Phase F must also be compatible with Phase B. Hence, when one phase conflict is defined, its
reciprocal is automatically added with a zero intergreen.
TRANSYT uses the phase intergreen matrix to calculate constraints for stages and phases that are
utilised by the signal optimisers.
16.5.1 Intergreens
Edit the matrix by double clicking in a cell to toggle a conflict on or off, by typing a number in each
cell, or by pressing the Delete key to remove a conflict.
Conflicts between phases are shown with a red background. The remaining cells of the intergreen
matrix will be either white or pale yellow. Pale yellow is used to suggest where conflicts ‘might’ be
required, i.e. where conflict pairs are currently not running together.
Phase intergreens can be visualised in the Timings Diagram:

Page 328
The Intergreen Matrix can be copied to, or pasted from, the clipboard – This is useful when you wish
to create a new matrix somewhere within your network similar to an existing one or for copying into
OSCADY PRO for detailed individual junction analysis.
It is up to you whether or not they specify a full set of intergreens or only those related to the
phase-to-phase transitions that they have in their file. It is however, often useful to define a full
matrix as it will mean that subsequent changes to stage orders can be achieved with relative ease.
Furthermore, a full intergreen matrix is required if you are planning to use any of TRANSYT’s
advanced phase and stage order optimisation features.
16.5.2 Establishing conflicts and intergreens from signal timings

You can generate a set of phase conflicts and intergreen values, based on the current phase timings
(i.e. on what ‘appears’ to conflict). Access to this facility is gained from either the Timings Diagram
or via the “Signal Timings” button on the Intergreen Matrix screen, (Intergreen tab only).
For example if you set up the Timings Diagram to show stage/phase timings as in the screenshot
below and then select Tools>Calculate Phase Intergreens>Conflicts and values, the intergreens
shown further below will be obtained. It is a one-shot option and would need to be selected again if
the intergreen matrix needed re-calculating after a change to the signal timings. Alternatively you
can select the Conflicts only sub-option to populate the matrix with 0s conflicts.
It will be often easier to simply populate the intergreen matrix by hand. This option is also only of
use if the stages you have, represent groups of mutually exclusive phases.
Before:

After:
Alternative - Setting conflicts and intergreens via the Intergreen Matrix screen:

Page 330
16.5.3 Establishing conflicts & intergreens from network geometry

It is laborious job working out conflicts and intergreen values. TRANSYT now offers a facility to
derive both conflicts and initial estimates of intergreen values quickly and easily from the network
diagram. The conflicts are derived from the crossing or merging connector paths within the network
diagram. Vehicular-vehicle, vehicle-pedestrian and pedestrian-vehicle intergreens are derived.
These are based on distances within the diagram between associated probable conflict points. The
calculations are based on the UK Traffic Advisory Leaflet 1/06 Part 4, and 5/05 Part 4.
The calculation of pedestrian-vehicle intergreens take account of the crossing type - “far-side” (e.g.
UK Pelican crossing) or “near-side” (e.g. UK Puffin crossing). This information is specified as part of
the crossing data, which is specified via the “Crossing” tab of the Crossing screen. Other manual
adjustments to pedestrian intergreens which may be necessary, such as those to accommodate high
speed roads, or slow moving vehicles, should be made after you have let TRANSYT calculate the
intergreens.
A collection of four buttons offers you a number of calculation options as follows:
1. Clear all then find Conflicts and values: Click this to start afresh – This will wipe out all your
existing conflicts and intergreen values.
2. Find missing Conflicts and their values: Click this to get TRANSYT to look for new conflicts
(and associated intergreen values) while retaining all existing conflicts and their values.
3. Update values (Increase only): Click this to calculate intergreen ‘values’ for those that are
currently zero, without changing any of your existing conflicts. This button is intended to
allow existing intergreens to be retained while new conflicts, that do not have intergreens
specified, to be calculated.
4. Update Values: Click this to simply update all intergreens (based on the current geometry)
without changing any conflicts.
A “Clear All” button is also provided to allow you to start with a ‘clean slate’.
If plan to use this tool, we have a number of important recommendations:
1. Add a background image of the real network to assist you to locate the
network items accurately
2. Scale the diagram so that distances within it are as good as they can be. This
is essential.
3. Use curved connectors as they will allow TRANSYT to calculate more accurate
locations of conflict points for opposing movements.
4. Adjust connectors if needed such that they represent a realistic path that
vehicles would take to make that movement.

5. Use the capabilities of the file’s Audit trail to leave notes regarding the
process/changes you have made when deriving your intergreens, e.g. you
could indicate whether or not you used auto-calculated values and also if you
changed them or checked their validity.
Internally-calculated distances to conflict points that are longer than those listed in TAL
1/06 will result in conflicts with zero intergreen values. This is to ensure that you are
drawn to the fact that the intergreen values have not been calculated for you in these
circumstances.
Intergreens will only be calculated if the connectors join or cross each other’s path.
Because of this you should ensure that it is the connectors that cross the path of
other traffic, and not the traffic stream itself. This can happen, more readily with
pedestrian crossings. However, this can be resolved by moving the start of the
relevant downstream traffic stream(s) in order to extend the connector length across
the pedestrian crossing.
16.5.4 Interstages
For anyone wishing to use TRANSYT derived timings either directly or to simply set signal timing
constraints within any stage-based signal control system (e.g. SCOOT), TRANSYT calculates all
interstages.

Page 332
16.5.5 Banned stage changes

The intergreen matrix screen can also be used to specify banned stages. A separate “banned Stage
Changes” tab is provided which allows any stage transition to be banned (see screen shot).
If the banned stage transition should appear in the active stage sequence it will prevent TRANSYT
running by generating an error in the task list. Banned transitions will also be displayed in the
Timings Diagram for both the active (blue) sequence (see screen shot) and the unused (yellow)
sequences.
The “Auto Generate Sequences” facility (available from the Timings Diagram and the Signals Data
screen) will automatically avoid creating sequences that would result in banned transitions.

16.5.6 Using Clearance Times and Amber Times

For countries where amber times can vary from phase to phase, TRANSYT offers the option of
working with amber times and clearance times instead of intergreens. When the Intergreen Matrix
screen “Use Clearance and amber Times” option is set, phase conflicts are defined by specifying
clearance times between pairs of phases. Edit the matrix by double clicking in a cell to toggle a
conflict on or off, by typing a number in each cell, or by pressing the Delete key to remove a conflict.
The intergreens used by TRANSYT are derived from the clearance times and (end-of-green) amber
times and are not directly editable while in this mode. When using this facility, pedestrian phases
must to be identified by setting their “Phase type”, otherwise clearance times will be wrongly
calculated, because they will assume the phases have an end-of-green amber period.
Amber times are specified for each phase via the Data Editor (Outline: Controller Stream n > Phases
> Phase n). Pedestrian phase types can also be set here.

Page 334
Phase delays are shown in the Data Outline as part of the relevant controller stream’s data.
The diagram below illustrates losing and gaining delays.
Intergreen A to B = 6 seconds
Phase A
Relative phase gaining delay
=2s
Where Phase B would normally start Phase B
2 seconds
Absolute phase gaining

delay = 8 s
Phase losing
delay = 3 s
End of Stage 1 Start of Stage 2
Stage 1 to 2 = 10 seconds
Phase delays can be added, deleted and edited in a number of ways:
 graphically, using the Timings Diagram (see 16.3.2)
 using the Data outline and Data editor
 via the Delays tab inside the Signals Data Screen (see 9.2.4)
 when automatically added by the phase optimiser (see 9.2.1)
TRANSYT allows you to specific street minimum green times for each phase, but it also reports (for
display/convenience purposes only) controller minimum green times. Where phase losing delays
exist, the controller phase delays will be different to the street minimums, due to the different
definitions of the two minimums – Controllers minimums exclude any phase delays, while street
minimums don’t. All valid stage transitions are accounted for in the conversion from street to
controller minimums.

Launch the Stage Sequence screen from the main vertical toolbar. You can show more than one
screen at once and can lock each screen to a particular controller stream with the padlock.
The Stage Sequence Diagram can be used to show either the current (active) stage sequence, any of
the other stage sequences that exist, or the stage library. Selecting any controller stream’s Library
Stage will change the diagram to show the stage library for that controller. In addition to the
diagram label indicating which is being displayed, a similar colour scheme to that used by the
Timings Diagram is applied to the background colour of the Stage IDs – Blue for the current
sequence, yellow for unused sequences and brown for the Stage Library. The current Sequence is
also indicated by the presence of an asterisk, and the first stage of any sequence by a ‘+’ sign.
The diagram shows, for the selected stage sequence, each stage of the controller stream and the
traffic streams (or links) on green for each stage. Traffic streams and links that are unsignalised are
not shown. Minor shared links (by default) are also shown in grey, but can be set to “Same as
Major” using Options/Minor Links menu. When an animation is running, blue highlighting is used to
indicate which stage or interstage is active.
A right-click option allows you to insert either an existing library stage to the sequence, or to add a
new empty stage to the stage library and insert it into the sequence. Added stages are added prior
to the one you right-click on. The right-click menu also allows you to remove the stage you have
clicked on.
We recommend using this screen in conjunction with the Timings Diagram.
16.7.1 Defining which phases run in each stage

Double-click on a phase arrow to toggle it on/off for each stage.
Irrespective of whether or not you edit a Library Stage or a particular stage within a
particular sequence you are always editing the Library Stage.

Page 336
16.7.2 Re-arranging stage sequences

As well as redefining what phases run in which stage, you can use the Stage Sequence Diagram to
change the stage order within a selected sequence. Simply drag and drop any stage in the sequence
to a new location. An orange box indicates the location into which the sequence is placed (see
screenshot).
Furthermore, using a second stage sequence diagram, which has been locked to the stage library,
you can drag new stages from the library and drop them into your stage sequence shown in your
other diagram. The orange highlighting will guide you to where they will be inserted. This makes it
very quick and easy to set up the staging arrangement you want. Your starting sequence can be
totally blank.
16.7.3 Showing banned stage changes

In the last box, after the last stage in the sequence, a banned stage diagram is shown. The stage
numbers are arranged in a circle and a line drawn between each allowable stage change. Lines with
an arrow indicate that this direction of change IS allowed, but the opposite direction isn’t. If the line
is missing altogether, this indicates that this transition is banned in both directions. This diagram
can be hidden using one of the menu options.
Banned stages are specified in the Banned Stage Changes tab of the Intergreen Matrix screen. The
example shown below indicates that a change from stage 1 to 8 is banned, and also from stage 8 to
7.

Banned stage changes are also indicated if they exist in any stage sequence, and will be an error if
they appear in the current stage sequence.
16.7.4 Showing multiple cycling
When a stage sequence is multi-cycled, rather than repeat the full sequence multiple times, an extra
box appears indicating how many times the sequence is repeated within the one cycle. In the
example shown, the sequence is being double-cycled.

Page 338
16.7.5 Show, Options and Tools Menus

Use the Show menu to select a particular stage sequence, or the stage library. Having selected a
stage sequence to display, you can also use a Tools menu option to set the displayed sequence as
the active sequence to be used by the controller, (i.e. replace the “use sequence” value.
Use the Options menu to control the appearance of the diagram. This includes an option to
show/hide the phase diagram. The phase diagram is useful when you wish to display which phases
control which movements, and at the same time, label the stage sequence with the traffic stream
IDs instead of the phases. The options selected are stored for future use as a user preference.
Using the Tools menu, you can set all links to be either red or green.
Non-base stages are shown with a slightly shaded background to indicate they are repeated stages.
The amount of traffic that can pass through a signal controlled junction depends on the effective
green time available to traffic and on the maximum flow of vehicles past the stop line during the
green period (saturation flow).
The terms 'saturation flow' and 'effective green' should be familiar to most traffic engineers. In
reality, for any stop line, the saturation flow will vary over the green time as well as from cycle to
cycle. For modelling purposes it is necessary to simplify this. As with most signalised junction
models, the saturation flow averaged over many cycles is used in TRANSYT. A further simplification
is that the saturation flow is modelled as a constant value which applies over the entire effective
green. In reality the saturation flow will grow from zero to a maximum value over a finite time (due
to the acceleration of vehicles from standstill) and decay over the amber period (because the point
in the amber at which drivers stop varies from cycle to cycle). The diagram below shows the
relationship between a typical real case and the simplified values used in TRANSYT.
From this 'real' curve three values required by TRANSYT are derived: the modelled saturation flow;
the start-displacement; and the end-displacement. The displacements give the start and end of the
effective green in relation to the actual green. TRANSYT uses global displacements, entered on the
Signals Overview data item, and relative displacements, entered for each traffic stream. For a given
traffic stream, the overall start displacement is obtained from the global start displacement + the
relative start displacement for the stream, and similarly for the end displacement.

TRANSYT reports for each controller, the “minimum possible cycle time” based on its currently
selected stage sequence (see “Outline > controller Stream”). This value can be selected using the
option “Reduced cycle item to minimum” via Timings Diagram > Tools Menu. Note that selecting this
option will necessitate the controller switching to use a “manual” cycle time – i.e. stop it referring
the network cycle time.
Additionally each stage sequence reports its “minimum possible cycle time” (see “Outline >
controller Stream > stage sequence”). Using a Data Grid of all stage sequences allows you quickly
see which sequence will offer the lowest minimum cycle time.
If you wish to select the smallest cycle time possible for the whole network, there are two options
available via Main Menu > Tools:
Tools > Reduce network cycle time to minimum possible > Use current stage sequences: This option
automatically sets the network cycle time to the lowest possible across the whole network – This
will be the largest “minimum possible cycle time across all the controllers, without switching any of
the current stage sequences.
Tools > Reduce network cycle time to minimum possible > Use stage sequences that give lowest cycle
times: This option automatically sets all controller current stage sequences to those with the lowest
“minimum possible cycle time”, and then sets the network cycle time to the lowest possible for the
whole network.

Page 340
Either of the two network cycle time options described above can result in shorter interstages, and
when the network is optimised, longer phase green times. The volume of traffic is not a factor in
these selections.
A TRANSYT network can be set up to have more than one cycle time within it. Each controller
stream can be set to run on a different cycle time. Any controllers that run on the same cycle and
are adjacent to each other can benefit from having their timings coordinated. While all controllers
using the network default can be set centrally (Outline>Network Options>Network Timings), any
individual controller can also be set to run on its own cycle time.
By default, each controller stream references the TRANSYT network-wide cycle time which is always
specified, by having the controller stream’s “Cycle Time Source” set to “Network Default” (see
Figure 16-1). This can be changed to either “Manual”, so that you can specify a different cycle time,
or alternatively it can be set to “Controller Stream”, in which case you need to reference the ID of
another controller, from which it gets its cycle time. In this way you can set up a group of
controllers to use the same cycle time as another controller, i.e. sub-networks can be defined.
Figure 16-1 Cycle Time Source

In all cases the flow volumes are transferred along the traffic streams (and links) from one
controllers’ control to the next one, however, due to the cyclical nature of the standard TRANSYT
model flow profiles, only transferred if they are running on the same cycle, i.e. the flow profiles are
in effect flattened when the cycle times do not match. This is required since coordination between
uncoordinated controllers will simply not exist and hence any benefits from such coordination
would naturally be lost. Also see section 23.7 which explains how Simulation Mode can model
different cycle times within the same network more accurately.
The effect of multi-cycling of stage sequences is not taken account of when TRANSYT
decides whether or not the controllers are part of the same sub-network. For
example, if a double-cycled controller is running at 100 second cycle time (i.e. its
stage sequence repeats every 50 seconds) this controller will still be considered to be
part of a different sub-network from that of an adjacent single-cycled controller
running at 50 seconds, i.e. its profiles will still be flattened.
If circumstances lead to a sub-network running on a cycle time that is a multiple of an

adjacent sub-network you should consider modelling one sub-network using
TRANSYT’s multiple cycling facility instead of on a different cycle time, as this will
preserve the flow profile across the sub-network boundary and hence will model the
coordination benefits of the situation. With different “manual” cycle times used the
coordination benefits will not be modelled.
The data outline displays any cycle times that are set to anything other than the default (see below).
The centre of network diagram Timing Wheels also display each controller stream’s cycle time.
Different cycle times and multi-cycling options for each sub-network can also be investigated using
TRANSYT’s enhanced Cycle Time Optimiser (CYOP). See section 28.11.

Page 342
16.10.1 Traffic Stream and Link cycle time selection

Traffic streams and links have an option called “Auto Cycle Time” which, by default, is always set.
This option ensures that the cycle time associated with all traffic streams and links, whether
signalised or not, will associate themselves with the right cycle time. When set, the cycle time of
signalled traffic streams will use the cycle time of the controller associated with the phase
controlling that traffic stream. For unsignalled items it will base the cycle time on of the most
appropriate one it can identify. The option to switch off this automatic selection is only provided for
the rare occasion in which the selection is not what is required. Generally, this setting can be
ignored.

Working with flared Approaches Page 343
This chapter describes how to correctly model the extra capacity available from flared approaches
(due to short lanes at the stop line) using the standard core models.
Flares can be modelled using two different techniques. One method is to use a traffic model that can
model the blocking back effects associated with a flare. The second method is one which has been
traditionally used in TRANSYT, but which has limited capabilities – This involves the explicit creation of
“Quick” flares to model flared approaches. These two methods are described in the following two
sections.
17.1.1.1 “Flare” Traffic Model

Using this method, flares are modelled by setting the relevant traffic streams (or links) to use the
“Flare” traffic model. TRANSYT will then use the most appropriate traffic model that has the required
blocking capabilities, i.e. either the congested platoon dispersion model (CPDM) or cell transmission
model (CTM).
sat.
flow
0 green time
A “Flare” traffic stream (or link) is, in essence, something that has the ability to fill-up with traffic, and
block upstream traffic entering it due to its restricted length.
To model a short flare you simply add the appropriate traffic stream (or link) type and set its traffic
model to “Flare”. The maximum queue storage value then determines the amount of traffic that can
store in the flare (short lane).
Setting traffic streams and links to use a “flare” model” is a more natural way of defining
flared approaches. For complex situations it is easier to set up and also models more accurately,
due to the inherent ability of the “flare” model to take account of blocking effects and platooning
effects.

Page 344
The congested platoon dispersion model (CPDM) is used automatically for shorter flares (less than
30 metres) due to the fact that it models random effects in addition to its inherent ability to model
platoon dispersion. For longer links the superior full horizontal spatial awareness of the CTM model
will make it a more appropriate model to use despite it not modelling platoon dispersion. When
blocking back effects need to be modelled these will also be the very situations where modelling of
dispersion will be less important.
The automatic selection of blocking model ensures that the model choice is both
consistent (between users of the program) and that the most appropriate model is always used. The
traffic stream (or link) structure is the same no matter which model is used.
In the simplest case, whichever flare model is chosen will provide additional capacity which will have
an equivalent effect to that of a “quick flare” - see the stepped form of the non-linear saturation flow
in Figure 17-2 which contrasts with the constant, single valued, saturation flow for non-flared links.
The “Flare” models are more flexible, as they handle situations that the older “quick flare” model
couldn’t, e.g. the flared area does not have to be controlled by the same signal phases as the
adjacent full lane, for example.
To model a short flare you simply build a Link or traffic stream structure in same way you would build
the rest of the network, i.e. explicitly provide the additional space provided by the flared area by
adding links and lanes to take the extra traffic, and connect the lanes or links together in the usual
way.
This is best described by way of a simple example:
17.1.2 Simple Flare Example

The simplest example (Figure 17-2) is a single lane flaring out to two lanes at a signalled stop line. The
signals presented to both lanes are identical in this example, but don’t have to be. It also does not
matter whether or not a traffic queue is likely to block back at any time to the one lane part of the
carriageway – any blocking will be taken account of if it exists. Starvation of any of the stop line lanes
due to blocking upstream will also be taken account of. Figure 17-3 shows the required traffic stream
structure in TRANSYT as well as illustrating the use of the “queue” overlay (which can be animated
over time).

main lane
flare
Figure 17-2 A simple flare – on-street
To set up this flare correctly the following is required:
1. A traffic stream with saturation flow (bottleneck) is inserted at the point where the lane
splits into two (or more), i.e. where the additional short lane starts. The flow connectors are
such that the traffic stream feeds through the bottleneck into the two downstream traffic
streams. Note that the part of the network adjacent to the extra lane(s) is regarded as part of
the ‘flared area’. Optionally, you can also specify an extra traffic node for Arm 1 – this can
make the items easier to manipulate the items in the network diagram.
2. The two stop line lanes, that represent the flared area, are modelled as separate signalled
traffic streams in order to model the potentially different queueing behaviour on each lane.
3. The Saturation flows of the two stop line lanes are specified in the usual way.
4. Traffic Stream Model Type: Traffic Streams 2/1 (the part of main lane that’s adjacent to flare)
and 2/2 (Flare) have their traffic model set as “Flare” so that blocking back effects will be
modelled. Traffic Stream 1/1 is left as the network default (in this case the network default is
PDM) – Essentially, you are defining which items have the capability to block upstream traffic.
5. Maximum Queue Storage: TRANSYT, by default will automatically calculate internally the
amount of traffic that can store on any traffic stream (or link) using the length and saturation
flow. This is not necessarily accurate enough for modelling flares, since it is only a rough
estimate and can sometimes be an overestimate of the maximum storage space that traffic are
prepared to use or can use in practice. Because of this, we recommend that any traffic stream
or link using the “Flare” model, should also have the maximum queue storage value specified
(Outline: Traffic Stream n>Modelling).

Page 346
Figure 17-3 “Flare” model of a simple flare
6. Feeding traffic stream: The feeding traffic stream has a (restricted flow) saturation flow
representative of a single lane. This is needed to ensure that the downstream traffic streams
are fed at the correct rate of flow when the feeding traffic stream queue (if it exists) discharges
into them.
If you wish to position the two lanes at the stop line, such that they are separate or not parallel to
each other, you can simply model them as two single traffic streams within separate Arms - The model
results will be the same.
“Flare” traffic streams (or link) should be constructed such that their
components (short lanes and feeding link/traffic stream) do not straddle two OD matrices. If this is
done the flare will not be recognised as such, and the random blocking effects will not be taken
account of.

Figure 17-4 Cyclic Flow Profile of exiting traffic
Figure 17-4 shows the profile of traffic crossing the stop line made up of traffic from both lanes. The
diagram illustrates the benefit of the flare – the extra capacity while the flare empties of traffic and
then a return to the flow rate associated with just one lane while the queue continues to discharge.
The shape of the graph is of a non-linear step form – in contrast with the constant, single valued,
saturation flow for non-flared approaches – and illustrative of the saturation flow that is achieved for
this situation. It is similar to what would have been achieved using the ‘quick’ flare model.
Because the flared area and the traffic using are explicitly modelled in TRANSYT, the go profiles of the
combined flared area automatically takes account of the extra capacity provided by the short lanes,
and this is done with respect to time, thus preserving platoon profiles for downstream links.
There are also other significant benefits of using the “Flare” models for modelling flares:
 The different traffic streams that represent the flared approach do not have to be controlled
by the same signals.
 Any platooning effects that reduce the potential benefit of the presence of the flare are
automatically taking account of. E.g. if all traffic arriving within a discrete platoon arrived at
the flared area and turned left using just the left-most lane, followed by a platoon that all
turned right using only the right-most lane, then the presence of the flared area could be
negligible.
 Flares can be applied to give-ways and restricted flow (bottleneck) links and traffic streams.
 The model automatically works out the likely utilisation of each short lane, so that it takes
account of whether or not traffic can choose between the different lanes or not. This makes

Page 348
the new model a more ‘universal’ solution than with the ‘quick’ TRANSYT flare model, which
allows one network structure to represent all flow situations.
It should also be remembered that the presence of flares giving extra discharge capacity for just the
initial part of the green may well mean that the signals will operate more efficiently on a short cycle
time. In this way, more frequent use of the flare capacity will be obtained, compared with longer
cycles.
17.1.3 Flare Results

Modelling of a flare using individual components as described when using the “Flare” model type
naturally means a full set of results for each individual component is provided. However, it may be
more natural and more desirable to evaluate a flare as a complete unit. In order that this can be
done additional results are provided.
This is best described by way of another example. The example here is a two lane approach flaring
to two, with two lanes catering for a straight ahead movement and a single lane for both straight
ahead and right.
Figure 17-5 Example Network of a flare

Figure 17-6 Data Outline and Flare Results
For the feeding (upstream) traffic stream (traffic stream 1/1 in the example) additional “Flare” data
is provided under the “Total Results” section of the traffic stream. This is accessed from the Data
Outline as shown in the screen shot.
The values shown represent those associated with the combined effect of the referenced “Flare
Components”. Degree of Saturation (and associated PRC value) is defined in such a way that it
closely matches the results that would have been reported when a ‘Quick flare’ had been used to
model the situation. This value represents a capacity specific to the particular utilisation of the
flared area as a consequence of the traffic model predictions.
TRANSYT still offers the option to use a traditional method of modelling flares. These are referred to
in TRANSYT 15 as “quick” flares.
TRANSYT models the extra capacity available from flared approaches giving extra lanes at the stop
line, as in Figure 17-7 by defining one or more ‘quick’ flares on a traffic stream or link.
main lane
flare

Page 350
The non-linear saturation flow is of the stepped form shown in Figure 17-8. It contrasts with the
constant, single valued, saturation flow for non-flared links or traffic streams.
sat.
flow
0 green time
TRANSYT ‘quick’ flares are defined on either traffic streams or on links. Quick flares can be used with
both CTM and PDM models. They should not be used on traffic streams or links that use the “Flare”
traffic model.
Because the new “Flare” Model technique offers advantages over the previous ‘quick’
flare model, we generally recommended the use of the new methods over the use of
‘quick’ flares. However, there is no reason not to continue using them for simple flare
situations ir where optimisation speed is an issue – see below. TRANSYT will import
existing flares, and will not attempt to convert them.
Using quick flares instead of the “Flare” model exclusively will allow you to use the
faster “link-by-link PDM” model option.
Flares modelled in TRANSYT 13 using the CTM model will not be converted to using the
“automatic chosen “Flare Model”. You can re-specify to use the “flare” model if you
wish.
17.2.1 How to set up a quick flare

You firstly need to use the Data Outline to navigate to Options > “Model and Results” or access the
main menu item “Data > Model and Results options…” and switch on the option “Enable quick
flares”. The ”Quick flares” item will appear in the data outline within each traffic stream (or link),
and also a new tab will appear in the traffic stream data and link data screens (see screenshot).

Figure 17-9 Data Outline and Quick Flare Data
Figure 17-10 Traffic Streams screen and Quick Flare data
The normal saturation flow specified for a traffic stream or link (Outline: Traffic Streams > Traffic
Stream n or Links > Link n) represents the value for the main lane alone. In addition, you are required
to specify, in Quick Flare Data (Outline: Traffic Streams > Traffic Stream n > Quick Flares > Quick Flare
n);
1. the saturation flow for the extra lane(s) provided by the flare,
2. the average number of vehicles which are able to use the flare during each green, estimated or
measured (“Effective storage”)

Page 352
This value can be entered manually as the “Effective Storage” or the flare capacity routine “Que
Prob” can provide a quick method for estimating the likely capacity gain for the situation where a
single approach lane (a main lane) widens out to give an extra lane (a flare lane) at the stop line.
The “QueProb” routine assumes that the traffic in the two lanes goes to different
destinations, i.e. an individual vehicle does not have a choice of lane. Therefore, QUEPROB is not an
appropriate tool to use when the traffic from the two lanes have the same destination.
The program derives its estimates from binomial probability theory, calculating the various cases
where either the main lane or the flare lane fills up first and cuts off access to the other lane,
causing a less-than-maximum usage of one of the lane queueing areas.
If used, you will be asked to enter…
"Maximum vehicles (PCU) that can fit into flare
Enter the size of the queue in the main lane which is just sufficient to block off access to the
flare. The queue size is entered as a number of PCUs or vehicles, using the same units as for
TRANSYT flows and saturation flows.
Percentage of traffic (using main lane)
Enter the percentage of traffic which uses just the main lane.
QUEPROB then works out the likely utilisation of the short (flare) lane giving you this in the form of
Effective storage. This leads to extra capacity being provided due to the flare.
The GO profile is modified to take account of the extra capacity provided by the short lanes, and this is
done with respect to time, thus preserving platoon profiles for downstreams. It should also be
remembered that the presence of flares giving extra discharge capacity for just the initial part of the
green may well mean that the signals will operate more efficiently on a short cycle time.
Examples of using the flare model in various cases are given in the following sections.
17.2.2 Identifying quick flares in the Network Diagram

Each quick flare is represented in the network diagram by a small grey rectangular box attached to the
stop line, behind the signalled traffic stream’s black rectangle. Each one can be individually selected
and clicked on. Hovering over one of the flares will reveal a tooltip reporting its storage length and
saturation flow (See screenshot).

Figure 17-11 Quick Flare in the Network Diagram
17.2.3 Flare fully used

For a single-lane flaring to two lanes at the stop line, where the approach traffic (or a substantial
proportion of it) can freely choose either the main lane or the flare lane, then the flare is likely to be
virtually fully used. This assumption can only be made however if the flare green is the same as that
of the main-line green.
The flare value entered is simply the storage capacity of the flare - probably estimated from the flare
length on the basis that 1 vehicle occupies about 6m in a queue, or that 1 PCU occupies about 5.75m.
17.2.4 Unequal use of flare and main lane

For examples, where use of the flare lane and the main lane will probably be unequal, the method
of modelling may well be dependent on the cycle time being used, and whether a link has double-
green or not. This is because the likelihood of queues blocking back to the narrower part of the
approach increases with longer red times for a flared link.
Queues interact, and flare caters for separate movement from main lane:
If the flare lane caters for (say) a left-turn movement while the main lane caters for straight-ahead
traffic, then not all the physical extra capacity will be usable on average because (a) for some cycles,
the flare or the main lane may fill-up before the other, blocking access to the extra road space
provided.
The extent to which these queues interact will depend on the percentage of traffic using each of the
lanes. To model this, it is necessary to specify the average number of vehicles able to use the flare
each green (Effective Storage Value). QueProb assists you in specifying this value. Again, the
assumption is that the flare green is the same as that of the main-line green – If not use the “Flare”
traffic model instead.
Queues interact, and flare traffic is opposed right-turn:

Page 354
In this situation the modelling is difficult and the flare model will not have been used. Other
modelling techniques will have been employed. Care should be taken when interpreting these. The
new flare modelling options available in TRANSYT make the modelling of such complex situations a
lot easier and simpler to model.

Working with priority junctions Page 355
This chapter describes how to correctly model priority intersections in TRANSYT by way of a few
examples. It explains how to add priority junctions to your TRANSYT network; how you can choose
between detailed models or simplified models; how the new priority objects can be used; how give-
ways within traffic signalled junctions should be specified, how to define give-way conflicts; and
describes all the features within TRANSYT relevant to priority junctions.
Additionally, for those wishing to understand fully what TRANSYT is doing on your behalf, in terms of
the traffic model, you may be interested in reading section 27.5.
Roundabouts are, in effect, a series of connected priority junctions, so it is recommend

that to understand fully how to model them in TRANSYT you should read the whole of this chapter
first to learn about how to define give-ways generally and optionally section 27.5 as well. Section
18.10 provides the additional information specific to the modelling of unsignalised roundabouts in
TRANSYT.
In TRANSYT, you have a choice between using a lane or a link structure to represent your real-life
network. You will generally find that the lane structure is a more intuitive way of setting up your
priority intersection as it will usually result in a one-to-one relationship between real lanes and
TRANSYT network lanes. The Priority Tool allows junction geometries (as used in ARCADY and
PICADY) to be specified, in order to work out the required give-way coefficients. These coefficients
can be assigned automatically to the TRANSYT lane or link structure.
The first couple of sections of this chapter start off describing the easiest way to add a priority
junction to a TRANSYT network – by adding a library file which contains a Priority Object.
Rather than construct junctions from scratch, you can choose to start off a new network
with a library file or merge one into their existing network. A small library of files is supplied with
TRANSYT, which can be supplemented by files you wish to store as additional library files. A number
of priority object files of various configurations are supplied. This feature is fully explained in
section 8.2.
The remaining sections describe how to use a number of other methods which may be required
when needing to model specific situations for which there is no library file supplied and for those
situations not covered by the priority objects.

Page 356
Figure 18-1 Example priority T-junction
Figure 18-1 shows a simple T-junction that will be used as an example to explain how priority
junctions can be modelled in TRANSYT. What is covered in this chapter can be used to model more
complex junctions as the principles learnt will be the same.
The example junction has one lane on the minor road and traffic on the main carriageway turning
right is mixed with that of the straight-ahead movement (i.e. no dedicated right-turn lane). This
movement is opposed by the traffic on the opposite major arm (a standard UK arrangement) which
is also a single lane.
A priority object is a TRANSYT data item that stores the geometric properties of either a priority T-
junction or a Roundabout. The priority object automatically calculates the give-way coefficients (see
section 27.5) needed to model the junction’s priorities and optionally assigns these coefficients to
the lane structure or link structure already specified within your model. The Priority object also sets
up the required movements and conflicts required to be defined for TRANSYT to model the junction
correctly. We recommend that priority objects are used if at all possible, as it reduces considerably
the work required to set up a fully specified priority junction.
Priority objects exist for roundabouts (all types), T-junctions and crossroads. Staggered crossroads
can be accommodated using two T-junction priority objects.

The models, now built into TRANSYT, that make this possible are those also used in our sister
products ARCADY and PICADY, which are used to model roundabouts and priority junctions
respectively. One of the main benefits of this new feature is that the performance of priority
junctions will take account of the effects of other closely-spaced junctions (signalled and
unsignalled) as well as take account of the effects of the cyclic flow patterns generated by the
presence of traffic signals within any modelled network.
To add or edit either a T-Junction or crossroads priority object within TRANSYT you must
have a registered version of PICADY on your computer. Similarly for the Roundabout
objects, you need a registered version of ARCADY on your computer.
By having a registered version of ARCADY on the same system as TRANSYT, it allows

you to add/delete and edit the data associated with Roundabout Priority objects, and
similarly having a registered version of PICADY allows you to add/delete and edit the
data associated with the T-junction Priority Objects. If a file containing either of
these objects is opened on a system without ARCADY or PICADY, the file will still
run, and give the same answers, but the data within the Priority Object will not be
editable. Priority Objects can always be deleted from a file.
For convenience, Both the ARCADY and PICADY modules of the JUNCTION product
can be registered from within TRANSYT using the main menu option “Help > Manage
Licences”.

Page 358
Figure 18-2 T-junction using a Priority Object
Figure 18-2 shows the lane and traffic stream network structure of the simple T-junction (Figure
18-1), which will be used to demonstrate the basics of setting up a priority intersection. The
structure assumes that traffic on the main road travelling left to right gets blocked by the right
turning traffic. The equivalent in PICADY is known as “Full Blocking”.
The steps required are as follows:
1. Open the network diagram if not already open
2. Click on the Insert Library File button on the network diagram’s bottom toolbar and then
click on the network diagram where you wish the new file contents to be deposited. This will
bring up a list of available Library Files.
3. From the list, select one of the files indicated as containing a T-junction Priority Object, and
click OPEN.
4. Select the default prefixes or re-enter your own – arm IDs and traffic stream IDs must be
unique within the network, and click MERGE. The contents of the file will be deposited at
the chosen location.
5. Connect the external traffic streams to the rest of the network (if required).

N.B. if you look at the traffic stream data you will see that all of the required movements and
conflicts have been created automatically for you. There is no need to change these, unless
you wish to model a different layout of traffic streams.
6. Specify the junction geometric data for the “Major Road” and “Minor Road” – See Figure
18-3 (Outline: Priority > T-junctions > T-Junction n). This automatically generates the “Slope
and Intercept” data that is used by TRANSYT to calculate the final give-way coefficients.
Figure 18-3 Geometric Data for a T-junction
7. Double-click on the OD Matrix in the network diagram and add your OD flows. The flows
entered will be assigned automatically to the traffic streams. Use a Local OD Matrix to
control how the flows are assigned to the network. Details on how to use a Local OD Matrix
is in section 14.4
8. Check the Task List for errors and if error-free simply run the file.
9. If you want results for the whole junction, rather than each individual traffic stream, add a
collection based on the relevant traffic node, in order that results appear in the TRANSYT
report.
Once a library file is loaded into TRANSYT it can be manipulated like any other
file. Saving the file will save it as an ordinary TRANSYT “.T16” file, but can also be saved as a
new library file if you wish.

Page 360
There will be situations where you wish to set up the network structure yourself or have simply
imported an old TRANSYT file to which you wish to add one or more Priority Objects.
Once you have added a new Priority object (using the network diagram or using the Data Outline)
you can specify the object’s data. One of its properties is “Auto Assign Priority”. When this is set it
will assign the calculated give-way coefficients to the relevant traffic movements. In order to do
this, TRANSYT traffic streams or links need to be matched up with their corresponding movements
within the Priority Object model.
If the junction is build using links it will be links that will need to be referenced and if the junction is
build using traffic streams it will be traffic streams that will need to be referenced.
Setting the “Type” to “TrafficStream” allows traffic streams to be referenced instead of links (see
Figure 18-5).
In either case, TRANSYT references the various movements (e.g. “Entry AB traffic
steam”) by copying the ‘approach naming convention’ copied from ARCADY and
PICADY – The names of each of the approaches to the junction are as shown in Figure
18-4 and Figure 18-6. For a UK give-way the Priority Model refers to the major right
as Arm A, minor arm as Arm B and the major left as Arm C.
If the referenced traffic streams (or links) do not match this convention TRANSYT will
give you incorrect results.
Traffic streams need to be matched up with the “Entries” and “Exits” on each arm of the junction.
Therefore, for the traffic stream network for the simple T-Junction (Figure 18-2), “Entry AB Traffic
Stream” will need to reference traffic stream “A1/1”. In this example the traffic streams themselves
have been conveniently named using the PICADY naming convention to make it easier to match up
the items, but of course, there is no need to do this, and in many cases you will not want to rename
existing traffic streams in your network. This example also illustrates the need to reference the
same traffic stream more than once if it carries traffic making more than one movement, as in this
case.
Links need to be matched up with traffic ‘movements’ at the junction. Therefore, in the example
shown in Figure 18-5, Link 24 is defined as the link carrying traffic from Arm A to Arm B i.e.
associated with “Entry AB”.
Where one way entries or exits exist please refer to section 18.3.1.

Figure 18-4 Priority Object Link names (Drive-on-the-left)
Figure 18-5 Matching up Priority Object to links or traffic streams

Page 362
Figure 18-6 Priority Object Link names (Drive-on-the-right)
Another important option that can be set is “Calculate Slope and Intercept”. When set this
TRANSYT automatically calculates a complete series of required slope and intercept values based on
the geometric data. When this option is not set, the various slopes and intercepts can be specified
directly (if you have them) without the need for the geometric data. For an explanation of what the
slope and intercept coefficients are, please see section 27.5 or read the relevant sections of an
ARCADY or PICADY User Guide.
18.3.1 Modelling one-way traffic

By default the “Traffic Direction” on each arm is set to “Two-Way”. If traffic is ‘restricted’ from
entering or leaving a junction, i.e. either one-way in or one-way out of the junction, the “Traffic
Direction” should be set appropriately as either “Entry only” or “Exit Only”.
The Priority Object needs to know this information, otherwise, it will demand the ID for traffic
streams or links that do not exist and will try to set up unnecessary conflicting movements of traffic
(see Figure 18-7).
Figure 18-7 Priority object - Exit only on Arm A

Some traffic direction restrictions affect the geometric data requirements. Any data that is not
required is ignored. How geometries are measured should not be changed as a result of any traffic
restrictions set - i.e. the customary doubling of the Total Carriageway Width (W) for certain
situations is not required – If this is needed TRANSYT will do this internally and will also report this
fact on the task list.
18.3.2 Modelling banned movements

The priority object also tolerates banned movements so if for example a right-turn movement from
the minor arm is banned, the priority object will automatically take this into account by only setting
up the conflicts and calculating the slopes and intercept needed for the TRANSYT network that has
been set up, i.e. it will spot when certain connectors are missing and take account of them (see
Figure 18-8).
Figure 18-8 T-junction with no right turn from Arm B
Where a priority (conflict) does not exist within the priority object’s area due to certain traffic
restrictions TRANSYT will not take this into account. The priority object forces the expected give-
ways to exist and these cannot be reset for example as a simple restricted flow type (bottleneck). If
one or more give-ways are missing from the junction, you will have to delete the priority object in
order to reset the give-ways appropriately. Note however that any conflicts and give-way
coefficients originally set up by the priority object will not be deleted – so any remaining give-ways
within the junction will still benefit from the slope and intercept calculations that have already been
made.
The saturation flow of any movement that does not have to give way will tend to be significantly
higher than if it was a priority situation, e.g. where the left-turn out of a side road or entrance is fully
protected, i.e. a raised kerb stops main road traffic conflicting. However, the relatively sharp turn
into the main carriageway still has the potential to restrict the flow of traffic and hence applying a
suitable restricted flow value (as part of the bottleneck data) is likely to be appropriate.

Page 364
Figure 18-12 shows the standard arms, lanes and traffic streams needed to model a basic T-junction.
The yellow pentagons shown are two of the OD Matrix ‘locations’. The structure assumes that
traffic on the main road travelling left to right gets blocked by the right turning traffic. The
equivalent in PICADY is known as “Full Blocking”.
When using a lane structure to model a T-junction you must use a Local OD Matrix to specify your
traffic flows in and out of the priority junction. A link structure can be used instead and is described
in 18.8 (Using Links to define your priority junction).
Figure 18-9 Network structure using traffic streams
This section gives a suggested order only, of the tasks involved in setting up a priority junction
assuming you have chosen not to import one of the supplied library files. Details of each step is
described in the following sub-sections. Note that non-essential data items such as “Name” or
“Description” data are not mentioned. Other items not mentioned are not required, so should be
left as their defaults. It is assumed that as you add the items to the network diagram, you will
position them appropriately.
1. Using the network diagram, add a traffic node (optional) and then the required number arms
(three), traffic streams (one per arm), each of which has one lane. An arm has one traffic
stream by default and a traffic stream has one lane by default, so for the example the
defaults are OK - no new streams or lanes are needed. You should ensure that you have a
full set of exit arms as these are a requirement of using a Local OD Matrix. For our example
you will need six arms in total.

2. In the network diagram, connect the various traffic streams to each other to define what
traffic goes where. Note that this does not define any give-way movements or conflicts –
only where the traffic goes.
3. Enter the Traffic Stream Data using either the Data Editor or the “Traffic Streams” screen. To
start with, define what type each traffic stream is: You will need to set the minor road traffic
stream as a give-way (pink in the network diagram) and the same for Arm C1 (Outline: Arm
C1>Traffic streams>Traffic Stream 1). The “Is Signal controlled” option should be de-selected
for both arms as neither of them is signalled. The exiting arms Ax and Cx will be whatever
type is required by the rest of the network, or if all the traffic on it is exiting the network it
should be set as neither signal controlled nor a give-way, i.e. an unrestricted traffic stream
(sandy-coloured in the network diagram).
4. For all arms the traffic stream option “Has Saturation Flow” should be disabled to ensure
that no queueing will occur on these lanes.
5. Add an OD Matrix using the network diagram: Add the number of locations required (one is
provided automatically). Three are required for the example as there are three entries with
corresponding exits. Use the connector tool to connect each of the exiting traffic streams to
the relevant location and connect each of the locations to the relevant entry traffic streams.
N.B. The direction you connect the locations defines what is an entry or exiting traffic
stream.
Double-clicking on the OD Matrix will bring up an origin-destination matrix from where you
can enter your required OD flows for the junction. Use the OD Matrix settings to control
how the flows are assigned to the traffic streams. Details on how to use OD Matrices is in
section 14.4.
6. Either add a T-junction Priority Object or add your “Give Way Data” manually. See section
18.6 on how to add a Priority Object. Since using Priority Objects avoids the need to set up
much of the data required, it is recommend that you use one, as long as the priority object
satisfies your modelling requirements.
By default, a give-way will have its property “Opposed Traffic” set to “AllTraffic” (Outline:
Traffic Stream n>Give Way Data). This means that all traffic on in this traffic stream is
opposed by some other movement(s) irrespective of where it is going.
In the T-junction example not all of the main road traffic arriving from the left (Traffic Stream
C1/1) is opposed, as some is travelling straight ahead. Setting the “Opposed Traffic” to
“Movement” allows individual movements to be added, so that the different characteristics
of each movement can be defined separately as required for this example situation. See
Figure 18-19. When “opposed traffic” is by “Movement” ALL movements must be set up,
even for movements that have no conflict. Those movements that have no conflicts should
have their “Percentage Opposed” value set to zero.

Page 366
Figure 18-10 Give Way Data (using Data Editor)
Figure 18-11 Give Way Data (using Traffic Streams Screen)
This is the only option that needs to be set for this example as the “step-wise opposed turn
model” is only applicable to signalled give-ways and the “Visibility Restricted” option is not
required for this example – see 18.7 for an explanation of what this option does.
7. Specify your movements and conflicts (or use a T-junction Priority Object). See section 18.6
on how to set up movements and conflicts. See section 18.6 on how to add a Priority Object.
Since using Priority Objects avoids the need to set up movements and conflicts manually, it is
highly recommend that you use one, as long as the object satisfies your modelling
requirements.
For Arm C1 a give-way max flow (opposed) for the straight ahead movement (Movement
Ax/1) is required, but will be set automatically to 1800 by the priority object (if used) – This
ensures that results match PICADY’s as closely as possible.
To construct a model of a priority junction in full detail from scratch involves

specifying a lot of movements and conflicts. However there are ways to reduce the work
needed. Firstly you can simplify the model to reduce the number of movements and
conflicts required. Details on how to do this are explained in section 18.15. The “Streams
Data” screen is also very useful as it allows you to see and specify many of the conflicts and
movements on one screen.

8. Check the Task List for errors and if error-free, run the file.
9. If you want results for the whole junction, rather than each individual traffic stream, add a
collection based on the relevant traffic node, in order that results you require are available.
Figure 18-12 Movements, conflicts and example conflict data
You can specify up to 16 conflicts per movement. Movements and conflicts are specified under
“Give Way Data” for each traffic stream.
The properties required for each movement are as follows:
“Destination Traffic Stream”: The movement itself defines the origin of the movement and
this defines the destination of the traffic.
“Max Flow (Opposed)”: This the maximum flow that can be achieved when traffic is giving
way to one or more opposing traffic streams, but when that opposing flow is zero. N.B. this
IS not the same as not giving way at all. It also sometimes referred to as the “Intercept”, as it
is in ARCADY and PICADY. When give-way traffic behaves as if it is unopposed then this
situation can be modelled – see section 18.16 to find out how.
“Percentage Opposed”: In this example the value is 100% as all the traffic making this
movement is yielding to the opposing traffic.
Where a movement on a particular traffic stream behaves differently from

another, then a movement should be added to represent this behaviour.

Page 368
When this is unnecessary, i.e. when “Opposed Traffic” is set to “AllTraffic” the
“Max Flow (opposed)” and “Percentage Opposed” are located inside the data
item “All Movements”.
When “opposed traffic” is by “Movement” ALL movements must be set up to

indicate to TRANSYT the number of conflicts, even for movements that have
no conflict. Those movements that have no conflicts should have their
“Percentage Opposed” value set to zero.
For the T-junction example, Lane C1/1 needs two movements specified – to traffic stream Bx/1 and
to Ax/1 (see Figure 18-13). These are necessary as the straight ahead movement requires having a
higher maxflow compared to that of the turning traffic. This is to reflect the fact that it is not
opposed by any traffic – A value of 1800 is set automatically to match the results of PICADY. In this
example the opposed movement has a max flow of 752 (N.B. this is an example value only – Not a
default).
Figure 18-13 Movements for Arm C1 (major left arm)

B1/1 requires movements to Ax/1 and C1/1 as again the give-way properties for each movement are
different, e.g. different conflicts and give-way coefficients.
Figure 18-14 Movements for Arm B1 (minor arm)
However, A1/1 does not require ANY movements defined as both traffic movements (to Bx/1 and
Cx/1) are modelled as having the same ‘experience’, i.e. nether give way to any other movements.
(In some countries this would not be the case, in which case the traffic stream would need to be
defined as a give-way, and separate movement data defined.)
The definition of the various movements allows each of them to be set up with associated conflicts,
i.e. a particular movement will conflict with one or more other movements. The screen shots shown
below show you how these will look in the Traffic Streams Data Screen.
Figure 18-15 Conflicts for Arm C1 (right-turn movement)

Page 370
Figure 18-16 All four conflicts for Arm B1 (right-turn movement)
Figure 18-17 Conflicts for Arm B1 (left-turn movement)
The data needed to define a conflict is as follows: For a given movement, first you need to specify
the “Controlling type”. Since we are using arm/traffic stream/lane structures throughout this
example, the “Controlling Type” required will either be “Traffic Stream Movement” or “Traffic
Stream”. If “Traffic Stream” was chosen you would need to specify the conflicting traffic stream and
this would mean all the traffic on that named traffic stream would conflict with the current
movement. In this example we wish to specify a full model and means that we need to specify that
the different movements conflict in different ways even when all the traffic conflicts. We therefore
chose “Traffic Stream Movement” (see Figure 18-15, Figure 18-16 and Figure 18-17 and Figure
18-18). This necessitates specifying where the conflicting movements come from and goes to, by
entering the “Controlling From Traffic Stream” and “Controlling To Traffic Stream” values.

“Percentage Opposing”: You also need to indicate what percentage of this movement is actually
conflicting – Often this will be 100% when using “Traffic Stream Movement” as is the case here.
TRANSYT allows you to specify this data to ensure TRANSYT remains generic in nature and therefore
flexible enough to model all situations you may encounter both in the UK and elsewhere in the
world.
The next required value is the “Slope Coefficient” (i.e. same as PICADY ‘slope’). This value
determines the rate at which the give-way capacity diminishes as the opposing traffic increases. See
section 27.5 if you wish to know more.
The “Upstream Signals Visible” defines how give-way traffic reacts to upstream signals – See 18.16
for fully details.
Give-way conflicts do NOT have to involve traffic crossing each other’s paths. Certain
movements can still influence the behaviour of traffic on non-crossing movements – This is the case
at T-junctions where the major road traffic takes a nearside turn into the minor road (A1/1 to Bx/1
in the example) affects the capacity of the minor arm B1.
At priority junctions, driver’s visibility can be reduced due the presence of adjacent lanes. On minor
roads where two lanes are present, it is well established that the nearside lane visibility is reduced
by the presence of the offside turning lane. This effect can be modelled simply by selecting the
option “Visibility Restricted” in the “Give Way Data” and setting the “Visibility Restricted By Link”
(or Traffic Stream) to the offside lane - the one causing the reduced visibility. This is a modelling
capability inherited from PICADY (TRL’s isolated priority junction modelling software).
The example T-junction does not have this set as there is only one lane on the minor road approach.
When using the Priority Object this value is set-up automatically whenever two traffic streams exist
on the minor arm.
This section briefly describes how to model priority junctions using a link network structure.
Alternative methods are described in earlier sections 18.2, 18.3 and 18.4. We recommend that you
read these sections too, as they contain information relevant to this method too.
Figure 18-12 show the standard links and link-shares needed to model a basic T-junction. The yellow
pentagons shown are two of the OD Matrix ‘locations’.
When using a link structure to model a T-junction you do not need to use an OD Matrix to specify
your traffic flows in and out of the priority junction, but it is worth considering as it makes it easier
to make changes to your flows and is less error prone. Details on how to use OD Matrices is in

Page 372
section 14.4. It is also worth considering using the T-junction Priority Object, as in this way you can
store all your junction data within the one software package.
Figure 18-18 Network structure using links and link-shares
The definition of links depends on the junction being modelled. In this example the main road left
approach is modelled using a shared link that models the traffic turning into the minor road. This
structure is equivalent to what is called “Full Blocking” in PICADY, which is the situation where the
traffic turning blocks the straight ahead movement, hence the use of a major and minor shared link.
If the particular layout shown is used it will produce identical results to the example T-
junction model that uses traffic streams instead.
If the main road traffic is not blocked by the turning traffic then it should be given a full link to itself
and so should the turning traffic, i.e. the links should not be shared.
If there are two lanes on the minor road you will need two full links. If approach flares out from one
lane to another the TRANSYT flare model (CPDM) should also be used.
The give-way data screen for a link is slightly different from that for a traffic stream. See below:
The Link “Give Way Data” is as follows:
“Same as Major Link”: This option allows the give-way data of the minor arm to simply
match that of the major arm – This is the default. On links 26 and 28 in the T-junction
example, we do not want to do this, as the model required the properties of the two links to
be different (e.g. different conflicts), hence this option has been deselected.

“Percentage Opposed”: Used to define how much of the traffic on this link is yielding to the
opposing traffic. In the T-junction example, 100% of the traffic on each of the give-way links
has to give way.
The T-junction example could have been modelled with a single link instead of
links 27 and 28. In which case, the straight ahead traffic (75%) on the combined link would
not be giving way, so the Percentage Opposed would be 25% instead of 100%. However, this
simplifying of the model prevents two separate max flows to be defined and as a result
would not produce quite the same results.
Figure 18-19 Link Give-way Data
“Opposed By Conflict 1 only”: This data item allows a percentage of traffic to be opposed by
only the first defined conflict. This option is no longer required in TRANSYT, but has been
retained for backward compatibility with previous versions. Imported files with this option
set will use this feature.
“Max Flow (Opposed)”: This the maximum flow that can be achieved when traffic is giving
way to one or more opposing traffic streams, but when that opposing flow is zero. N.B. this
IS not the same as not giving way at all. When give-way traffic behaves as if it is unopposed
then this situation can be modelled – see section 18.16 to find out how.
“Max Congested Capacity”: See Modelling give-way links in CTM. This item is only relevant
to the CTM model, so is a hidden item in this example.
“Use Step-wise Opposed Turn Model”: This item is only relevant to opposed turns at
signalled junctions.
“Visibility Restricted”: See section 18.7 for an explanation of what this option does.

Page 374
Crossroads are modelled either using a Crossroad Priority object or by setting up a series of give-
ways and their associated conflicts with other movements of traffic. Both of these methods use the
same processes as used to model Priority T-Junctions, hence in order to understand how to use this
object please refer to the information associated with the example T-junction in the previous
sections, starting with section 18.1
The main difference between crossroads and T-junctions is the number of conflicts that need to be
set up (in order to offer results comparable with PICADY) – Crossroads naturally have far more
movements of traffic through them, and hence require far more conflicts. We recommend,
therefore that you do not attempt to set these up manually, and instead always use the Priority
Object to do this for you.
Figure 18-20 Crossroad Priority Object
Roundabouts and priority T-junctions gives you the option of adjusting or specify your own slope
and intercept values instead of using those calculated by the priority object. However due to the
impracticality of allowing this facility for crossroads, these values are not reported nor editable from
within the priority crossroad object itself and are only reported on the conflict data of each traffic
stream (or links). These values may appear to be editable but are in fact read-only. See Figure
18-20 for an example.

Figure 18-21 Crossroad Conflicts
The “Visibility Restricted” option is not required for crossroads so can be ignored, and the “Use
Step-wise Opposed Turn Model” only applies to signalled give-ways, so can also be ignored.
Roundabouts are, in effect, a series of connected priority junctions, so it is recommended that to

understand fully how to model them in TRANSYT you should read section 18.4 , first to learn about
how to define give-ways generally and optionally section 27.5 as well. This section provides the
additional information specific to the modelling of unsignalised roundabouts in TRANSYT.
The easiest way to model an unsignalled roundabout is to simply load one of the supplied library
files. The library files use the new Roundabout Priority Object (see section 18.1) to allow the
roundabout geometries to be specified and the resultant give-way coefficients attributed to the
relevant traffic streams on the roundabout.
An example conventional four arm roundabout is used to illustrate how to build your model or to
adapt an existing library one. (See Figure 18-22) The model requires four “Entries” to be added to

Page 376
the Roundabout Priority Object – one for each approach. Exit-only arms do not require an “Entry”.
TRANSYT 15 needs only a minimum of ONE entry per roundabout object.
The steps described in section 18.5 are essentially the same, as each roundabout approach is treated
as a simple T-junction with one-way flow on the major arm. Traffic exiting the roundabout is
represented by either a set of traffic streams (or links) with unrestricted flow if the exiting traffic is
also leaving the network, or whatever traffic streams (or links) type is required for modelling of the
downstream situation within the network.
For the equivalent of step 6 (from section 18.5) - Add your “Give Way Data”:
Under ‘General’ give-way Data, a give-way link will have its property “Opposed Traffic” set (by
default) to “AllTraffic” (Outline: Traffic Stream n>Give Way Data). This means that all traffic in this
traffic stream is opposed by some other movement(s) irrespective of where it is going. This is the
case here, so there no need to change it. If you are using the roundabout object this value (along
with some other data) will always revert to the correct value even if you do try to change it!
The “Visibility Restricted” option is not required for roundabouts so can be ignored, and the “Use
Step-wise Opposed Turn Model” only applies to signalled give-ways, so can also be ignored.
Figure 18-22 Traffic Stream and Lane Structure of a roundabout
Under “Conflicts > All Movements” the “Max Flow (Opposed)” is simply the “ARCADY “Intercept”
and can either be entered directly or calculated for you if the Roundabout Priority Tool is used to

assign the intercept to this give-way traffic stream (or link). The “Percentage Opposed” can be left
at the default of 100% as all traffic will be giving way to the circulating traffic.
Figure 18-23 Roundabout Conflicts
For each approach you need to specify how many “Conflicts” exist – each conflict being a single
traffic stream (“Controlling Type” = “Traffic stream”). The specified conflicts should represent all
the traffic passing the entry. These conflicts will be automatically set up for you if you use the
Roundabout Priority Object.
You can specify multiple circulating traffic streams within the Roundabout Priority Object
Figure 18-23 shows how Arm 3 in this example has Traffic Stream 8/1 as its conflicting traffic. The
conflict should be associated with “All Movements” of the entering traffic stream, as there is only
one movement onto the circulating carriageway.
The “Percentage Opposing” should be set to 100% (default) to model the fact that the entering
traffic has to give way to all of the circulating traffic. It is automatically set to 100% when using the
roundabout object.
As was the case with “Max Flow”, the “Slope Coefficient” (the “ARCADY slope”) can either be
entered directly or calculated for you if the Roundabout Priority Object is used to assign the slope to
this give-way traffic stream (or link).
The definitions of the give-way geometric data is the same as for ARCADY. Full details of
these are given in the ARCADY User Guide, so are not repeated here.
For step 7 – Add your Roundabout Priority Object data:

Page 378
“Roundabout Type” can be either a “Standard” roundabout” or “Mini-roundabout” or “Large or

Grade Separated”.
The “Lighting” option can only be specified for mini-roundabouts - the conditions can be described
as either “normal/unknown”, “daylight” or “darkness”. “Normal/unknown” should be selected if
the effect of lighting is not to be modelled.
The “Road Surface” conditions can be described as either “dry” or “wet”. “Normal/unknown”
should be selected if the effect of road surface is not to be modelled.
If the junction is in London, the “In London” option should be selected. This factor affects capacity,
but only applies to mini-roundabouts.
“Entry Order” is only required for mini-roundabouts. Because data specific to mini-roundabouts
affects the capacity on arms other than one to which the data relates, the order of entries
(clockwise for drive-on-the-left and anti-clockwise for drive-on-the-right) is needed.)
Once the overall roundabout data is added, the give-way coefficients (ARCADY slope and intercept
values) are required for each approach (arm). When “Auto Assign Priority” is set, TRANSYT will
assign directly-entered or calculated give-way coefficients to the relevant traffic movements. In
order to do this, TRANSYT traffic streams or links need to be matched up with corresponding ‘entry’
and ‘circulation’ links within the Priority Object.
At the moment the Priority Object is limited to specifying just one of each. This is suitable for most
situations, but for situations for which it is not, the Auto Assign Priority option can be switched off.
In this situation, the Roundabout Priority Object can still be used as a tool to calculate suitable give-
way coefficients which can be attributed to the TRANSYT model manually to suit the particular
circumstances.
Figure 18-24 Roundabout Priority Object data

The entry “Type” value should be set depending on whether you are referencing traffic streams or
links.
The geometric data associated with each entry to a standard roundabout is shown in Figure 18-25.
The data required depends on the roundabout type chosen. The data is the same as that used by
ARCADY. Definitions of these can be found in the ARCADY User Guide.
Figure 18-25 ‘Standard’ Give Way Data per Entry
If required, the slope and intercept give-way coefficients can also be specified directly
rather calculated from the geometries and then auto-assigned to specific traffic
streams (or links) by switching off “Calculate Slope and Intercept”.
This option is particularly useful when site-specific adjustments are necessary to the
calculated slope and intercepts, as “Calculate Slope and Intercept” can be switched
on initially while values are calculated based on the geometries, and then switched
off to allow the calculated values to be adjusted subsequently.
Having added the data described above you should now be able to run TRANSYT. Your roundabout
can either be totally isolated or connected to other junctions as part of a network. Often storing
several variations of the same file in the same file can be useful, e.g. a fully unsignalled one and, say,
a partially or fully signalled one. As TRANSYT 15 tolerates different cycle times within a file, storing

Page 380
multiple signalled roundabouts with different cycle times in the one file is not a problem and can
also be an elegant way to store sets of alternative designs.
Flared approaches to unsignalled junctions should be modelled by specifying

the relevant flare length roundabout geometry value within the Roundabout Object, or in ARCADY
to work out the required give-way coefficients. The TRANSYT flare model (CPDM) should NOT be
used.
This section briefly describes how to model roundabouts using a link network structure. An
alternative method is described in the previous section 18.10. We recommend that you read this
section too, as it contains information relevant to this method.
Figure 18-26 shows the standard links and link-shares needed to model the same four-arm
roundabout. Examination of the library files is a useful way to understand the structure needed.
When using a link structure to model a roundabout you do not need to use any OD Matrices to
specify your traffic flows in and out of the priority junction, but they are worth considering as they
makes it easier to make changes to your flows and is a less error prone method. Details on how to
use OD Matrices is in section 14.4. It is also worth considering using the Roundabout Priority Object,
as this way you can store all your junction data within the one software package.
Figure 18-26 Link Structure of a roundabout

The link structure is generally the same as that used for signalised roundabouts other than the fact
that all the circulating links will be unrestricted links, and all the entries will be give-way links. Each
path through the roundabout that exists on-street must be provided for by way of a series of
connected links. Shared links are used to represent more than one path on the same physical road
space. This use of shared links allows the traffic from different approaches to be kept separate
within the model. There are simplifications, such as using just one full link to represent the
circulating carriageway, but the model will not then be equivalent to the alternative lane structure
method, will give different results, and most importantly will not correctly take account of
platooning effects that may be present within the traffic flows.
If the roundabout is not attached to any further network containing signalled lanes or
links, circulation carriageways CAN be represented by a single link, because there will not be any
platooning of traffic within the network. If you are intending to experiment with partial or full
signalisation of the roundabout it is recommended that you use the full link structure anyway for
consistency and ease of conversion to a signalled situation.
We also recommend that you read chapter 30 modelling signalled roundabouts in order to ensure
you fully understand the link structures required.
Mutual opposition is now tolerated by TRANSYT since adopting a revised PDM model. Give-way
parameters are specified in the usual way. Please note that a certain amount of calibration may be
needed in order to obtain the best results. As a starting point only, it would be reasonable to use
the typical coefficients suggested for opposed turns, i.e.
Max Flow (Opposed) = 715 PCU/h
Slope coefficient = 0.22
Please also note that the step-wise opposed turn model cannot be used for mutual
opposition situations.
This section illustrates a number of other give-way modelling situations in order to show how each
of them can and should be modelled. Data values are generally specific to the situation and
adjustments to conflicts will be needed to model specific situations not covered by these examples.

Page 382
18.13.1 T-junction with Two lanes on the minor road and no blocking of straight
ahead traffic by right-turners
Figure 18-27 T-junction with two lanes on minor road (using links)
To represent two separate lanes on the minor road – one carrying left-turning traffic and the other
right-turning traffic - the two links representing the minor road are not shared.
To represent the fact that traffic on the main carriageway is not blocked by traffic making an offside
opposed turn into the minor road, the link carrying the straight-ahead traffic is not shared with that
carrying the opposed turn traffic. It is also defined as a link with an unrestricted flow as no queueing
is expected on this section of road.
The links representing the main carriageway in the other direction as similarly set with unrestricted
flows. They can be shared or not-shared – it will make no difference in this situation.
All Percentage Opposing values should be set to 100%, since shared links have been used to
separate out the different movements.
The give-way conflicts needed (for the example shown) will be as follows:
LINK 26 (B-C, left-turn from minor): Opposed by LINK 23 and 24
LINK 25 (B-A, right-turn from minor): Opposed by LINK 23, 24, 27 and 28
LINK 28 (C-B, right-turn into minor): Opposed by LINK 23, 24
The traffic stream equivalent is not shown here as a general principle can be applied
that will help you to decide whether or not to use one traffic stream or two – If you would have used

shared links, then one traffic stream should be used, and if the link equivalent uses non-shared links
then two separate traffic streams are needed on that arm.
18.13.2 T-junction with one lane on the minor road

The only difference with the two-lane example is that the minor arm uses two shared links.
Figure 18-28 T-junction with one lane on minor road (using links)
18.13.3 T-junction with a turning bay on the main carriageway

The effect of the presence of a turning bay on the give-way coefficients is taken account of through
the geometry value for the major road “Width of C-B traffic”, when using the T-Junction Priority
Object, or by external calculation of the give-way coefficients.
The presence of an offside turning bay which will have limited length leads to what in PICADY is
called “partial blocking”. So called because the blocking can be described neither as “full blocking”
nor “no blocking” (as also referred to in PICADY), i.e. blocks back only when the bay fills up and spills
back to such an extent to block straight ahead traffic. For technical reasons it is not possible to re-
use the PICADY “partial-blocking” model inside TRANSYT, so TRANSYT cannot directly model this
effect.
However this situation can be set up as shown (see screenshot). Note that the short bay is not using
a blocking model such as CPDM or CTM. This setup, will allow you to assess the likelihood of
blocking back by examining the MMQ value of the bay. Note that blocking is likely to occur before
the MMQ matches the length of the bay since the MMQ is only an average.

Page 384
Figure 18-29 Priority T-junction with an offside turn bay
18.13.4 UK-style nearside slip-road giving way to exiting traffic on minor road.
This situation can be modelled with a few small changes to a standard T-junction library file. A
restricted traffic stream (or link) is added on the approach from the right in order to feed traffic that
is turning left into the side-road onto the slip-road. The slip-road itself is designated as a give-way
traffic stream (or link) as it gives-way to the other traffic exiting down the side-road. The give-way
coefficients can be calculated by the addition of another T-junction Priority Object or by entering
them directly.
Some adjustment to the calculated coefficients might be required in light of experience as this
situation is not quite the same as an average T-junction. Some differences in driving behaviour may
be observed due to the proximity of the slip-road give-way to the main junction. These effects are
likely to be minimal in situations where the distance of the slip-road give-way from the main T-
junction is considerable.

Figure 18-30 T-junction with slip-road
Figure 18-31 Model of T-junction with slip-road

Page 386
Situations arise within signalled junctions where traffic receives a green signal but must give way to
other traffic (i.e. not a fully protected movement). This occurs commonly for offside-turning traffic
which must give way to opposing straight-ahead traffic. In TRANSYT it is relatively straightforward to
model these situations. How to use TRANSYT to model the various offside turn situations is described
through a series of examples, starting with the simplest on-street situation. The examples will use a
lane structure rather than a link one to illustrate each example – The same basic principles apply also
to link structures.
All situations require specification of both signal control data and give-way data.
We also recommend the use of the step-wise opposed turn model, because it, as the name suggests,
takes account of opposed situations on a step-by-step basis. It is takes account of the opposed turn
research results published in Research Report RR67.
Please note that you cannot use this model where mutual opposition exists. For this, you must use
the method described in 18.14.8
All of the following examples assume the various scenarios are built from scratch – The
use of one of the supplied Library Files will, in most cases, offer the quickest and easiest way to set
up your model. Examples of each of the described situations are provided as Library Files.
18.14.1 Wholly opposed offside turn with no unopposed stage

In the situation where offside-turners do not benefit from an unopposed stage, they will turn through
gaps in the opposing flow. For situations where traffic waiting in front of the stop line at the end of
green can clear during the intergreen see section 18.14.2
Where the offside turn movement does not have an unopposed stage, it is likely that the traffic
demand for that movement is low. In the absence of an offside-turn bay (dealt with in the next sub-
section) it is most likely that the offside turners will share a lane with other movements. Occasionally
there might be a dedicated lane.

Figure 18-32 Simple signalised T-junction with opposed offside-turn movement
Shown in Figure 18-32 is a fully signalled T-junction where the offside turners from Arm 1 have been
modelled as wholly opposed.
The way to set this scenario up is:
1. Start off with each approach traffic stream defined as signalled controlled (e.g. Arm C1 > Traffic
Streams > Traffic Stream 1 > Is Signal Controlled) and hence also needs a saturation flow
specified. Same applies to Traffic Streams A/1 and B/1.
2. You also need to specify Arm C1 (the one with the opposed movement) as a give-way, i.e.
Traffic Stream 1 > Is Give Way)
At this point it is worth pointing out that there several different ways to model
opposed turn movements. However, the instructions here are simply the recommended ones
(using the RR67 step-wise model) – If you wish to learn more about ‘older’ methods that you
may still come across, or indeed still wish to use, please see section 18.14.8.
3. Now specify the give-way data (Arm C 1 > Traffic Streams > Traffic Stream 1 > Give Way Data).
Set the “Use Step-wide Opposed Turn model” to TRUE
4. This example has no storage in front of the stop line so the “Number of spaces” = 0
5. Enter the “Radius of Turn”. You have the option of entering this directly or letting TRANSYT
work this out from the geometry of your network diagram. The diagram MUST be scaled if
you chose the latter option.

Page 388
Figure 18-33 Simple signalised T-junction conflict data
You now need to define the actual conflict with the opposing traffic. N.B. the defining of conflicts is
designed to be flexible in order to allow as many situations as possible to be modelled. Therefore
there are a number of selections required to set any particular conflict. How to define conflicts
generally is described in 18.6.
6. For this example the turning traffic is being opposed by all traffic from the opposing single
traffic stream, therefore the “Opposed Traffic” data item should be left set to “All Traffic”.
(Traffic Stream C1/1 > Give Way Data > General Tab)
7. Now switch to the “Conflicts” tab (See Figure 18-33). In this example, the turning traffic is part
of a mixed stream (some are travelling straight on), so not all traffic is opposed. The
“Percentage Opposed” should be set to the percentage of turning traffic (Traffic Stream C1/1
> Give Way Data > Conflicts Tab).
N.B. The “Max Flow (opposed)” is simply the Saturation Flow which you’ve already specified,
and this is not editable from here.
8. Add a Conflict. The controlling type is set to whatever the opposing item is – a Traffic Stream
or a Link. In this example it is a Traffic Stream.
9. For this example you need to set the Controlling traffic Stream to A/1” – the traffic stream that
carries the opposing traffic.
10. Set the “Percentage Opposing” – In this case – leave as 100%

11. Specify the Conflict Shift and Conflict Duration values. Full details of these are described in
section 18.14.7 which gives full details of the step-wise opposed turn model. Generally,
“Conflict Duration” should be left as “2” and “Conflict Shift” set to the clearance time between
the conflicting traffic.
18.14.2 Opposed offside turn with storage in front of the stop line
In the situation where offside-turners do not benefit from an unopposed stage, they will turn in gaps
in the opposing flow, and those waiting in front of the stop line at the end of green will clear during
the intergreen, as illustrated in this example.
Figure 18-34 Signalled opposed offside-turn movement with storage
As shown above, there is additional room for right turners to store out of the way of other traffic. This
will give additional capacity by allowing more vehicles to store before blocking the other movements.
Fortunately this is relatively easy to model in TRANSYT – and the use of the supplied Library File for
this situation can speed up the modelling process.
The recommended method involves modelling the right-turn storage explicitly by adding a short traffic
stream in the middle of the junction which is long enough to store the number of PCUs expected (see
Figure 18-34). This additional lane has the right turn give way parameters. An alternative method is
described in section 18.14.2.1.
The situation requires the following to be set up:
1. The approach to the opposed turn (Arm C1) should be defined as a normal signalled traffic
stream (with a saturation flow restriction), i.e. it is NOT a give-way traffic stream.

Page 390
2. An additional traffic stream (on Arm C2) needs to be created to represent the storage area in
front of the stop line for offside turners. This should be a give-way with saturation flow -
‘Give-way’, because it is giving way to opposing traffic, and ‘Has saturation flow’ as this value
is needed by the RR67 step-wise opposed turn model.
3. Traffic Stream C2/1 also needs to be set to use the FLARE traffic model (Traffic Stream C2/1 >
Traffic Model = “Flare”) so that the vehicles waiting in the middle stop the vehicles on Arm 1
from proceeding. How many vehicles store in front of the stop line can be left for TRANSYT to
work out from the link length, or by specifying your own maximum queue storage value.
Where an early cut off situation is being modelled (with an offside turn
indicative green arrow) the use of a separate traffic stream will ensure that any bonus
capacity that exists from this situation will be automatically taken account of by TRANSYT -
There is no need for any additional adjustment factors. Even where the green arrow phase
may be particularly short and the storage area extensive, the reduced benefit of the early
cut-off in this situation will be taken account of automatically.
4. The give-way data needs to be set up for Traffic Stream C2/1 – see the previous example for
how to do this. The only difference in this situation is that the percentage of opposed traffic
will now be left as 100% as the storage area only contains turning traffic.
5. Please note that the step-wise model data “Number of spaces” = 0, despite there being storage
in front of the stop line. This is because we are already choosing to model the storage
explicitly using its own traffic stream – This value if it were set, would represent storage in
front of the storage!
In this example there is a no traffic node between Arms C1 and C2, as it is not needed –the OD Matrix
property “Allow Looped Paths on Traffic Nodes” ensures that the required path creation will
unaffected by the fact that both C1 and C2 are associated with the same Node (Node 1).
18.14.2.1 Older method for modelling storage in front of stop lines
An older way to model the situation where traffic stores in front of the stop line and clears
during the interstage, is to skip using an explicit traffic stream all together, and to model the
bonus capacity that results by adding an appropriate end displacement (Controller Stream 1>
Phases > Phase N > “Relative End Displacement”). The time to add is 3600/sat flow x storage.
This method, although straight forward, is not ideal if you expect to have to
change the stage order or phasing. Stage re-ordering may invalidate the use of the relative
end displacement, since clearance in the interstage may no longer be available. For this
reason, if you think you may be changing the stage order or phasing (e.g. using TRANSYT’s
phase and stage optimisation), you should use the recommended method in which the storage
area is explicitly modelled using its own traffic stream.

18.14.3 Opposed offside turn with a turn bay
Figure 18-35 T-junction with offside turn bay
Where a right turn bay exists, as shown in Figure 18-35, there is additional room for right turners to
store out of the way of other traffic. This will give additional capacity by allowing more vehicles to
store before blocking the other movements. This situation requires the addition of a second traffic
stream at the stop line.
Traffic Streams on Arm C1 need to be modelled with the traffic model set to “Flare”. Using a model
like this allows the blocking by right turners of the other movements to be modelled.
Traffic Stream C1/1 representing the straight ahead lane, should be defined as signalled.
Traffic Stream C1/2 representing the right-turn bay, should be defined as a both signalled and as a
give-way. Give-way parameters will be the same as those described for the basic example in section
18.14.1

Page 392
18.14.4 Opposed offside turn with a turn bay and storage area
Figure 18-36 T-junction with offside turn bay and modelled storage
Where a right turn bay exists, as shown in Figure 18-36, there is additional room for right turners to
store out of the way of other traffic. This will give additional capacity by allowing more vehicles to
store before blocking the other movements. This situation requires the addition of a second traffic
stream at the stop line and a third traffic stream to model the storage area in front of it.
Traffic Streams on Arms C1 and C2 all need to be modelled with the traffic model set to “Flare”. Using
a model like this allows both the storage in the middle of the junction, and the blocking by right
turners of the other movements to be modelled.
Traffic Stream C1/2 representing the right-turn bay should be defined as only signalled, i.e. NOT a
give-way.
Give-way parameters will be the same as those described for the ‘storage’ example in section 18.14.2.

18.14.5 Standard two-lane situation

Consider the situation where there are two lanes on an approach without ‘bays’ or flares, with an
opposed right-turn movement. The main consideration is whether the offside lane will contain just
right turners, or a mix of traffic. If the lane is marked for right-turners only, it would normally be
expected to carry just right turning traffic. A separate traffic stream or link for this movement would
be required in this case. If, however, straight-ahead traffic is permitted to use the lane, then it is a
question of how much right-turn traffic there is: light demand will allow straight-ahead traffic easier
access to the lane, whereas heavy right-turn demand will discourage straight ahead traffic from using
it. You have to decide, either by on-street observation, by some common-sense based calculation, or
using TRANSYT’s lane balancing and flow assignment processes, what the mix of traffic on that lane
will be. Where there are a high proportion of right turners in the offside lane, some straight-ahead
traffic might be able to get to the front of the queue ahead of right-turners who might otherwise block
them. The number able to do this (on average) depends on the proportion of straight-head’s to right-
turners, and on driver behaviour. But it might be enough to give a small increase in capacity which
might be worth modelling with an increase in saturation flow for example. On the other hand, even if
straight-ahead traffic is unimpeded by the right turners, the saturation flow will still be reduced as the
right-turners divert and leave gaps in the traffic flow. Having decided the mix of traffic in the offside
lane, you need to specify the give-way parameters for the opposed movement as indicated earlier.
Where there are two lanes on the approach with the opposed offside turn movement, there is a high
chance that there will be two lanes opposing the right turners and these lanes might form two
separate links. With TRANSYT 16 any number of ‘conflicting’ traffic streams can be accommodated.
To do this use the ‘add conflict’ facility and specify the conflicting traffic streams. Account is taken of
the increase in distance an opposed vehicle has to travel before crossing all conflict points by
specifying a longer Conflict Shift value for the furthest conflict, and that the opposing flow is now using
more than one lane.

Page 394
18.14.6 Two-lane situation with a turn bay
Figure 18-37 Two-lane approach with additional opposed-turn ‘bay’
Sometimes, a multi-lane approach may include a right-turn bay. This situation is relatively easy to
model, simply by making use of the capabilities of the blocking “Flare” traffic model.
Whether or not the bay can cope with the turning traffic will be taken account of by modelling the bay
area as a “Flare” traffic stream or link. The part of the adjacent (middle) lane that is next to the bay
will also need to be modelled as a separate “Flare” traffic stream. Both of these will be fed by the
offside approach lane which can be modelled simply as an unsignalled traffic stream with a saturation
flow.
Having created the network structure and selected the relevant traffic models to use, the remaining
task is to assign traffic to the network in an appropriate way. The Lane Balancing OD Matrix option
can be used to distribute traffic to the various traffic streams. However, in light of additional local
knowledge you may wish to adjust the allocation of flows to better match your own predictions. This
can be easily done by switching the Allocation Type on certain paths through the junction from
“Normal” to one of the other options.

Figure 18-38 Diagram overlay shows where the Flare (CPDM) model is used.
18.14.6.1 Alternative method using quick flares.

If using only quick flares to model this situation, rather than setting the Traffic Model to “Flare”, it is
necessary to know whether the bay is large enough to store all of the right-turn demand or not. Once
you have decided whether the bay can cope with the demand or not, the traffic stream structure can
be set. If the bay can cope with the right turn demand, the approach could be specified as two or
maybe three links (including a short one to model the effects of the centre lane). Whichever way it is
modelled, the capacity of the offside lane will be affected by the proportion of right-turners in the
stream. The greater the number of right turners present, the fewer straight-ahead vehicles in the
lane.
If the right turn is not especially critical, it would be possible to use three traffic streams, with the
saturation flow of the ‘middle’ lane reduced in proportion to the number of right turners. The fact
that right turners can then queue in their own traffic stream in TRANSYT, whereas in reality they might
not all be able to reach the stop line, may not matter too much. If, however, the proportion of right-
turning traffic is high (but still not enough to fill the bay) it might be better to model the situation with
one traffic stream feeding two further traffic streams representing the bay and the adjacent portion of
the main lane. If the bay does fill up, it will effectively make the upstream offside lane a right turn only

Page 396
lane. In this situation (seen in Figure 18-37) there will be some space ahead of the point where the
right turners divert into their bay. This extra space can be fully used by the straight ahead traffic
(whether they actually use the space is another matter). In many cases it may prove difficult to find an
ideal modelling solution to your problem. However, with the application of common sense and
experience it should be possible to find a solution that meets your particular requirements.
18.14.7 Using the step-wise opposed turn model

TRANSYT uses a method of modelling opposed offside-turns within traffic signals that is superior to the
traditional TRANSYT 12 opposed offside-turn model traffic signals. In the traditional method, the
defined opposed saturation flow is assumed not to vary over the opposed green time and the required
data items are maximum flow (opposed) and slope coefficient. The new model derives a give-way
capacity which varies from time-step to time-step according to the opposing flow for each step.
To activate this model the ‘Use Step-wise Opposed Turn Model’ option is set. When set, the maximum
flow (opposed) and slope values are not required, and two new pieces of information (RR67-related)
are needed instead – the number of storage spaces available within the intersection which offside-
turners can use without blocking straight-ahead traffic and Radius of Turn (m) which is the radius of
curvature of offside-turning vehicle paths. You have the option of letting TRANSYT work out this value
from the geometry of the network diagram. If this option is selected the network diagram MUST be
scaled to match reality.
Figure 18-39 Required step-wise opposed turn model data
The step-wise (RR67) opposed turn model is only relevant to signalised give-way
situations and should not be selected for other situations.

The requested “number of storage spaces” is NOT used to calculate the additional
capacity due to those vehicles storing in front of the stop line which clear during the
intergreen. This particular effect should be modelled either explicitly using the
recommended method already described, or the older method which requires an
extension to the effective green using a Relative End Displacement on the relevant
phase.
A further two parameters, that only apply when the step-wise opposed turn model is used, are also
required:
The first of these is the Conflict Shift. This is the delay between the controlling flow departing and the
controlling flow influencing the give-way. This has the effect of delaying both the increase in opposed
flow once traffic passes (e.g. clearance time), and also the drop in opposed flow when a platoon of
opposing traffic enters the junction (i.e. reaches the stop line). The influence of the opposing traffic is
essentially shifted (delayed) in time. The value set will depend largely on the geometry of the junction
(e.g. size), but generally will be a small positive number of seconds (i.e. not zero).
The second of these is the Conflict Duration. This is the time by which to delay the establishment of
discharge after a reduction in flow on the conflicting arm. It is in effect a ‘give-way equivalent’ to the
start displacement for a signal controlled stop line and allows for the time it takes for vehicles to get
moving after a gap in the opposing flow has appeared. It would normally be about 2 seconds.
Without this, the results may be slightly optimistic. The data can be found at Traffic Stream N > Give
Way Data -> All Movements > Conflicts > opposed by Traffic Stream X. N.B. it has no influence during
times when the opposing traffic flow is rising.
18.14.8 Alternative way to modelling opposed offside turns

An alternative to using the “step-wise opposed turn model” is to specify a slope (maximum flow) and
intercept (the rate at which opposing traffic reduce the opposed capacity).
Although the best give-way coefficients for each situation will vary from situation to situation, it is
suggested that the approximation given below can be used as a starting point. The values need to be
adjusted to represent the site-specific on-street situation.
F = 1000 - 0.5q
This approximation is only a ‘rough and ready’ solution. Adjustments

should be made in the light of practical experience. Alternatively, use
the step-wise (RR67) opposed turn model for greater accuracy.
The values shown may be acceptable approximations where the degree-of-

saturation on the opposing arm is above 50% and where the right turn is not
critical to the junction’s performance. Below 50%, the figures can become
somewhat pessimistic.

Page 398
1. Only specify give-way movements that you need – if never opposed you don’t need it AND
separate movements are only needed if their characteristics are different.
2. At a T-junction, the traffic making the near-side turn into the minor road has a lesser effect
on the minor road capacity than the straight-ahead traffic does. The effect of the turning
traffic (whose paths don’t even cross) is approximately a third of that caused by the main
road straight ahead traffic. Missing this effect out is not likely to be critical, and will produce
a slightly pessimistic result for the performance of the junction. This means one less link on
the main road and one less movement, and hence a conflict referenced by three other
movements that you no longer have to specify.
3. If using a link structure to model a roundabout, use a single link for the circulating
carriageway, but only if none of the traffic on the approaches are platooned.
4. Use Library files as much as possible as it will speed up construction of your network and
reduce errors too. Be sure to check each data value though, to ensure that they are set
correctly for your particular network requirements.
5. Some simplifications and suggested give-way parameters are described in section 27.5.2.
Using a give-way with a saturation flow (i.e. a give-way bottleneck) allows a situation to be modelled
where the maximum capacity or saturation flow is likely to change from one mode of operation to
another, due to drivers KNOWING that the opposing traffic is being held up.
It can be used for any of the following situations, but not limited to:
 Nearside slip lanes (by-passing a signalled junction)
 give-ways downstream of a signalled pedestrian crossing
This effect is generated by drivers not having to pause at the give-way line to check for opposing
vehicles before making their turn because they know that there wouldn't be any opposing vehicles.
A give-way traffic stream (or link) with a saturation flow is one that is controlled by the saturation
flow when the opposing traffic is stopped at a red signal, but is controlled by the give-way
parameters (maximum flow) when the opposing flow is given a green signal. (In earlier versions of
TRANSYT this was known as a “give-way bottleneck”.)

Figure 18-40 Specifying that upstream signals influence a give-way bottleneck
To set one up is straight-forward: Firstly you need to specify a traffic stream (or link) as a give-way
WITH a saturation flow and enter both the give-way and saturation flow data. If the controlling
traffic stream (or link) is signalled, that is all that is required. However, if the controlling traffic
stream (or link) is not itself signalled the effect you wish to model will not operate, as the controlling
traffic stream (or link) would normally have to be signalled. However, the conflict option “Upstream
Signals Visible” (see Figure 18-40) allows, say, a controlling traffic stream (or link) to be a restricted
or unrestricted traffic stream (or link) and still take account of the effect of any upstream signals. An
example has been produced below to indicate how this is set up and its effect on the restricted
traffic stream’s (or link’s) OUT-profile.
Figure 18-41 Example of near-side slip lane

Page 400
Figure 18-42 Near-side slip lane modelled in TRANSYT
If all the controlling links upstream are at red and this link has zero out flow and zero traffic on the
link then the conflict is modelled as unopposed. This means that TRANSYT assumes that drivers can
see the upstream signals and that there is no traffic between the signals and them and will therefore
cross the give-way line at the higher saturation Flow rate defined by the restricted flow value,
instead of the maxflow associated with the give-way.
Figure 18-43 OUT-profile from the give-way
The OUT-profile in Figure 18-43 clearly shows the expected three levels of out flow – initially running
opposed, then discharging at saturation flow, and finally free flow (once any queue has dissipated).

Working with Traffic Models Page 401
This chapter describes how to correctly make use of various options which influence how the chosen
traffic model behaves, and are not described elsewhere in this document.
The selection of the traffic model for each traffic stream (or link) is one of the more important
decisions to make when constructing a TRANSYT model. Choosing the right model for each
circumstance ensures that you get the best, most accurate representation of your network. If
unfamiliar with the traffic models, it is recommend that you read Chapter 26 (Traffic Behaviour
Models (Non-simulation)) which contains full descriptions of each of the models, advice on selecting
the right model, and the pros and cons of each.
How you can select the traffic models is described below:
The traffic model can be set either globally for the whole network (Outline: Network
Options>Traffic Options) or for each individual traffic stream or link (Outline: Arm n >Traffic Streams
>Traffic Stream n >Modelling).
Figure 19-1 Selecting network-wide and local traffic models
The Link or Traffic Stream options for Traffic Model are as follows:
 Network Default: Select this if you wish the network (global) value to determine what
option is used for this traffic stream (or link).

Page 402
 PDM: Select this if you wish to select the platoon dispersion model in order to model
platoon dispersion along the length of this particular traffic stream (or link), AND model no
blocking effects that it may cause upstream of it.
 CTM: Select this if you wish to use the cell transmission model to model the blocking back
effect on upstreams, caused by this particular traffic stream (or link).
 Flare: Select this if you wish TRANSYT to model the limited capacity of a short lane, i.e. one
that is liable to block back and prevent traffic from entering it or other flares that it may
block. Only those traffic streams or links that are liable to block or be blocked need to be set
up to use the appropriate “Flare” traffic model.
At the network (global) level, the following Traffic Model options are available:
 PDM / CTM: Select between Platoon Dispersion and Cell Transmission models.
 Link by Link PDM: Select this alternative PDM model if you want significantly
faster run times, and are prepared to avoid using the CTM and CPDM models at a
local level. Flares will need to be modelled as “Quick Flares”
 Force To PDM / Force To CTM: Select one of these options if you wish to FORCE all links and
traffic streams to use the chosen model irrespective of what local value has been set. This is
useful if you quickly wish to investigate the effect of, say, using the PDM model throughout
the network.
 Force to PDM and Flare: Select this option if you wish to FORCE all links and traffic
streams to use the chosen models irrespective of what local value has been set.
This is useful if you quickly wish to investigate what would happen if you did not
model blocking back into upstream junctions, while retaining the modelling of any
CTM or CPDM flares.
The network diagram overlay “Traffic Model Type” can be used to inspect what traffic streams and
links are modelled using which model.
These parameters are only accessible if a file is in Advanced Mode.
“Vehicle-in-service” is a modelling coefficient that relates to the calculation of vehicle delay. It is

included if vehicles have to slow down or stop, as at priority junctions, or not included if they can
move freely across the stop line, as during the green phase at a traffic signal. TRANSYT allows the
value to be directly set to cater for ‘ambiguous’ modelling situations.
The “Random Parameter” is a modelling factor that defines the randomness of the queueing
situation on a traffic stream (or link) and relates to the calculation of queues and delay.

These new modelling parameters are just part of the necessary changes to TRANSYT to allow it to
model fully unsignalised junctions and to remove the assumption that networks have to be
predominantly signalised.
These values can be set either globally for the whole network (Outline: Network Options > Traffic
Options > Advanced) or for each individual traffic stream (or link) (Outline: Arm n > Traffic Streams >
Traffic Stream n > Modelling > Advanced).
This is an advanced feature of TRANSYT and unless you have very specific/exact
modelling requirements, it is recommend that the global value is set to “Automatic”, while all the
individual links are left at their default of “Network Default”.
Figure 19-2 Vehicle-in-service and Random Parameter options
The Link or Traffic Stream options for Vehicle-in-Service are as follows:
 Network Default: Select this if you wish the network (global) value to determine what
option is used for this traffic stream (or link).
 Automatic: Select this if you wish the TRANSYT internal logic to work out which option is best
for this traffic stream (or link). If the item is an unsignalled give-way then the Vehicle-In-
Service will be INCLUDED and if not, it is NOT INCLUDED.
 Uniform (TRANSYT): Select this if you wish to assume uniform queueing – This option sets
the NOT INCLUDED in-service delay, and is what all previous versions of TRANSYT have used,
irrespective of the link type.

Page 404
 Random (ARCADY): Select this if you wish to assume random queueing – This option sets the
INCLUDED in-service delay, and is, essentially, what all versions of ARCADY uses.
 Custom: This allows you to select the in-service coefficient manually – i.e. INCLUDED or NOT
INCLUDED.
At the network level, the following Vehicle-in-Service options are available:
 Automatic: Select this if you wish the TRANSYT internal logic to work out which option is best
for every traffic stream (or link) which has been set to the Network Default option.
 Uniform (TRANSYT): Select this if you wish to assume uniform queueing for every traffic
stream (or link) which has been set to the Network Default option.
 Random (ARCADY): Select this if you wish to assume random queueing for every traffic
stream (or link) which has been set to the Network Default option.
 Force To Automatic: / Force To Uniform: / Force To Random: Select this if you wish to
FORCE all links and traffic streams to use these options irrespective of what local value has
been set. This is useful if you quickly wish to investigate the effect of, say, using the same
options that TRANSYT 13 uses, i.e. “Force to Uniform”.
The options for the Random Parameter are as follows:
The options are basically the same as those provided for vehicle-in-service and offer the same ability
to force the global network value on the individual links and traffic streams. The main difference is
the actual value used as the Random parameter for each of the options:
Uniform (TRANSYT): This sets the value to 0.5 – the value used for all links in all previous versions of
TRANSYT, and represents a partly random queueing situation, which is generally an appropriate
value for predominantly-signalised networks.
Random (ARCADY): This sets the value to 1.0 – the value used on all arms/approaches in all previous
versions of ARCADY, and represents a full random (unsignalised) queueing situation.
Custom: This allows you to select the random parameter coefficient manually. If an upstream
arrival pattern is deemed to be particularly consistent, there may be scope to reduce the random
parameter below 0.5, but generally there will be no justification to reduce it to zero or near-zero, as
no matter the situation, no arrival pattern of flows will be without some randomness. Furthermore,
one has to remember that TRANSYT was empirically developed and extensively tested/validated for

use with signalled networks, all of which included the use of a random element of delay of 0.5
throughout.
If unsure what value to set for the Cell Saturation Flow, a good starting point is to simply let
TRANSYT automatically set the values to 1800 PCU/hr per lane. In most cases you will not need to
alter these values.
Alternatively, you could set the values to what RR67 would give you if all traffic was assumed to be
going straight ahead, summed for each lane represented by the traffic stream. You can also take
account of the standard RR67 reduction for a kerbside lane. Using this method will ensure that the
relatively high initial capacities that are achieved at the upstream end of the downstream traffic
streams (due to short headways) are modelled. However, you may wish to use a lower cell
saturation flow that more realistically reflects the overall capacity of the traffic stream.
Traffic stream capacity (as opposed to stop line capacity) is determined by 'headway' - which is
affected by many factors including, but not limited to, vehicle speed, lane width, road works, parked
vehicles, % of heavy vehicles, weather conditions. Taking account of these effects can improve the
accuracy of your model.

Page 406

Working with Results Page 407
In TRANSYT, results are generated when you run a file. There are several types of results:
 Basic results for each traffic stream (or link), such as each item’s Degree of Saturation
 Basic results for the whole network, such as the whole network Performance Index, which
are calculated by summing and/or averaging individual traffic stream, link and controller
stream results
 Basic results for parts of the network, such as collections, or bus network. You can see such
results by generating reports or by setting up Data Grids to show such subsets. User-defined
custom data grids and TRL’s default data grids are accessible from the horizontal toolbar
“data grid” button/dropdown.
 All of the above for each time segment, and additionally for a summary time segment. (This
is only applicable if there is more than one time segment defined.) All of the above are
visible in the Data Editor and in Data Grids.
 Detailed results from the different traffic models in the form of graphs and also equivalent
animations in the network diagram.
Results can be viewed in various places, such as:
 Summary Results screen

 Data Outline sections (use the Results button on the main toolbar to jump to these sections)
 Reports
 Network Diagram overlays
Basic results are saved in the file when you save it - To generate animation and graph data the file
needs to be re-run. The animation and graph options available will depend on what traffic models
have been used.
Remember that results are those from the last successful run of the traffic model. If you
subsequently change input data but don’t re-run the model, then the results may be
inconsistent with the current data file. In general, results are shown with a red
background if the file has changed since the last run; this will change to a green
background once the file has been run.
Remember also that results are displayed for only one Analysis Set at a time.

Page 408
The Summary Results screen shows a summary of the results from the last run of the
file. It is shown automatically whenever you run the file. To show results from the
last run, you can also click this button on the main vertical toolbar.
The results shown in this screen are key results associated with a run of TRANSYT. The Highest DoS
value is the highest value across the whole of the network. If multiple time segments are present,
the results shown are for the selected time-segment only (selected via the time-segment drop-
down). The values shown here are also available through the Data Outline in the Network Results
sections. For more detailed results, study the individual results using the Data Outline, Data Grids,
or by generating a report.
 Use the Show menu to control whether to show all Analysis and Demand sets (as shown in
the screenshot), or, more simply, only the currently selected set. See Analysis/Demand Sets
and Summary Results (section 13.3) for a full discussion of the use of the Summary Results
screen with Analysis and Demand Sets.
 Also use the Show menu to control whether to show Collections. Collections can ber set up
to represent any subset of a network, but are particuarly useful for reporting the
performance of individual junctions (once defined as a set of Collections).
 If showing all sets, then a bold font is used for the results for the currently active
Analysis/Demand set pair. In the screenshot above, the user is currently working with the PM
– 2026 Scenario.
 Use the Columns menu to control which results should be shown.

Results for all Analysis/Demand sets are stored in the file. This means that even if
showing results for one set at a time, you can change set and the results for that set will be shown.
Further functionality of this screen relating specifically to its use with multiple Analysis Sets and
Demand Sets is described in section 13.3
There is more than one place to examine the detailed results produced by TRANSYT:
 A full set of individual results can be produced as part of the TRANSYT Report. (See chapter
22 for a detailed description of each of the individual results found within the Report.)
 The Data Outline (see below) contains results data as well as input data. The results are
displayed within the Data Editor. Any data item that is a result, i.e., an output from TRANSYT,
is shown with a light green background (or light red if out-of-date):
When looking at results, some items may appear greyed out. This is usually indicates the
results are not available for that item because it is inapplicable. You can check this by
showing the Help>Glossary screen. In many situations inapplicable data items will simply be
hidden from you. Some totals may also appear with “N/A”. These will usually occur because
some items in the list of items being summed are unavailable.
 Data Grids (see below) can also be used to display results, either as they are, or in a
customised format (see section 10.1.11 for how to use data grids to show results.)

Page 410
Use the animation controls (press the Animate button on the main vertical toolbar) to show a screen
where you can turn on and off animation in the network diagram. When animation is turned on, a
time-bar will cycle through the network cycle, and this will be reflected in signal states in the
network diagram, queue/flow animations in the network diagram, and also in time-lines that are
visible in the Timings Diagram, Stage Sequence diagram and network diagram timing wheels.
When multiple cycle times exist within the network there will be multiple time-lines displayed.
See the network diagram (Chapter 11) for details of the items that can be animated.
After running a file, you can view various graphs for each traffic stream or link. Flow Graphs and
Spatial Graphs are accessed via buttons on the vertical toolbar. Both the Time distance diagram
(TDD) and PI-Offset graphs are accessed from Main Menu > Tools.

You can display any number of each graph type; each graph will update to show data for the current
item unless you use its padlock (see section 7.11). Each graph can be stretched to whatever size is
required.
Signal states shown in the graphs can either show actual or effective greens; change
your preference via the option at the bottom of the graph.
The graphs types available will depend on the traffic models used for the selected
item and whether you have yet run the file; use the Summary Results screen to
confirm that the required “run data” is available.
All graphs can be copied to the clipboard (via right-clicking).
You can include Cyclic Flow Profile graphs and also, for the first time Spatial Traffic Graphs in
reports by adding entries to a grid of graph items, accessed from Main Menu >Tools>Graphs to
include in reports. These can be arranged in either one-column or two-column format.
Please see elsewhere in this manual for background discussions of the various graph types. They are
listed below, with an example shown for each.
Note that you do not have to 'run' each graph separately. After running the file once, all graphs for
all traffic streams and links are available; simply select the graph type via the Graph buttons on the
main vertical toolbar, and then select the traffic stream or link of interest, via the Data Outline or
the network diagram. You can show several graphs at once, and each graph will update to show
data for the current item, unless you lock it.
20.4.1 Flow Graphs (including Cyclic Flow Profile Graphs)

A variety of flow graphs are provided. The main graph type is the standard “Cyclic flow Profile”
(CFP) graph which plots the variation over a complete cycle of the rate at which traffic ‘arrives’ at the
stop line (the IN-profile) and leaves the stop line (the OUT-profile). An example of a CFP graph is
shown. Further explanation of the ‘IN’, ‘OUT’ and ‘GO’ profiles can be found in section 26.1.2
Each CFP graph represents, for one traffic stream (or link), the variation during one signal cycle
(horizontal axis) of:
a) The flow up to the stop line (red and green bars)- the IN-profile
b) The flow leaving the stop line (green and blue)- the OUT-profile
The two flow profiles are overlaid so that the flow distortion caused by the red/green periods of the
signal can be observed easily. Vehicular flows, shown in red, are stopped by the red light and leave at
a later time at saturation rate as shown in blue.

Page 412
Details of where the traffic comes from are indicated and the red and green times of the relevant
(feeding) upstream traffic streams or links are shown. The green times shown are displaced
forward by the cruise time between the source item and the downstream end of the item being
viewed. Therefore, the arrivals from the sources should more or less correspond with a vertical line
dropped to the stop line on view. The offset used is displayed to the right of each source red/green
times.
The CFP graph’s primary role is to help with validation and calibration of the TRANSYT model. It is
unlikely that all data specified is correct first time and even if no coding errors are made, the model
may be based on inaccurate assumptions about traffic behaviour. Comparisons can be made
between on-street arriving and leaving traffic patterns and those presented by the CFP graphs. CFP
graphs are also useful in understanding the interaction between different traffic streams.
Furthermore, CFP graphs give a quick visual indication of how well co-ordinated the signals are for
each traffic stream (or link). This too can be compared to the on-street situation to ensure that the
model is as accurate a representation of the real-life situation as possible. The greater the delay
imposed by the signals, the greater will be the difference between the IN-profile (red and green) and
the OUT-profile (green and blue). The more green and the less red, the less delay is being caused to
traffic on the traffic stream (or link).
The vertical axis of each graph shows the traffic flow per hour.
The horizontal axis of each graph is adjusted to the number of steps in one cycle. This axis comprises
red and green boxes for the red and green times at the link exit respectively.
The CFP graphs have a number of other features:
1. The time-axis can be rotated in order to align different graphs to the same time at the origin
(such as the network’s arbitrary zero) to allows graphs of related links to be more easily
compared.

2. The link length in metres is also given on the left-hand side of the queue graph - Useful as it
influences the total dispersion effect along the link.
3. The Performance Index for the chosen item is shown on the left-hand side.
4. The Mean Modulus of Error (MME) is shown on each graph. This refers only to the arrival flow
at the stop line and is a measure of how far the profile of the arrival flow deviates from the
mean value.
The MME is expressed as a number in the range 0.0 to 2.0. A uniform flow for example has a
MME of 0.0, while a high MME would indicate an item on which the flow was strongly bunched
or platooned and which would therefore benefit particularly from efficient co-ordination of
signals. The MME is similarly useful for selecting items on which co-ordination of signals is not
very significant (low MME) and which would therefore be suitable for the location of sub-area
boundaries if it should be necessary to break a region into smaller sub-areas.
A general rule-of-thumb is that for a MME of less than 0.3 the item may not be worth
considering for coordination.
In addition to the standard Cyclic Flow Profile graph there are a number of other Flow graphs available.
These are selected via the dropdown box at the bottom left of the Flow Graph. These (and there
functionality) are described below:
 InFlow – This shows just the in-flow portion of the “normal” graph
 OutFlow - This shows just the out-flow portion of the “normal” graph
 EntryFlow - This shows just the entry-flow portion of the “normal” graph
 GOFlow – This shows what the outflow would be if the traffic stream (or link) was fully
saturated, and no blocking was occurring.
 GOFlowWithBlock – This shows what the outflow would be if the traffic stream (or link)
was fully saturated, with existing blocking effects taken account of.
 Occupancy - This shows the relative occupancy along the length of the traffic stream
(or link) at any point in the cycle. How the graph looks depends on the traffic model
used – CTM, being spatially aware, will tend to be easier to interpret. When using
PDM, the way the model simplifies real life, results in the graph excluding the stop line
and hence excludes any queuing or evidence of the effect of any stop line restriction
such as a red signal.
 Pointflow – This graph is used in combination with the Point (m) ‘distance’ value to
show the flows at any point along the traffic stream (or link). This can help to match up
an observer’s location when collecting on-street data with the predicted shape at
exactly the same point within the model. This is of most use when the links and queues
are long resulting on-street measurements having to be made significantly upstream of
the stop line. The two diagrams below show the flow profile at the upstream end of

Page 414
the traffic stream (at 0 meters) and at four-fifths of the way down steam (at 80 metres).
The effects of platoon dispersion can clearly be seen.
20.4.2 Spatial Graphs

There are four types of spatial graphs. These are selected via the dropdown box at the bottom left of
the Flow Graph. The choice you have is “Flows”, “Occupancy”, “Queue” or “Traffic”. The graph types
also match up with the network diagram overlay options that are available.
Each graph (and its functionality) is described below:
Like the Flow graphs, details of where traffic comes from is indicated and at the top of the graph the
signal states of the relevant (feeding) upstream traffic streams (or links) are shown. Unlike the Flow
graphs, the green times of the source items are NOT shifted in time, since the 'green waves' can be
seen directly.
The vertical axis represents distance back from the stop line. (The stop line is at the bottom of the
graph.) These graphs are essentially a type of time distance diagram, and clearly show green waves
of traffic travelling from the upstreams (at the top of the diagram) to the next downstream traffic
stream (or link) in question (at the bottom of the diagram).
20.4.2.1 Queue Graphs:

The plot of the queue usually takes the form of a forward-skewed triangle (two if there are two
green periods). This is as a result of traffic behaviour on the commencement of green. At the start
of green the vehicles at the front of the queue move off from the stop line. Those at the end remain
stationary until the vehicles in front have moved. The presence of queued traffic is indicated in RED.

The queue graph plots represent only the uniform component of any queue. The MMQ (mean
maximum queue) values shown in the final prediction table of the PRT file includes additional
queueing due to random effects (i.e. cycle to cycle variations) plus oversaturated conditions.
At some junctions, queueing may occur during the green period. This happens when the flow along
the traffic stream (or link) is greater than the saturation flow.
Queueing in the green may also appear on either major or minor shared links. This happens when a
platoon on one shared link joins the back of a discharging queue on the other shared link. The queue
graph for a shared link does not include the queues for the other shared links in the same group, i.e.
for the purposes of the displayed graphs, the main and shared links are, in effect, treated as separate
links, even though they in fact share the same road space.
Two examples of queue graphs shown here – one is from a PDM traffic stream and the other from a
different CTM traffic stream. The differences that can be seen between the two graphs reflect the
different spatial information that the two traffic models naturally contain. The rougher stepped
nature of the CTM graph is determined by the number of cells that the item is made up of – Longer
traffic streams with slower traffic will result in more cells being created.

Page 416
20.4.2.2 Occupancy Graphs:

The plot of occupancy gives an indication of where along the traffic stream (or link) vehicles are
located. The deeper the BLUE colour the higher the density of traffic. Therefore the deep blues
seen in the graph are indicative of high flow, or stationary traffic - The graph does not differentiate
between these. See the “Traffic” graph (or network overlay) for that.
Graphs drawn for items modelled using CTM will naturally look slightly different as CTM naturally
has a better idea of the spatial positioning of traffic but lacks the ability to model dispersion. The
screen shot of a PDM occupancy graph clearly shows how the edges of the blue platoon of traffic
becomes less distinct (fuzzier) as it travels from the upstream signals to the next stop line – This is
due to the dispersion effects that are modelled by PDM.
In the screen shot immediately above, traffic from both green periods reaches the next stop line
such that most of the traffic is undelayed, i.e. it arrives during green.
20.4.2.3 Flows:
The plot of flows shows the relative flows at each point on the link at each point in the cycle. It gives
an indication of where along the traffic stream (or link) vehicles are moving. It is almost an ‘inverse’
of the CTM queue graph. Deeper GREEN colours are indicative of where traffic is flowing freely.
Lighter or the absence of shading shows either an absence of traffic, or, slowed or queued traffic.

You can see in the screen shot that there is an obvious void where the typical saw-tooth shaped
queue will be.
20.4.2.4 Traffic:
This plot is a version of the occupancy graph that is colour coded - It uses multiple colours to
represent stationary (queued) and moving traffic. Red indicates stationary traffic and green
indicates moving traffic. Amber and yellow are used indicate values in between. This graph uses the
same data (corresponds) to the network diagram “Traffic” overlay (in 2D and 3D). It is particularly
useful because it allows you to see both the total volume of traffic and what that traffic is doing.
Traffic graphs can be added to the TRANSYT report using the option Main Menu > Tools > Graphs to
Include in Reports.

Page 418
20.4.3 PDM –PI-Offset Graph

The main purpose of the P.I. graphs is to indicate the likely change in P.I. following a change in the
offset between this controller stream and the upstream controller stream. The optimum offset
value indicated by the graph can be checked via a full TRANSYT run.
The Performance Index (PI) graph plots the P.I. for a traffic stream (or link) against the offset-
difference. The P.I. value, which TRANSYT uses to calculate the network P.I., is shown to the left of
the vertical axis. The graph shows how the P.I. would vary if the offset-difference was altered by an
amount varying between zero and the cycle time.
Since traffic stream (or link) on the edge of the network will have no upstream controllers they cannot
be offset from them. For these items the P.I. remains constant. In all the other cases the P.I. for a
particular item will vary depending on the offset-difference. The lower the P.I. the better the co-
ordination.
Time-distance diagrams provide a mechanism to visually display the state of progression (good or
bad) of traffic from stop line to stop line along a specified path through a network by plotting traffic
flow over time and distance. This can be compared to the on-street situation to ensure that the
model is as accurate a representation of the real-life situation.
The diagram is accessed from Main Menu > Tools.

Figure 20-1 A typical (non-cumulative) time distance diagram
20.5.1 Features of a time distance diagram

Each time distance diagram consists of the diagram itself plus a number of additional items. The
diagram is made up of progression bands, stop lines which the chosen series of links, traffic streams,
or OD paths pass through, and the time and distance axis.
The progression bands are shown in a variety of ways depending on the chosen band type, (See
section 20.5.5)
Stop lines are shown as a thin horizontal bar showing either the actual or effective green time. Up
to two bars are shown at each stop line. The upper one (of a possible two) is always shown and
represents the green times affecting the traffic being shown. The other bar shows the combined
green times of all other traffic stream (or link) that are feeding into the displayed downstream traffic
stream (or link). Unsignalled nodes are displayed with 100% green time. Multiple green periods are
automatically catered for.
The vertical-axis shows the distance away from (downstream of) the stop line of the first traffic
stream (or link) for each subsequent stop line. The distance between the stop lines reflects the true
distance between them. A distance scale and vertical scrollbar allows a limited part of the total
distance to be selected. The vertical-axis is also labelled with the signal node number (in brackets)
associated with each stop line, and the downstream traffic stream (or link), shown between the stop
lines.
The horizontal axis shows by default, one complete cycle. Multiple cycles on this axis may be
selected if needed (see Figure 20-2).

Page 420
Figure 20-2 CTM “Flow Mode” showing three cycles
20.5.2 Using time distance diagrams

After running a file, you can view a time distance diagram (TDD), which is accessible via the TDD
button on the main vertical toolbar.
Time distance diagrams can be displayed by simply selecting an existing TRANSYT path, route or by
making a multiple selection (by holding down the CTRL key) in the network diagram. When making a
multiple selection, the items must be selected in the order that you wish them to be displayed, and
only after the second item downstream of the first is selected will the diagram be displayed. To
select the relevant traffic streams you need to click on any lane of that traffic stream – not the traffic
stream itself. For links, simply select each link.
Upon loading, the TDD displays (by default) the flow from stop line to stop line for the currently
selected Collection (Route), OD Path, or selection of contiguous Traffic Streams/Links. A blank TDD
will result if none of these are selected. Multiple selections (via the network diagram or the Data
Outline) must contain at least two connected items before a TDD will be drawn.
You can display any number of TDDs; each one will update to show data for the current selection
unless you use its padlock (see section 7.11). Each TDD can be stretched to whatever size is
required.
Note that you do not have to 'run' each TDD separately. After running the file once, any valid set of
link-to-link progressions are available to display; simply select click the TDD button on the main
vertical toolbar, and then select the links of interest, via the Data Outline or the network diagram.
You can show several TDDs at once, and each one will update to show data for the current valid
selection, unless you lock it.

20.5.2.1 Changing offsets

A TDD allows you make direct changes to the signal timings, in addition to allowing you to observe
progression of particular traffic flows – dragging the stop line bands left and right changes the offset
for its related traffic node. This allows you to adjust the coordination between nodes in order to
achieve the particular progression you wish for the displayed flows. This feature mirrors that of the
Timings Diagram where you can also change offsets. The TDD is automatically updated when offsets
are changed, irrespective of where in TRANSYT they are changed.
In order to see the effects of offset changes, you will need to switch off “Auto
Distribute” and set the optimisation level to “None” and re-run TRANSYT. If you do not re-run
TRANSYT after changing the offsets, the TRANSYT results (and hence the diagram) will be out-of-
date. Using the TRANSYT auto-run feature in this situation is useful as it will allow the effects to be
seen straight away each time you make a change.
20.5.3 Measure of Effectiveness (MoE)

A simple “Measure of Effectiveness” (MoE) value is calculated and displayed between each stop line
and is also averaged for the selected collection of links and shown below the diagram.
The MoE gives a rough indication of how well signals are co-ordinated by calculating what
proportion of the flow lines or the number of green-wave time steps that arrive on green. A value of
100% indicates very good coordination and a value of 0% very poor. N.B. Dispersion is not taken
account of. The Mean Modulus of Error (MME) calculated by the CFP Graphs, although not directly
related, will affect the likelihood of obtaining a good MoE value. For example, a low MME (such as
for a near uniform cyclic flow profile) will reduce the likelihood of obtaining a good MoE value, while
high MME values, which indicate a highly platooned profile, are likely to provide better
opportunities to obtain good coordination.
20.5.4 Showing Dispersion

The effect of dispersion along many links is an important factor when considering progression. Each
set of signals produces a block of traffic that travels from one stop line to the next junction. This
‘green wave’ of traffic has a front and a back which is determined by the effective green time, the
cruise speed along the link and the level of dispersion.
The TDD’s Show Dispersion option provides both the actual front of the green wave from stop line to
stop line and also an approximation of the back of the green wave. Therefore this feature is
particularly useful as it ensures that the full extend/breadth of the green wave is shown on the
diagram. As a result, any adjustments to, say, offsets, to improve coordination of a particular route,
can be made with good knowledge of when the majority of the traffic will be arriving at the
downstream signals. N.B. the dispersion shown is always for normal traffic.

Page 422
Figure 20-3 Time Distance Diagram showing dispersion
20.5.5 Progression band types

A TDD can show progression in five different plot modes (see figures) as follows:
Non-cumulative: Shows progression bands with a width stretching across each

of the effective green periods for the first link only (see Figure 20-1). The
progression band is drawn across all selected links AND is shown as being
unaffected by them. The dispersion option is available.
Non-cumulative reset: Separate progression bands for each stop line are shown,
i.e. the progression band is ‘reset’ after each stop line. The dispersion option is
available.
Cumulative progression: Same as “Non-cumulative”, except that the

progression band width is shown as being affected by the effective green times
of subsequent downstream green times.
Flow Mode: Shows flow rates (in green and grey) along the selected item at all
times of the cycle, and additionally shows queues in red. GREEN indicates the
presence of high flow rates.
The flows make use of the same information used to display animations in the
network diagram.
For PDM items, platoon dispersion can also be clearly seen.
This mode, in some ways, gives the most ‘traditional’ looking time distance
diagram and is probably the most useful.
Cell Flow (tolerance): A variation of “Flow Mode” - A flow threshold can be set
to hide any flow rates below the chosen threshold.

Figure 20-4 “Non-cumulative reset”
Figure 20-5 “Cumulative Progression”

Page 424
Figure 20-6 PDM “Flow Mode”
Figure 20-7 CTM “Flow Mode”
20.5.6 Other features

A time distance diagram has a number of other features as follows:
 The time-axis can be rotated in order to align different TDDs or graphs to the same time at
the origin (such as the network’s arbitrary zero) to allow them to be more easily compared
 The diagram reflects the timings associated with the currently selected Analysis Set and
Time Segment. In addition to the standard locking mechanism, the diagram can be locked to
the current time segment
 Since traffic on a particular traffic stream can be made up of more than one traffic type
(normal, bus, tram) the “Traffic Mode” option can be set to display only the flows associated
with any of the traffic types.
 Signal states can either show actual or effective greens; change your preference via the
Graphs button menu or via the user Preferences screen. A TDD can be copied to the
clipboard (via right-clicking)
 The diagram can be copied to the clipboard as a bitmap (via right-clicking)
 Because Collections, by definition and multi-link selection via the network diagram, do not
necessarily consist of contiguous links, progression of TRANSYT routes is limited to those
links that are linked to the first selected link in the chain
 The “Flow Threshold” value sets the tolerance for the mode “Flow Mode (Tolerance)”. Only
cells with flows greater than or equal to this threshold are drawn. Compare Figure 20-7
with Figure 20-8.

 The whole diagram can be rotated in order to match the orientation you may be most
comfortable or familiar with. Use the Orientation dropdown to choose between “Normal
(interactive)” and one of the rotations. Please note that some features of the diagram are
inactive when rotated.
Figure 20-8 The effect of a 200 PCU/hr Flow Threshold

Page 426

Generating Reports Page 427
After running the traffic model, you can choose to generate a report that summarises all input data
and results. The report is in the form of a HTML file (saved to disk) which you can optionally convert
to a Word document or a PDF file. (You can also generate reports before running the model, in
which case the report will contain current input data, but also out-of-date or zeroed results.)
Click this button to configure a report.
Click this button on the main toolbar to generate a report.
The contents of TRANSYT reports are configurable. The Report configurator allows you to decide
exactly what you want or don’t want in your report. Each ‘section’ of a report can be switched off or
on using the tree-like structure within the report configuration, and each sub-section, data table,
diagram or graph within each of these sections can also be selected on an individual basis, giving you
full control of the contents.

Page 428
Select what you want by ticking or un-ticking the various items in the list. To open up a section to
see its contents click on the ‘+’ symbols. Tick a section heading to either select or deselect
everything within it. Once you’ve happy with your selections, press the Generate Report button to
close the Configurator and to generate a report. The report will appear in the Report Viewer from
where the Report Configurator is also available (section 0).
Generated reports are useful as final reports summarising a TRANSYT file and are also a convenient
way to quickly view all data in a tabular format.
To quickly see the performance of network, show the Report Configurator then turn off all options
other than Output > Final Prediction Table option. See chapter 21 for a detailed description of each
of the individual results.
Turn on Signals and Output to include a set of tables that covers all output values in the file.
There are also some report options affecting the behaviour, contents and appearance of reports
which are set via the user Preferences screen (section 7.18)
The order of network items in the report uses the sorting and grouping selected via the
Options>Sorting section of the Data Outline and therefore you control the ordering as an option
associated with the data file, NOT as a user preference.
Under the “Signals” section an option to “Group by Controller Stream” is available. When selected,
separate signal data tables for each individual controller stream will be created. Turn off this option
to have just one table per topic for all controllers.
When all the rows of a particular table contain the same data, the table will automatically shrink it
down to just one row of data, and the data is marked as applying to “All” network items, as shown
below.
Some report content will not appear if it is unselected in the “Data > Model and Results”
options (Outline: Options > Model and Results”), or if the file is in Basic Mode.
If a company-wide definition of reports (including Data Grids) is needed TRANSYT can be set to point
to a centralised configuration file instead of the local one via the user Preferences screen
(File>Preferences), using the Import Settings From External File option.

21.1.1 Loading and Saving Configurations

The Report Configurator allows multiple “configurations” of selected and unselected sections of
reports to be saved for future use. Select the “Manage Configurations” tab in order to add, save
changes to, rename or delete your configurations.
The “Load configuration…” button, which is available whenever either the “Sections” or “Options”
tab is selected, offers a convenient shortcut to load existing configurations.
Configurations are stored as part of your installation of TRANSYT, rather than in each file. However,
the particular selections that you make in a file will still stay with the file so that anyone else
opening the same file will see the same selections. The recipient of that file can then choose to save
the particular selection in it, as one of their own “configurations”.
The default configuration (“Default” prefixed to the configuration name) is used when running a
report for a new file. This is the only time the default configuration is used.
Select a configuration using the saved configuration list in order to either save it, rename it, set it as
the default (for new files) or to overwrite it with the current settings. Note that selecting from this
list does not affect the current settings. The current settings are changed only when a new
configuration is loaded.

Page 430
21.1.2 Report Options

There are various options affecting the contents and appearance of reports, available via the
“Options” tab.
21.1.2.1 Use high quality images

When selected, diagrams such as the network diagram and stage and sequence diagrams are shown
as high quality vector images. These types of images also give high quality hard copies. If you have
trouble with a third-party application recognising these vector images, you should switch this option
off so that standard bitmaps are used instead.
21.1.2.2 Highlight Result Fields

By default, TRANSYT will use a pale-green background colour for any results in the report. This
option can be switched off.
21.1.2.3 Show Time Segments and Show summary time Segments

When Show Time Segments is selected, results are shown for all time segments. Some tables are
split into sections with a header that indicates the time segment shown. The remaining tables,
relevant to time segments, are extended to show values for all time segments, and have an extra
first column indicating each of the time periods (see screen shots below).
When Show summary time Segments is selected, results are shown for the special summary time
segment.
Neither of these options has any effect if only one time segment exists, and when neither of the
time segment options is selected, none of the time segment related tables are shown.
When examining the summary results, use the glossary to confirm how they are
calculated, e.g. a sum, an average, a weighted average.

Time segment results shown in separate sections:
Time segment results shown within the one extended table:

Page 432
21.1.2.4 Show all analysis sets

When selected, the report will include the contents of all analysis sets that have been marked for
inclusion in the report.
21.1.3 Using custom grid layouts in reports

If you use the Data Grid screen (chapter 10) to store customised grid layouts, then you can mark
each layout for inclusion in reports. To do this, you need to use the Data Grid menu item “Custom
Grids Manager” to set the “UseInReport” flag. For convenience, a short-cut to this is provided from
the Report Configurator. You must also turn on the Custom Grids option in the Report Viewer
screen (and then refresh the report if needed).
Each generated report is an HTML document, whose filename is based on the filename of the
current data file. Reports are saved in the location specified on the user Preferences Screen (section
7.18). This can either be set to always be the same location as the data input file, or alternatively
can be set to a fixed location, such as “My Reports” for example. If this location cannot be accessed,
such as when the data file is located on a drive without write permissions, the Windows temporary
folder will be used instead.
If the report includes diagrams, they are saved as separate .gif, .jpg or .emf files in the same location
as the HTML file, and their names will be based on the HTML filename. If moving/saving/e-mailing
the report file, please be aware that you will need to include these files as well as the HTML file
itself.
Additionally, the Report Viewer contains options for converting the file to a Word or PDF document,
in which all diagrams will be embedded and the file can easily be saved, emailed, etc. The
generated PDF files are fully paginated. Some tables cannot be accommodated if your Print
orientation is set to “Portrait” – If any of your tables are cropped on the right-hand side then please
use File > Print Setup… to set your orientation to “Landscape” and then re-convert your report to
PDF.
If you intend to save reports as PDF files, then the HTML files are effectively only
temporary files and we recommend using the user Preferences Screen to set the Report Folder to a
temporary folder such as c:\temp folder.

As soon as a report is generated, it is shown in the Report Viewer. Reports are HTML documents,
and TRANSYT reports can be viewed in other HTML viewers, including Microsoft Internet Explorer,
and can be e-mailed to colleagues. The contents of reports, or subsections of, can also be copied
and pasted into any word processor or spreadsheet.
Use the orange contents at the top of the report to quickly jump to sections of the report.
In TRANSYT, only one report can be viewed at a time. You can however use any web browser to
view any number of reports, whilst using TRANSYT, refreshing them as necessary.
Irrespective of where the report is saved, the filenames of the report documents are always based
on the filename of the input data file. The filename of the HTML document shown in the Report
Viewer is always shown at the top of the screen. If you intend to use PDF reports as final versions,
then you can generally ignore the location of the HTML report and treat it as a temporary file
produced by TRANSYT.
If the data file has not yet been saved and therefore does not have a filename, the name “Untitled”
will be used, and the report will be saved to the Windows temporary folder, overwriting any existing
untitled report.

Page 434
21.3.1 Refreshing the Report

Whenever you change data in the TRANSYT file, or select a different current analysis or select a
different demand set, a red message will appear in the top left-hard corner of the report (see
below). As the wording implies, this indicates that the report is out-of-date, i.e. it does not reflect
the contents of the current TRANSYT file.
Click ‘Refresh’ on the viewer toolbar. This

does NOT re-run TRANSYT for you.
Pressing the Refresh button does two things - it allows the report to reflect the current state of the
TRANSYT data AND allows the report to take account of any changes to the Report Options (see
section 21.1.2).
The Refresh button does NOT re-run TRANSYT for you. Therefore, if the TRANSYT data
has changed and TRANSYT has not been re-run, the results in the file will be out-of-
date. These same out-of-date results will be reflected in the report, even after a
refresh of the report. To ensure that the report shows up-to-date results you need to
re-run TRANSYT before pressing the Refresh button.
In order to ensure you don’t forget, a yellow warning message is printed at the top of
the report if the report is refreshed and the results in the data file are still out-of-
date.
21.3.2 Report Viewer Tools

Use the Copy, Print and Print Preview buttons on the main TRANSYT toolbar.
Use the Copy button to copy any selected to the clipboard, from where you can paste it into a word
processor or spreadsheet. To copy the entire report, firstly select everything by pressing CTRL+A (or
use the right-click menu). Pasting the entire report may be quite slow if the report is large,
depending on the application you are pasting it into, and the formatting may not exactly match the
original formatting.

To print the report, use the Print Preview and Print buttons on the main TRANSYT toolbar. No
pagination is applied when using this method of printing, so if pagination is important to you, we
recommend one of the following:
 Pasting the report into a word processor and formatting from there
 Using the report viewer’s convert option “convert to Word document”) and format as
necessary
 Using the report viewer convert option “Save as PDF document” to save a PDF version of the
report. Converting to a PDF offers the best way to obtain good pagination within the report.
The Report Viewer’s Tools drop-down menu will show a menu containing a few utility functions:
Open this report’s containing folder: opens the Windows folder where the report is saved.
Open this report in your default web browser: launches your default web browser and loads the
report. You can then close the Report Viewer and continue working in TRANSYT, switching to the
last run report in your default web browser as necessary.
Keep Inside Application Window: turn this OFF to have the Report Viewer ‘disconnect’ from the
main TRANSYT application window, so that you can position it freely, e.g. on a second desktop
monitor. Double-clicking the header will toggle this mode off and on.
An extra application of the Report Viewer is to compare different files. This can be used to compare
existing files, variations on temporary files within TRANSYT, or to compare different
Analysis/Demand Sets. It can also be used to find out what is different between two files that give
different results for an unknown reason.
In all cases, the files need to be loaded into TRANSYT or otherwise created (e.g. via the File>Copy
Into New File option).
File comparison is set up from outside the Report Viewer, via the Tools>Compare Files or Data Sets
option. This will show the screen below, which lists in the File dropdown each file currently loaded
in Junctions 9 (i.e. the files as shown in the blue file bar at the bottom of the screen). It is
recommended that you save any new files with a meaningful name, otherwise they will all appear as
‘[New File]’, although this is OK for quick comparison runs.
For each file that you want to compare, choose it from the File menu and click the Add button.
Optionally you can choose a colour for each file (by double clicking in the Colour column) to be used
when differences are found.

Page 436
We recommend you run all the analysis sets first, before carrying out any comparisons
to ensure the results are up to date - The main menu “Eval Run” dropdown “Evaluation Run for all
data sets” is the easiest way to run all the analysis sets in one go.
If the Only show differences option is turned on, values are only printed when they differ between
the files, and blanks shown otherwise. If this option is turned off, then all values for the master file
(the file that is currently active in TRANSYT) are always printed, and values for the other files printed
where they differ. This means that even where alternative network layouts differ from each other,
limited comparisons (common items only) can still be made between them. (The master file is also
used during the comparison, as the file that is assumed to have the correct number of arms etc.)
Press OK to generate the comparison report, which will appear in the Report Viewer and from there
can be refreshed as usual and saved as a PDF and so on.
The top of the report shows the ‘master’ file and the comparison file(s) in their relevant colours:
The report is then printed as usual, using options as set in the Report configurator.
The examples below show an extract from a comparison result with Only show differences turned
off. All numbers for the master file (red) are printed, and, when the comparison file(s) contain
differences, the values from the other file(s) are shown in their appropriate colour. This example
clearly shows that the difference in the OD flow data for has led to differences in the results on all
traffic streams. (Assuming that the Run files option was used.)

With Only show differences turned on, the same report extract appears as below. This time, the
rows and columns that are the same are not printed at all. This makes it much easier to skim down
the report and immediately pick out the differences. Many sections will not be printed at all,
although the headers and table titles are often printed regardless.

Page 438
If you try to compare files that have different numbers of arms, or do not match up at all, then you
will either receive an error or else the report will appear but show question marks where an item in
the master file, does not exist in the comparison file(s).
21.4.1 Comparing Analysis and Demand Sets (within one file)

To compare different Analysis or Demand Sets within a file, use the Analysis Set and Demand Set
dropdowns in the comparison tool and click the Add button. Once you have added one set to the
list of items to be compared, an Add all link will appear which can be used if you want to compare
ALL sets.
In the example below, all four Demand Sets within the file have been added to the list of items to
compare.
After clicking OK, the report lists at the top the Demand Sets and their colours.
The example report extract below shows that all four Demand Sets have different O-D data (as
expected).

As you would expect this leads to differences in all results.
Comparing Analysis Set and Demand Sets in this file is useful if you need to confirm whether two or
more sets are the same as each other.
Although the comparison system allows you to add any combination of

files, analysis sets and demand sets to the comparison list, we recommend that you only compare
sensible items. For example, you can add a combination to the list that includes inconsistent
combinations of sets, such as a particular analysis set combined with a demand set that is not
referenced (used) by that analysis set. This will invariably lead to confusing comparison results.
21.4.2 Comparing Analysis and Demand Sets between files

You can also use it to compare sets within different files, assuming that the files are broadly similar
(i.e. contain the same arms etc.). For example if you had two files – one containing the analysis sets
(am and pm) for a baseline case and another containing the same two time periods for a
development case, you can compare specific analysis set and demand set combinations from each
file.

Page 440

TRANSYT Outputs Page 441
This chapter provides a description of the TRANSYT table-based output and a description of the main
output values provided within the core TRANSYT results. Many of the items (particularly the input
data items) are self-explanatory and described elsewhere, so these items are not mentioned in any
detail here.
A set of traffic model predictions are provided for the optimised or provided (evaluation) signal
timings. The results are split into the following sections (depending upon the report options
chosen):
Banner:
Describes what version of TRANSYT produced the results. This is always shown in the report. Also
includes the filename used; location of file; date and time the report was generated.
» Contents:
A hierarchical set of links to each section of the report
“Summary” section:
This section includes the file description data; model and result options; units used, and the selected
sorting options. See later for what additional information is provided for each “analysis set”.
“Network Diagram” section:

Main Diagram: A network diagram image of the complete network.
Custom views: Any saved “views” of the network that have been selected to
appear in the report (see the network diagram’s “Manage Views” screen).
For each Analysis Set:
“Summary” section:
This section lists data errors, data warnings and data Information statements. A “Run
Summary” (similar to the on-screen Summary Results) is also part of this section. The
Analysis and Demand Sets specified within the file are also listed in this section.
----------------------------------------------------------------------------------------------------

Page 442
“Input” section:
This is a collection of sub-sections which includes all of the input data, except for signal data:
Network Options: A collection of tables detailing the input data items common
to the complete network, such as network cycle time. Includes a variety of other
data items, including details of what optimisation options have been used.
Traffic Nodes: Details node input data (N.B. does not include signal timings.)
Fuel Consumption: Details all fuel consumption data, e.g. WebTag data used and
assumed vehicle class proportions for the network
Individual Basic Data: Details of arm data, traffic stream and link data such as
lengths, saturation flows, type (signalled / give-way / etc.) and RR67 lane data.
This section includes most of the Pedestrian crossing data, but excluding
modelling and flow data.
Individual Modelling Data: Details of traffic model used, weightings, max queue
storage value and advanced modelling data. This section includes Pedestrian
crossing modelling data.
Individual Flow Data: Details of total flows and flows per traffic type
(Normal/Bus/Tram) each traffic stream and link.
Individual Source Data: Details of sources (feeding traffic streams and links) for
each traffic stream and link. Includes cruise speeds, and turning radii
Individual Give-way Data: Details of conflicting traffic streams (or links) and
percentages of what is opposed and what is opposing. Includes the intermediate
calculated value of “slope” coefficient.
Quick Flares: Details of any quick flares within the file, e.g. saturation flow of
flare and usable length of it.
Priority Objects: Details of the data for each roundabout, T-junction or crossroad
object, including ARCADY and PICADY geometry data.
Local Matrices: A list of any Flow OD matrices. Includes Locations, Paths, Path
Flows for normal traffic, buses, trams and pedestrians.
Wide Area matrices: A list of any assignment (wide area) OD matrices. Includes
Locations, Paths and Path Flows. Because assignment path flows are not stored
within the data file, these will appear blank in the tables unless you re-assign the
flows to the network prior to running the report.
----------------------------------------------------------------------------------------------------

“Signals” section:
This is a collection of tables under the sub-headings Input, Output and Diagrams. These sets
of tables include all of the signal timings data AND signal timing results:
Sub-heading Group by controller stream determines if all the data for a specific controller is
kept together (this will generate more tables, but smaller ones) or if the data is grouped by
topic into bigger tables that present data for all controllers.
Sub-heading Input includes the following items: Controller Stream Data; Phase Data; Library
Stage Data; Stage Sequences Data; Intergreen Matrix; Banned Stage changes.
Sub-heading Output includes the following items: Resultant Interstage Matrix; Resultant
Clearance Times; Resultant Stages; Resultant (Phase) Green Period; Traffic Stream Green
Periods / Link Green Periods; Resultant Offsets and Resultant Penalties.
The start/end times and duration of each green period are the actual green times:
to obtain effective green times, add the global displacements specified in Main
(common) Data and any local “relative” displacements.
When requesting the “Resultant Offsets” table, any user-defined “relative

offsets” (see Controller Stream Data) will appear in the report. This allows the
offset between one controller and any other controller to be reported. A piggy-
backing system can therefore be set up where each controller reports the offset
relative to the previous one, along a corridor of controller streams. Both
positive and negative offsets are reported.
Sub-heading Diagrams includes Phase Timings Diagrams and Stage Sequence Diagrams
----------------------------------------------------------------------------------------------------

Page 444
“TRANSYT 12 Tables” section:

This is a collection of tables resembling the well-known traditional results tables provide by
earlier versions of TRANSYT:
N.B. for this section to appear in the report when selected, the Model and Results
option “Display TRANSYT 12 style timings” must also be TRUE.
This group of tables includes details of Resultant Stages, Resultant Phase Green
Periods, TRANSYT 12 style Stage Timings, Traffic Stream (and link) green times
----------------------------------------------------------------------------------------------------
“Output” section:
This is a collection of sub-sections which includes all of the TRANSYT output data: It includes
sets of results equivalent to the result sections of the Data Outline.
Sub-heading Show pedestrian crossing results includes the output results for each
pedestrian crossing, presented together, along with a summary of all the pedestrian
crossings.
The following individual output items are presented in this section: Individual Result
Summary; Individual Flows and Signals; Individual Stops and Delay; Individual Queues and
Blocking; Individual Journey Times; Individual Flare;
Network Tables (equivalents of the individual tables listed above) are also provided: The
results are for all items within the network combined (i.e. all traffic streams or all pedestrian
crossings).
The following additional outputs are provided:
Point to Point Journey Times: A point-to-point journey time tables for each user-
defined OD Matrix. Tip: For OD location-to-location values, these are the most
accurate journey time results available.
Final Prediction Table: This is not just one table but is a set of summary tables – one
for traffic streams, links, and pedestrian crossings. They include results for every
individual traffic stream, link and pedestrian crossing. Additionally, there is a table
showing network totals and another table for collections. An example of a traffic
stream table is shown below:

Collections: When selected, a full list of the available collections is

reported. A set of results for each collection marked for inclusion
(i.e. individual and/or aggregated results) will as be included. Each
set of results is calculated for each individual collection you have
defined. Results for any Collections are also presented within the
data Outline, in a similar way to how they are presented for other
individual network items and for the complete network.
Graphs: Collection of user-specified “Cyclic Flow Profile (CFP)” graphs and “Traffic
(Spatial)” graphs. The graphs are defined from Main Menu > Tools > Graphs to include
in reports… As many graphs as you like can be added. Each graph is set to be either a
CFP or Traffic graph, and each one references a comma-separated list of traffic streams
or links that you wish to plot. Each plot can be in either a one or two column format -
Single column graphs are bigger.
----------------------------------------------------------------------------------------------------

Page 446
“Custom Grids” section: This is a collection of user-defined tables which have been
created using a Data Grid, and then selected by you to appear in the report. You can double-
click on this item to gain access to which custom grids should appear in the report.
This section provides a description of the main output results provided by TRANSYT relating to each
individual traffic stream and link. Pedestrian crossing outputs are also indicated where applicable.
The results describe here are those from the “Output” part of the report, which are also accessible
from the “Results” sections of the Data Outline. Some of the items are also part of the summary
“Final Prediction Table” output.
The descriptions here refer to values calculated when there is only one time segment.
See elsewhere for details of how varying flow conditions affect the results presented. For multiple
time segment cases it is generally the case that the most appropriate combination of the individual
values per time segment, highest values of all time-segments, and average values of all time segment
are shown.
To assist with interpretation of the “Final Prediction Table” results, the report includes a key which
explains what each special symbol or abbreviation means, some of which are mentioned in the
following text.
22.2.1 Results: Vehicle and Pedestrian Summaries

This is a list of the key output results that appear in either the Vehicle Summary or the Pedestrian
Summary.
Please note that these results are also repeated under their own sub-sections, namely:
 Flows and Signals results – See 22.2.2

 Stops and Delays results – See 22.2.3
 Queue and Blocking results – See 22.2.4
 Advanced results – See 22.2.7
In pedestrian crossing only tables some items will be labelled as “Ped/hr” in the
appropriate places). Where tables display a mix of pedestrian and vehicular traffic data “PCU/hour”
should be interpreted as “PED/hour” where needed (as the pedestrian PCU Factor is permanently set
to 1).
Data/Results shown in units of “PCU” or “PCU/hour” can optionally be displayed in “Veh” or

“Veh/hour” respectively, by selecting them in the “Units” section of the data outline.

Degree of saturation (per cent)
Practical Reserve Capacity (per cent) – Vehicular links and traffic streams only
Calculated Flow Entering (link or traffic stream) (PCU/hour)
Calculated Saturation flow (PCU/hour (of green)).
Actual Green Time (seconds per cycle)
Mean delay per Veh (seconds)
Mean maximum queue (PCU)
Utilised storage (%) This value gives a useful estimate of how much of a traffic stream or link is filled
with traffic based on when the back of the queue is at its longest. This helps to identify where
blocking problems might occur. Values close to or over 100% are likely to block the upstream junction.
Flow during Gap Accepting (PCU/hr) – Pedestrian crossings only streams only
Weighted Cost of delay (£/hour)
Weighted Cost of stops (£ per hour) – Vehicular links and traffic streams only
Performance Index (£/hour)
This is the sum of the delay and stop costs for the traffic stream (or link) plus any of the following
penalties:
 Excess queue penalty (see Maximum Queue Length and Penalty - 28.6.1).
 Excess degree of saturation penalty (section 28.7)
 Low degree of saturation penalty
 Pedestrian gap-accepting penalty (see section 28.8)
The delay and stop components are also weighted by any link/ traffic stream-specific delay or stop
weights (as in Link Data, Traffic Stream Data or Give Way Data) before summing.
If you wish to include the costs given by the P.I. in any form of cost-benefit analysis, it is advisable
they you use the un-weighted P.I. instead, to ensure that the various weighting factors on delays,
stops and queues do not result in an unrealistic estimate of community costs.
22.2.2 Results: Flows and Signals

Traffic stream number, Arm number and Link number

Page 448
In the “Final Prediction Table” traffic streams carrying buses are indicated by ‘B’, tram links by ‘T’ and
imported pedestrian links by ‘P’. Traffic streams carrying normal traffic are indicated with a ‘N’, but
only if it also carries one or more other traffic types. Similarly, the link column is used to indicate
which traffic types use each link.
Major Link
Links having shared stop lines (see Shared Stop lines description) are identified by a reference to the
major link in this column. The major links are identified by their own bracketed link number in this
column.
Calculated Flow Entering (link, traffic stream or pedestrian crossing) (PCU/hour)
This is the flow counted on the link or traffic stream entry, i.e. the sum of the IN flow profile elements.
For links, usually this equals the value specified in the Links Data Screen (Outline: Links>Link n>Link
Flows>Total flow) for the link since the inflows are automatically adjusted for compatibility after data
input, to give the specified total. For traffic streams, usually this is simply the derived total flow based
on summation of the flows on all the paths passing through the traffic stream. However, in the event
that this specified flow causes a traffic stream (or link) to be oversaturated, either with the initial
signal settings or at any part of the hill-climb process, downstream traffic streams (or links) will have
reduced inflows. In such cases where the flow into a traffic stream (or link) is smaller than the original
value by more than 10 PCU/hour, the inflow value is marked with a ‘<’ symbol in the Final Prediction
Table. An oversaturated traffic stream (or link) itself will usually have the specified inflow and will not
then be so marked; its outflow will, however, be less than expected and this will be apparent when it
is noted that the ‘degree of saturation’ (see later) is greater than 100 per cent.
The CTM restricts traffic entering a traffic stream (or link) at its upstream end if the first
CTM cell is occupied. Therefore, even for entry traffic streams Calculated Flow Entering values can
be reduced or even zero. Zero values of Calculated Flow Entering may indicate that the traffic on
that part of the network has locked up.
Calculated flow out (link, traffic stream or pedestrian crossing) (PCU/hour)
This is the flow counted crossing the stop line, i.e. the sum of the OUT flow profile elements. If the
traffic stream (or link) is under-saturated this will be the same as the Calculated Flow Entering the
traffic stream (or link). However, when the traffic stream (or link) is over-saturated, it results in less
traffic leaving than arriving, as TRANSYT will not allow more traffic to leave than it is physically
possible to do so. Calculated flow is also sometimes referred to as “Achieved flow”.
Flow Discrepancy (PCU)
If TRANSYT encounters an oversaturated node, the flow going into the traffic streams (or links)
immediately downstream of that node reduces by a corresponding amount. This output value
indicates the value of that reduction, i.e. the difference between the specified total traffic streams

flow and the TRANSYT calculated total flow. Values over 10 PCUs are additionally indicated in the
output as having an “Adjusted Flow Warning”.
Calculated Saturation flow (PCU/hour (of green))
This value is the saturation flow associated with either a signalled traffic stream (or link) or the
average maximum possible flow at give-ways or give-way bottlenecks, e.g. if using a link structure it is
specified in the Links Data Flows Screen (Outline: links>Link n>Saturation flow)
However, at give-ways it is not simply the specified maximum flow, but is the maximum flow possible
at any particular time averaged over the cycle. If a give-way also has a separate restricted flow value
specified (i.e. a give-way bottleneck), this can result in a value higher than the give-way maximum
flow, as when the opposing traffic stream signal is at red the give-way flow rate increases to the
specified saturation flow instead of the maximum flow.
‘Quick’ flares also affect this value – The calculated saturation flow of a traffic stream or a
link with a ‘quick’ flare is an average value that depends on the green time as well as saturation values
used by the flare.
For ‘link shares’ data and results relating to the shared stop line are shown with the major link
referenced in a separate column, and duplicated values shown as bracketed values. E.g. queue
lengths that apply to the complete shared stop line and NOT to individual links shows the value
repeated for each link of the shared stop line. Such values should, obviously NOT be summed to
give a total – it is ALREADY a total, which is simply shown more than once.
For each side of a pedestrian crossing a saturation flow is calculated. This is fully explained in section
15.6.
Calculated Capacity (PCU/hour)
The average rate at which traffic can exit the traffic stream (or link) when all effects are taken account
of, such as blocking, reduced flows, etc. This value can be used to easily calculate the Degree of
Saturation. It is equivalent to the average ‘GO’ flow when including blocking effects.
Degree of saturation (per cent)
The degree of saturation (DoS) is an important measure of the spare green time available and
indicates how near the links (and hence the nodes and network) are to the maximum capacity
available.
In its simplest form, i.e. where no oversaturation or blocking effects are taking place, this is the
ratio:
Total flow into link x cycle time x 100 (per cent)

Page 450
Saturation flow x effective green time
However, it is easier to consider the DoS as:
Total flow into link x 100 (per cent)
Calculated capacity
The reason for the second equation, which simply references the calculated capacity of a link, is that
not all of the effective green can be used – e.g. due to blocking effects and furthermore the full
saturation flow is not always possible despite traffic being presented with effective green.
The calculated capacity takes account of all downstream effects, such as blocking that influences the
ability of the traffic stream (or link) to let traffic out of the traffic stream.
A DoS value of over 100 corresponds to oversaturation and a queue will grow for as long as the
specified flow conditions exist.
The Total Flow into the traffic stream (or link) is the entry flow as it takes account of oversaturation
of the upstream sources feeding that item, i.e. as the upstreams become more oversaturated the
DoS on the downstream can be seen to go down. These reductions in flow due to oversaturation
also apply across local OD matrix boundaries and across different cycle time ‘zones’.
Demand flow corresponds to the total demand independent of when the flow arrives or whether
the flow can actually arrive onto the traffic stream (or link). The entry flow corresponds to the flow
that can actually arrive onto the link within the time period simulated; For CTM links and CTM traffic
streams, it is constrained by the downstream link traffic. The demand flow and entry flow are
normally approximately equal unless the traffic stream (or link) is over-saturated, in which case, the
demand flow is greater than the actual flow. TRANSYT reports entry flow based degree of saturation
for non-entry links, and demand flow based degree of saturation for entry links.
Practical Reserve Capacity (per cent)
This gives the percentage by which the arrival rate on a stream could increase before the stream
would be at practical capacity. It is given by 100(p-x)/x where x is the degree of saturation and p is
the maximum acceptable degree of saturation. (NB the calculation is different for opposed
streams). The Junction PRC is the lowest stream PRC. A junction that has a PRC of 100% can cope
with double the amount of traffic, and a junction with a PRC of 0% is handling the maximum
acceptable amount of traffic. Reserve capacity can exceed 100%.
Flow during Green (Peds/hr); Flow during After Green (Peds/hr); Flow during Gap Accepting
(Peds/hr); Flow during Before Green (Peds/hr)
The above four flow rates are shown only for pedestrian crossings using the walk-on-red pedestrian
model. The cycle is split up into four different time periods each representing a significantly
different scenario for pedestrians wishing to cross. The flows indicate the volume of pedestrians

crossing during each of these periods. The time periods are calculated internally within TRANSYT.
N.B. “Green” is a reference to the green man period.
Flow On Red (PCU (or Veh) per cycle)
This is the resultant flow over the stop line during red per cycle when nearside turning of traffic on
red is permitted.
Actual Green Time (seconds per cycle)
This is the time for which the signal head for traffic on a traffic stream (or link) actually shows green.
Effective Green Time (seconds per cycle)
This is the time for which traffic behaves as if the signals were green.
22.2.3 Results: Stops and Delays”

All results are relevant to all traffic streams and links. Results shown for pedestrian crossings are
indicated.
Mean cruise time per PCU (or Veh) (seconds) – including pedestrian crossings
This is the mean un-delayed travel time along a traffic stream (or link) obtained from up to six possible
inflow cruise times specified in the Link Flow Data or Traffic Stream Flow Data these cruise times being
weighted in proportion to their inflow. If, optionally, speeds are specified, cruise times are first
calculated from the speeds and the link length.
Mean delay per Veh/Ped (seconds) – including pedestrian crossings
This is the average value of delay experienced by a PCU on the traffic stream (or link). It is obtained by
dividing the total delay rate (uniform and random + oversaturation) by the ‘flow into link’. The delay
is similarly calculated for Traffic Streams, but the mean delay value is a weighted average of the delays
of the traffic on all paths passing through the traffic stream. ...........For traffic streams, please note
that the delays experienced by PCUs using a particular TRANSYT path through the network will
experience their own delays specific to that path. This ability of TRANSYT to take account of different
path delays allows it to provide more accurate travel time results.
Signalled LoS
This is the US Highway Capacity Manual (2000) signalled junction “Level of Service” (LoS) for a
signalled traffic stream (or link). This result is only available if the LoS option is set via Main Menu >
Data > Model and Results options.
Mean delay per Veh/Ped (seconds) – including pedestrian crossings

Page 452
This is an average value of delay obtained by dividing the total delay rate (uniform and random +
oversaturation) by the ‘flow into link’ or ‘flow into traffic stream’.
Uniform delay (PCU-hours/hour, or Veh-hours/hour) – including pedestrian crossings
This is the uniform component of the total rate at which delay is incurred on the traffic stream (or
link). The uniform component is equivalent to the average number of PCUs queueing on the traffic
stream (or link) during the ‘typical cycle’.
Random + oversaturation delay (PCU-hours/hour, or Veh-hours/hour) – including pedestrian

crossings
The random delay rate is the component of the total delay rate which is caused by random
fluctuations in traffic arrivals on the traffic stream (or link). If the degree of saturation on the link
exceeds 100 per cent, the total delay rate includes a further ‘oversaturation’ component which
accounts for the steady increase in the queue during the period, due to arrivals exceeding departures.
The total delay rate on a traffic stream (or link) equals the sum of the values given in the ‘uniform’
column and the ‘random + oversaturation’ column. This total delay rate is equivalent to the average
number of PCUs queueing on the traffic stream (or link) during the period specified in the General
Data, Simulated time (mins) (Main/Common Data).
Total delay (PCU-hours/hour, or Veh-hours/hour) – including pedestrian crossings
This is the total rate at which delay is incurred on the traffic stream (or link). This is only shown if the
option to Display separate uniform and random results is switched off (see Main Menu > Data >
Model and Results options).
Unweighted Cost of delay (£/hour) – including pedestrian crossings
This is the cost of delay, but with all weightings removed from the calculations, allowing the ‘true’ cost
to be quickly ascertained. This avoids the need to remove weightings and run an un-optimised run of
TRANSYT to obtain them.
Weighted Cost of delay (£/hour) – including pedestrian crossings
The total delay rate for the traffic stream (or link) is multiplied by the value specified in the Main
(Common) Data, Value of Delay and divided by 100 to give cost per hour in pounds. An asterisk after
the delay cost indicates a delay weight other than unity has been specified in the Link data or Give
Way Data for this traffic stream (or link) data equivalents).

Mean stops/Veh (per cent)
This is the average percentage of stops per vehicle entering the traffic stream (or link), i.e. 100 means
that, on average, each Vehicle stops fully once. The estimate takes account of both uniform and
random stops and allows for fractional (partial) stops as described in section 27.3. Stops/PCU will
often exceed 100 per cent where link inflows are near to capacity because some vehicles may have to
stop twice.
Uniform stops (Stops)
This is the predicted number of stops associated with a typical under-saturated cycle
Random stops (Stops)
This is the predicted number of extra stops associated with the randomness of arriving traffic and of
oversaturated conditions.
Unweighted Cost of stops (£/hour)
This is the cost of stops, but with all weightings removed from the calculations, allowing the ‘true’ cost
to be quickly ascertained. This avoids the need to remove weightings and run an un-optimised run of
TRANSYT to obtain them.
Weighted Cost of stops (£ per hour)
The total number of stops per hour is first obtained as the product of mean stops/Veh and the flow
into the traffic stream (or link). This total is then increased or decreased to allow for the kinetic
energy lost in making a full stop from the average cruise speed on the link as compared with a
standard stop from 12 m/second. The new total of equivalent standard stops per hour is then
multiplied by the value specified in Main (Common) Data, Value of 100 Stops and divided by 10,000 to
give cost per hour in pounds. An asterisk after the stop cost indicates that a stop weight other than
unity has been specified in the Link Data or Give-way Data for the traffic stream (or link) data
equivalents).
22.2.4 Results: “Queues and Blocking”

All results are relevant to all traffic streams and links. Initial queue, mean end of red/green, wasted
times, and estimated blocking do not apply to pedestrian crossings, nor are they shown.
When the results are shown in “Vehicles” instead of “PCU”, the “PCU” result is converted into vehicles
using the relevant vehicle mix and PCU factors.
Initial queue (PCU or Veh)
This is the initial queue as specified by you, or if using multiple time segments, the calculated initial
queue at the start of the displayed time segment period.

Page 454
Mean maximum queue (PCU or Veh)
The value given is the estimated mean over all cycles of the position of the back of the queue at its
peak during the cycle (measured in numbers of PCU back from the stop line rather than in distance
units); since it is a mean value it is likely to be exceeded during a significant proportion of the time.
Mean max queue EoTS (PCU or Veh)
This value is similar to the ‘Mean Maximum Queue’, but is the equivalent value at the end of the time
segment (EoTS).
Maximum Queue storage (PCU)
This is the maximum number of PCUs that can fit within the physical space of the traffic stream (or
link) (which is appropriate for the modelled time period). This can be either specified by you, or a
TRANSYT calculated one.
Utilised Storage (%)
This is the maximum percentage of used storage on the traffic stream (or link). This value is only
relevant if all traffic is stopped.
Average Excess Queue (PCU or Veh)
This is the average (over the cycle) of the excess queue checked against the Maximum Queue Storage.
This is NOT the same as the Average Limit Excess Queue.
Average Limit Excess Queue (PCU or Veh)
On traffic streams and links where a ‘queue limit’ has been specified, the mean back of queue is
checked against the queue limit during each step of the typical cycle, and any excess queues are
averaged over the cycle to give an ‘average excess queue’ for the traffic stream (or link).
Maximum queue storage (PCU or Veh)
For links other than those specified with a Max Queue Storage value, TRANSYT computes:
Maximum (Link) queue storage (PCU) =
SF Link length (m)

*
1850 ( PCU / h) 5.75
(i.e. approximate storage capacity of link)
This assumes that each PCU in a queue occupies 5.75m along a lane having a standard saturation flow
of 1850 PCU/hour of green. If the mean maximum queue exceeds the above maximum queue

storage, the printout is marked with a ‘+’ symbol in the mean maximum queue column to indicate a
possible problem which you are advised to check, if the timings are to be implemented in practice.
For links that do not have saturation flow, such as a give-way, the saturation flow is assumed to be
1850 so that the assumed max queue storage is simply the link length divided by the 5.75m.
For Traffic Streams other than those specified with a Max Queue Storage value, TRANSYT computes:
Maximum (Traffic Stream) queue storage (PCU) =
Link length (m)

number of lanes *
PCU length (m)
Where the PCU length is defined in Network Options > Traffic Options. The number of lanes is
the number of lanes that the traffic stream represents.
Excess Queue Penalty (£ per hour)
This the calculated cost on the traffic stream (or link) associated with excess queue.
Mean End of Green Queue (PCU or Veh)
This is calculated by taking the time step on which the signal changes from green to red - this gives
the uniform queue at end of green. The average random + oversaturated queue is then added to
this. N.B. this is intended to be equivalent to the OSCADY PRO End Of Green queue, and so is based
on queue (i.e. the number of queuing PCU) rather than back of queue
Mean End of Red Queue (PCU or Veh)
This is calculated by taking the time step on which the signal changes from red to green - this gives
the uniform queue at end of green. The average random + oversaturated queue is then added to
this. N.B. this intended to be equivalent to the OSCADY PRO End Of Red queue, and so is based on
queue (i.e. the number of queuing PCU) rather than back of queue.
Wasted Time Starvation (seconds (per cycle))
This is the effective green time wasted through traffic starvation. This is shown as an absolute value in
seconds rather than as percentage so that it can be easily summed over traffic streams and links.
Wasted Time Blocking Back (seconds (per cycle))
This is the effective green time wasted because of blocking back from downstream links. This is shown
as an absolute value in seconds rather than as percentage so that it can be easily summed over traffic
streams and links.

Page 456
Wasted Time Total (seconds (per cycle))
This is the total number of seconds of wasted green time due to either the starvation or blocking back
effects.
22.2.5 Results: “Fuel consumption”

As described in section 27.9, the estimates are sub-divided into three components: fuel used at cruise,
while delayed, and for stopping and starting. A user-definable network-wide composition of seven
vehicle types is used to calculate the fuel used as a rate per hour. None of these results are relevant
or shown for pedestrian crossings.
The results are presented as follows:
Fuel consumption Cruise (litres per hour)
Fuel consumption Delay (litres per hour)
Fuel consumption Stops (litres per hour)
Fuel consumption total (litres per hour)
Fuel Economy Total (Miles / gal)
22.2.6 Results: “Journey Times

Distance Travelled (PCU-hr/hr, or Veh-hr/hr)
Time spent (PCU-hr/hr, or Veh-hr/hr)
Mean Journey Speed (kph)
Journey Time per PCU (seconds)
These values presented here are the link and traffic stream equivalents to those presented as part of
the “Final Prediction Table” output (See section 22.4.3). Results are shown for all links and traffic
streams and pedestrian crossings.
22.2.7 Results: “Advanced”:

The advanced output values are only accessible from the “Results/Advanced” sections of the Data
Outline. Results are shown for all links and traffic streams. Results shown for pedestrian crossings
are indicated.
Degree of Saturation Penalty (£ per hour) – including pedestrian crossings

This is the penalty cost added to the P.I. as a result of the degree of saturation being outwith
the boundary limits set by you.
Ped Gap Accepting Penalty (£ per hour) – shown for pedestrian crossings only
This is the penalty cost added to the P.I. as a result of the level of pedestrian gap-accepting, set
by you, being exceeded.
Warmed up
This indicates when the network modelling process has successfully ‘warmed up’ the network.
When this does not occur it can affect the accuracy of the model.
Warmed up error
An error value associated with the warming up of the network. Used for fault-finding purposes
only.
Cost of traffic penalties (£/hour)
This is a summation of all the penalty costs associated with Excess Queue Limits and DoS
limits, which are added to the P.I. calculation.
Unweighted Performance Index (£/hour) – including pedestrian crossings
This is the sum of the delay and stop costs for the link WITHOUT any weightings or penalties
applied, giving the ‘true’ cost on the traffic stream (or link).
Performance Index (£/hour) – including pedestrian crossings
This output is repeated in the Vehicle and Pedestrian Summary results – See section 22.2.1
22.2.8 TRANSYT 12 tables: “Resultant Stages”

This set of results are part of the “TRANSYT 12 tables” output. Some items appear in multiple tables.
Descriptions are only given when describing the table items in which they first appear.
Controller Stream: At signal controlled junctions, this is the ID of the controller stream that
controlling the signals, as specified in Link Data>Controller stream or in Traffic Stream Data>Controller
stream. This is the TRANSYT object that also contains the signal data. No number is given for links at
unsignalled priority junctions. This item was previously known as the “Signals Node” in TRANSYT 13.
Resultant Stage: This is the index number of each stage, i.e. the first stage is 1, the second is 2, etc.
This is NOT the stage number.

Page 458
Is Base Stage: This indicates if the stage is a repeated stage (as part of a multiple-cycled controller
stream).
Library Stage ID: This is the ID of the stage (i.e. the stage number). This is the stage number used
when referring to a particular stage.
Phases In This Stage: Comma separated list of phases that run in this stage.
Call to stage: This is the time of the start of an old TRANSYT stage which includes the preceding
interstage, unlike the current definition of a TRANSYT stage. This output corresponds with the “Stage
starts” reported in TRANSYT 12 or earlier.
Preceding Interstage: This is interstage associated with the green time that together makes up the
‘TRANSYT’ stage.
Inclusive Stage Minimum: This minimum acts as a constraint on the optimiser. It includes the
preceding interstage and the minimum green time for that stage.
22.2.9 TRANSYT 12 tables: “Resultant Phase Green Periods”

This set of results are part of the “TRANSYT 12 tables” output. This table tabulates results for each
green period of each phase of each traffic stream. These results are probably only of interest to those
already familiar with them from using earlier versions of TRANSYT.
The following data is presented:
TRANSYT Starting Stage
Derived from the library stage data , this is the first stage in which the named phase runs, i.e. the
Starting Stage defines which of the stage change times starts the change to the green period on the
traffic stream (or link).
TRANSYT Ending Stage
Derived from the library stage data, this is the first stage in which the named phase no longer runs,
i.e. the Ending Stage defines which stage change time ends the green period. The green periods can
run between any stage numbers, e.g. 2 to 3, 2 to 6, 7 to 3, or 4 to 4 (in the latter case, the green
period will for the complete cycle).
TRANSYT Start Lag
The start lag is the time in seconds from the stage change time to the start of green signal on that
phase. The start lags (used internally by the TRANSYT model) are derived from the intergreens and
phase delays. The TRANSYT Starting Stage number plus the Start Lag defines the TRANSYT time at
which the actual green begins.

Usually the start lag corresponds to the interstage time, as shown in Figure 22-1. TRANSYT adds the
displacement of start of effective green (see Figure 4-9) to this lag to give the time of start of traffic
flow assumed in calculating delays etc. for the traffic stream (or link).
TRANSYT End Lag
The end lag is the time in seconds from the stage change time to the end of green signal for that
phase. Often this value is zero. The end lags are derived from the intergreens and phase delays. The
TRANSYT Ending Stage number plus the End Lag defines the TRANSYT time at which the actual green
ends.
Stage 1 actual signals
Red Red
Green Red
Demand
change to
stage 2 Start green on
stage 2
Start Start
Lag Lag
Start green on
Demand stage 1
change to
stage 1
Stage 2 actual signals
Green Red Green
Amber Red/Amber
Figure 22-1 Lag between change demand and start of green signal
22.2.10 TRANSYT 12 tables: “Stage Timings (TRANSYT 12 timings)”

This set of results are part of the “TRANSYT 12 tables” output. These values are provided for
backward compatibility. They represent the values produced by previous versions of TRANSYT prior
to TRANSYT 13.
For each controller stream the Number of Stages, the stage IDs and the
“Call to stage” start times (including preceding interstage) are shown.

Page 460
This section provides a description of the output results provided by TRANSYT relating to each
individual controller stream.
The results describe here are those from the “Signals” part of the report, which are also accessible
from Outline: Controller Stream N > Resultant penalties”. One of the items is also part of the
summary “Final Prediction Table” output.
22.3.1 “Signals > Output > Resultant penalties” report section:

Results are shown for all controller streams.
Phase Min Max Penalty (£ per hour)
This is an internally used penalty (i.e. not reported in final PI). This value, in normal operational
circumstances, will be zero.
Intergreen Broken Penalty (£ per hour)
Stage constraint Broken Penalty (£ per hour)
Cost of Controller stream penalties (£/hour)
This is a summation of all resultant (controller) penalty costs associated with broken phase
minimums/maximums or broken stage constraints or intergreens. These are added to the P.I.
calculation.
‘When a “Cost of Controller stream penalties” is non-zero, a warning message will

appear on the task list. The cause of this warning will need to be identified and fixed before an
evaluation run can be executed. However, full (optimised) runs can still be carried out, as long as
“Auto-redistribute” and green split optimisation options are both enabled. This is because the
optimisation process may fix the problem, although this is not guaranteed.
This section provides a description of the main output values provided within the TRANSYT results
relating to the network as a whole.

The descriptions here refer to values calculated when there is only one time segment.
See elsewhere for details of how varying flow conditions affect the results presented. For multiple
time segment cases it is generally the case that the most appropriate combination of the individual
values per time segment, highest values of all time-segments, and average values of all time segment
are shown.
22.4.1 “Summary” report section:

The following network-wide results are part of the Report “Summary” AND part of the Report
“Output”:
Run start / end time
This information records how long the run of the traffic model took.
Network within capacity (Yes/No)
Either YES or Blank. YES indicates that no items anywhere within the network have a DoS over the
user-defined degree of saturation threshold. The Percentage of oversaturated links and traffic
streams (see below) will be zero.
Percentage of Oversaturated Items (%)
This indicates the percentage of all links and traffic streams which have exceeded the user-defined
degree of saturation threshold. So, in this context, ‘oversaturated’ does not actually mean
oversaturated. In most cases the threshold will be set to a value that is essentially a practical
(acceptable) limit of saturation, meaning it is a justifiable descriptive term to use here.
Number of Oversaturated Items
An indication of how much of the network is oversaturated. A value of 0 equates to the network
being within capacity.
Item with highest DoS
This is simply the link or traffic stream ID of the item with the highest DoS within the complete
network.
Item with worst overall PRC
This is simply the link or traffic stream ID of the item with the lowest practical reserve capacity (PRC)
within the complete network. Both signalled and unsignalled items are referenced.
22.4.2 “Output” report section:

The following network-wide results are part of the Report “Output”:

Page 462
(Various) “Network Results” Tables
Various tables provide network-wide totals or averages of the appropriate link and traffic stream
values, e.g. “Network Results: Stops and Delays” and “Network Results: Queues and Blocking”. Where
applicable the link and traffic stream values are multiplied by the individual weightings before adding
into the totals.
The Performance Index reported within the Network results: Vehicle Summary table
includes all of the costs associated with each individual traffic stream. A similar table
displays the total pedestrian P.I. when pedestrians exist within the network.
The Performance Index reported within the Network results: Advanced table includes
all of the costs associated with each individual traffic stream and link and pedestrian
costs, but additionally includes any controller stream penalty costs - This is therefore
the same overall P.I. you will see in the “Summary Results” screen
22.4.3 “Final Prediction Table” report section:

The “Network Results” Table consists of up to five rows of results as follows:
1st line: Normal traffic… For Normal traffic streams and links only.
2nd line: Bus… For bus traffic streams and links only.
3rd line: Tram… For tram traffic streams and links only.
4th line: Pedestrians… For both pedestrian crossings and pedestrian links.
5th line: Controller Streams… Shows controller stream penalties (if any), such as those due
to broken phase minumums or maximums.
5th line: TOTAL… For all traffic streams, links and pedestrian crossings.
Certain lines only appear when these traffic types exist within the network
Extra lines... For ‘collection’ or ‘route’
A separate table is produced containing a set of results (equivalent to the network-wide

summary) for each defined ‘route’ or ‘collection’ within the network.

Distance travelled (PCU-km/hour or Veh-km/hour)
This is the product of total flow entering the link and link length, summed for all traffic streams (or
link equivalents). It represents traffic demand in the network. If any links within the network are
oversaturated, some traffic will be unable to pass on to downstream links; consequently, the total
distance value can be less than would occur in the absence of oversaturation. In practice, such
apparent reductions in travel due to oversaturation would probably be made up later as queues
disperse, but this would be after the end of the Simulated Time, for which TRANSYT calculations are
made.
Time spent (PCU-hours/hour, Veh-hours/hour)
This is the product of the flow into the link and the sum of the mean delay time plus mean cruise time,
summed for all traffic streams (or link equivalents). Another interpretation of this value is the average
number of vehicles present in the network during the specified period. Some vehicles will be
queueing - the number estimated by the average total delay (uniform and random-
plus-oversaturation) - the remainder will be travelling between intersections.
Mean journey speed (km/h)
This is total distance divided by total time to give an average speed which represents the typical
journey speed within the network. Not available for the “summary” time segment.
Journey Time per PCU (or Veh) (seconds)
It is the average time spent on the link by each PCU on that link It can be calculated by dividing the
link length by the average journey speed.
(Various) summed values
Other values in the summary are the appropriate totals of the link and traffic stream values. Where
applicable these values are multiplied by the individual weightings (indicated by an asterisk if other
than unity) before adding into the totals.
Signalled Level of Service (LoS)
This result is only available if the “Display level of service” option under Main Menu > Model and
Results Options has been enabled. This output is part of the “Vehicle Summary” and “Stops and
Delays” results tables.
This is the US Highway Capacity Manual (2000) signalled junction “Level of Service” (LoS) calculated
for each node. The ‘Node’ LoS is based on the flow-weighted average of the total delay of all
signalled traffic streams (or links) feeding into that particular Traffic Node.

Page 464
22.4.4 Path Segment results:

When traffic streams are used in a network, they generate an underlying network structure far
more complex than you would manually construct. This structure is made up of “path segments”
most of which are similar to links. These form into chains of path segments that carry traffic flows
from one specific “location” to another. None of the path segment data is editable, or of any
particular value to users. Path segment results however may occasionally be useful in interpreting
the network, as they reveal details of the traffic on a particular path segment, travelling along a
particular TRANSYT “path”. By default they are hidden (to speed TRANSYT up), but can be revealed
by enabling this option: Network Options > Traffic Options > Advanced > Calculate results for path
segments. See Outline: Traffic Streams > Traffic Stream n > Path Segments. N.B. at least an
evaluation run will need to be carried out after switching this option on, in order to repopulate the
file with this extra data. The data is never saved to disk.

Simulation Mode Page 465
TRANSYT 16 is the first major version of TRANSYT to include a Simulation model. A ‘Lane’
Simulation model was first introduced in Junctions 8 to provide a way to compare different entry
lane configurations at roundabouts and was extended in Junctions 9 to cover T-junctions,
pedestrian crossings and exit lanes. This model has been adapted and considerably enhanced for
use in TRANSYT - in particular by adding the ability to model journey (cruise) time between
junctions.
Generally any TRANSYT network you construct will work in both Standard Mode and in
Simulation Mode with few, if any, changes required. Simulation also allows you to model situations
which are not possible using the Standard Mode – see section 23.1.1
Running a file in simulation is generally slower than running a file in normal mode. However it has
the following advantages which represent the main reasons for considering simulation for any given
file:
 Modelling of demand-dependent scenarios, i.e. irregular stages modelled by defining

probability of them running
 Explicit modelling of blocking back issues (from downstreams)
 Explicit modelling of complex flares (short bays)

Page 466
 Explicit modelling of controller streams running on different cycle times, including across
zones (OD matrix boundaries).
 Modelling of the entire modelled period, allowing the network performance to be examined
in detail at any point in time
 Explicit modelling of oversaturated conditions
 Significant changes in network performance can be associated with a particular point in time
 Intuitive Information-rich visualisations showing traffic behaviour within the network
 Animations showing estimated positioning of individual vehicles
 Signal log over the full modelled time period
• Automatic collection of queue length percentile data
Although TRANSYT Simulation makes use of some aspects of the core TRANSYT models including
some empirically-derived components, it is not in itself derived from empirical studies. Therefore
you should (as always) apply engineering judgement to both the application of the model and the
interpretation of the results.
23.1.1 Applicability of simulation

Simulation Mode in TRANSYT is provided as a tool to model the same single junction and traffic
network scenarios that you would model using the non-simulation TRANSYT traffic models. However,
there are a number of scenarios or effects that can only be modelled using one of these models.
These are as follows:
Scenario / Effects Standard mode (non- Simulation

simulation)
Intermittent stages (Demand X 

dependency)
Complex signalled flares (short X 

bays)
Platoon dispersion  X
Signal optimisation  Not yet
Network ‘link’ structures  X
Modelling of buses and trams  No separate model
Oversaturation   More explicitly
The standard models are based on the premise that the defined stage sequences run consistently
time and time again, and the majority of TRANSYT results are ‘average’ results across the whole

modelled time period. This is why demand dependent scenarios cannot be directly modelled in
Standard Mode, and only limited approximations of that behaviour accommodated within the model
using the multi-cycling of the stage sequences facility. Simulation allows you to model signalled
situations which are not possible using the Standard Mode.
The modelling of give-way approaches is the same as it would be when using TRANSYT in standard
mode. Please note that this is still based on the standard give-way coefficients (slope coefficient and
intercept (max flow)) values being applied to the overall single approach, or specified to individual
traffic streams, where this is deemed to be necessary.
In Simulation Mode there is no change to how Pedestrian flows on crossings are modelled.
Because the Simulation model is an analytical one rather than being based on empirical studies, you
should (as always) apply engineering judgement to both the application of the model and the
interpretation of the results.
When in Simulation Mode, TRANSYT uses a simulation technique, which is based on the simple
modelling of individual vehicles. (This does NOT allow for all effects such as acceleration,
deceleration, gap-accepting by individual vehicles and so on; rather, it is mainly concerned with
queueing behaviour and travel time along traffic streams while taking into account traffic demand
and available capacity.
Each vehicle is allocated to a traffic stream according to the vehicle’s desired movement (based on
the entered turning proportions) and the allowed movements, based on the network connectors and
associated underlying path structure. Where there is more than one lane within a traffic stream, the
next vehicle will choose the lane with the shortest queue at that moment it makes its lane selection.
Within each traffic stream all lanes go to the same destinations so all lanes are the same as each
other. See section 23.9 on how this can affect your choice of network structure.
The length of each traffic stream can be defined either manually or estimated by TRANSYT, in terms of
the number of PCU that can be stored in each traffic stream. This is split between the numbers of
lanes the traffic stream represents. If such a lane is filled with queueing vehicles, then new vehicles
cannot enter the lane and instead will queue in upstream lanes.
At any point on an approach where the number of lanes changes, for example, entering a flared area
represented by a new set of lanes and traffic streams, each vehicle will again choose a suitable lane,
using the same rules. Vehicles do not change lane at any other time.
The simulation runs for the entire modelled period - for example 60 minutes – with results being
collected and reported for the whole modelled time period (or per time segment period if more than
one is defined). A single simulation run would be unlikely to give useful results, because it could be
unduly influenced by the random nature of the simulation. Instead, many runs (trials) are performed
in succession, with the results from the runs being averaged to give an overall result. In practice often
only a few trial are needed, especially if everything in your network is signalled.

Page 468
When in Simulation mode, the complete network is modelled using the simulation. It is not possible
to selectively turn the model on or off for individual parts of the network.
You can adjust the time taken by simulation runs by adjusting the Stop Criteria (see
section 23.13.2). Generally you do not need to wait for a run to finish and can press
the Stop Simulation button as soon as results become apparent.
If running several Analysis or Demand Sets, any sets that use Simulation mode will be
included but will slow down the overall run time.
You can generate x-y graphs whilst in Simulation mode. If you do so, we recommend
increasing the convergence criteria (see Error! Reference source not found.) to a high
value (e.g. 10%) or setting the number of trials to a very small number, and using a
relatively small number of points to reduce the overall run time.
23.3.1 Turning on Simulation Mode

Simulation mode can be turned on for individual Analysis Sets. This can be done either for a new
file, or for an existing file, and can be changed at any time.
Use the Data Outline and Data Editor to tick the Use Simulation property for the current Analysis
Set: Some of the items available in the Data Outline and main vertical toolbar will change to reflect
the different options available in this mode.

Alternatively, simply press the Simulation button on the main vertical toolbar. This will
automatically switch the current Analysis Set into Simulation Mode and will also launch the main
Simulation Screen, from where you can control the simulation.
23.3.2 Running the simulation

Once you have constructed your network, in the usual way, and if there are no errors in the file, you
can run the simulation. (In fact you can open an existing TRANSYT file, change to Simulation Mode
and run the simulation immediately; this will use the default simulation options.
Firstly make sure that the Simulation screen is visible. If not, press the Simulation
button on the main vertical toolbar.
When you press the Start simulation button, TRANSYT will begin to model vehicles in
the network. This involves running a large number of trials of the simulation (each of which models
the entire modelled period, e.g. 90 minutes), with vehicles being randomly generated in accordance
with the entered demand flows. The results from each trial are averaged, and as the number of
trials increases, the accuracy of the results gradually improves.
Depending on a) your PC performance, b) the complexity of the network or junction and c) the
modelled time period (e.g. 90 minutes), please note that it may take some time to run the
simulation.
Whilst the simulation is running, the main user interface will regularly update any open
screens, so that you can see the results and any selected visualisation immediately and
throughout the simulation. If you find that the UI appears to freeze, try changing the

Page 470
Results Refresh Speed (Data Outline > Options > Simulation Options) - see section
23.13.
As the simulation runs, some important numbers are shown at the top-right of the screen:
• Number of trials: this is the total number of trials run so far.
• Duration: the time spent running the simulation, shown for reference (this is a function
of your PC speed and is NOT related to the modelled time period)
• N of M converged: this indicates the number of traffic streams in the network which
have converged, based on the convergence criteria that you have set – click to see the
value of each individual convergence measure. See section 23.13.2 for more detail on
how to set the convergence criteria. You can tick the “Indicate on diagram” option to
visualise which parts of the network have converged. Red means it not converged. Amber
if it is close to convergence and green if it has fully converged.
•
•
The simulation will stop automatically when any one of the convergence criteria is reached,
however, you do not need to wait for this. In most cases, the performance of the network/junction
will be obvious almost immediately, and you can press the Stop Simulation button as soon as the
results become apparent. For example, the Summary Results screen may show almost straight away
that the queue on Traffic Stream 1 is 10 PCU. If you leave the simulation running then it may
eventually show a more accurate value of, say, 8 PCU, but you may not need this level of accuracy.
For comparing alternative lane movement designations, for example, the overall conclusion of
whether the network performs well or not is often obvious very quickly.
However, if you wish to obtain repeatable results, then you may wish to leave the simulation
running until it stops automatically. In this case, you may also want to set the Random Seed (see
section 23.13) to a fixed number, and the Stop Criteria (see section 23.13) to your own preference.
Note that if the demand is low, then the simulation can take a long time to stop. This is because the
random variation between trials will be large compared to the flows and queues. Again, however,
this only applies to the case where you leave the simulation running until it stops automatically.

As soon as the simulation starts, the Summary Results screen is shown. (Unless your user
preferences have turned this off.) In this screen, and in any other screen that shows results, the
values will change as the simulation runs.
If you re-start the simulation and again stopped it straight away, you may well see different numbers
– although the overall conclusion of whether the queue and delay is low/medium/high will be the
same.
If you stop the simulation after only a few trials the results are only approximate. If you leave the
simulation to run for longer, however, then the results become more accurate and the fluctuations
in the results reduces – although note that there will always be a certain amount of variation.
As the simulation runs, results are collected for each time segment, and these can be seen in the
usual areas of the Data Outline. The Summary Results screen shows the maximum values over the
modelled period.
Detailed results are available both for each traffic stream, via the Data Outline or the main Results
toolbar button.
The key difference between simulation results compared to a normal TRANSYT model run is that
results from the simulation are ‘measured’ from the individual vehicle simulation, rather than being
predicted analytically. For example, the Demand is measured as the number of generated vehicles,
and although this generation rate is based on the network traffic demand, it will not be exactly the
same. For complex flared approaches where one or more traffic streams feed into other traffic
streams on the way to a stop line, then the demand on the downstream lanes corresponds to the
amount of traffic assigned to each lane. For example, if a downstream lane does not allow a
particular movement, then the demand for that movement on the lane will be zero.
All lanes within a traffic stream inherit the traffic movements associated with the parent
traffic stream.
Throughput is measured as the flow of vehicles across the stop line or give-way line.
End of Red/Green Queues are simply the number of waiting vehicles, measured at that point in the
cycle, throughout each time segment.
“Mean Max Queue” is the average maximum back of queue position across each time segment.
Some “EoTS” - End of time segment - results are also provided, such as Mean Max Queue EoTS.

Page 472
For traffic streams, delay represents the total time spent queueing in the traffic stream. If there are
multiple lanes within the traffic stream then the total delay on the traffic stream will be the sum of
the delays experienced by vehicles on these lanes.
Degree of Saturation values, and RFCs are not calculated, as there is no single specific value that can
be calculated for these, for example the capacity of a traffic stream depends not only on Saturation
Flow but also on the lane configuration and turning movements. A low DoS could mean that the
flow is low compared to the capacity (i.e. the usual interpretation), but it could also mean that the
flow is low because it is restricted due to the lane configuration/movements. For this reason, DoS
values are not shown. We recommend looking at the overall queue and delay situation across the
components of the network that you are most interested in.
For any situation, where you wish to calculate the maximum possible entry flow for a given lane
configuration and set of turning proportions, then you can set scale the OD demand flows to high
values, which will have the effect of flooding the network with extra demand. The calculated
Throughput on each traffic stream will then represent the most that the part of the network can
cope with. However it is important to note that if the turning proportions change or lane
designations change, then the overall capacity may change.
Queue length percentiles are produced automatically from the queue probability distributions that
are built up as the simulation runs. The queue percentiles are shown as visualisations on the
network diagram. They are not reported as numerical results (such as in the Data Outline).
From the Simulation screen, you can choose from several visualisations to display average queues
on each lane in the Junction Diagram. This can be extremely useful when looking at the overall
performance of your network or junction, or when comparing alternative lane configurations.
Visualisations can be shown and animated as the simulation is running, or after the simulation has
finished. Note, however, that visualisation data is NOT saved in the data file. That is, you must re-
run the simulation if you load a file and wish to display visualisations.

The visualisations show data that is collected from the simulation for each second of the modelled
period. (Additionally, data for each time segment is collected and stored in the usual Data Outline
locations.) As you drag the Time slider in the Simulation screen, queues in the Network Diagram are
shown for the indicated time.
Note that queues are scaled in the diagram according to the current scale of the drawing; see
11.10.1.1 for more details. To display the full extent of the queues, you may need to stretch the
entry traffic streams to cover a longer approach. It is also recommended that traffic stream “auto
length” facility is switched on for all traffic streams.
TIP: Select “Backgrounds> Show backgrounds and numbers/overlays only” to hide most network
items while the animation of vehicles and queues, etc.
The visualisation types are described in the following sections.
NOTE: Visualisations are available almost immediately after starting the simulation. Leaving the
simulation to run for longer will not model a longer time period but will simply refine the accuracy of
the results.
23.6.1 Individual vehicles

In this mode, individual QUEUEING and/or MOVING vehicles are shown in blue. See below for
examples of a network with the “Show moving vehicles” option ON.

Page 474
See screenshot below of “Individual vehicles“ with “Show moving vehicles” option turned OFF.
As you drag the Time slider, or use the animation controls, you can see the progress of individual
vehicles. Note that the graphics represent a single trial of the simulation, rather than averages.
Unlike the other modes, the accuracy of this visualisation does NOT improve as the simulation runs
for longer. The purpose of this mode is simply to display roughly which traffic streams and lanes are
used by which vehicles. If you start the simulation again, the individual vehicle animation is unlikely
to be the exactly same as the last run unless you use a fixed seed (see section 23.13.3).
TIP: The animations of individual vehicles will look better if all traffic stream “lengths” match their
lengths as drawn in the diagram - The traffic stream “Auto length” option makes this easy to do.
In the example shown above, each coloured block represents a single vehicle.

You can control the size of the blocks by adjusting the network diagram scale, but if you adjust this
please be aware that auto-calculated network geometries such as traffic stream length will be
affected by this change.
In addition to the “Show moving vehicles” option, a number of visualisation options that are
relevant when displaying individual vehicle” animations have been provided as follows:
• Show back of queue: When OFF, the animations will show the queue length on each
traffic stream starting from the stop line. With this option ON the queues will be
displayed more realistically, as they would appear on-street, i.e. showing the progression
of the front of the queue moving back from the stop line. This will give a better
indication of where the back of the queue really is.
• …with white interior: This option simply makes it easier to see the space vacated by
traffic crossing the stop line.
• Draw outlines: This adds a black outline to each vehicle making it easier to see the
individual vehicles, particularly when they are superimposed over a network diagram.
• Show path IDs: The TRANSYT network is made up with a series of local OD matrix paths,
each of which have an ID. This option places this ID inside each vehicle on the network
diagram so that you can identify the individual path taken by each vehicle.
23.6.2 More Individual vehicle options

An additional collection of useful visualisation options have been provided which alter the individual
vehicle animations. You can access these from within the “More individual vehicle options” tab.
• Filtering:
o Current path: Switch this filter ON and select an OD Path to filter out all vehicles
apart from those using a particular OD Path.
o From/To current location: Switch this filter ON and select an OD location to filter out
all vehicles apart from those coming from or going to the location of interest.
o Every 10th vehicle only: This option can make it easier to see the paths taken by a few
individual vehicles
o Show other veh: This option allows you to see, in a subtle manner, the vehicles that
have been filtered out of the animation
o … with white interior: This option simply makes it easier to see the vehicles that have
been filtered out. Also switch on the “Draw outlines” for a clearer view, if your traffic
streams are white or you are using a background image.
• Colour coding

Page 476
o By location source/destination: With this coding ON, individual QUEUEING vehicles

are shown, colour-coded according to their source or destination OD location.
o Time in queue: With this coding ON, each vehicle in a queue will start out yellow, and
slowly turn red the longer it has been waiting in the queue. In this way, it draws your
attention to the worst delays within your junction or network.
Vehicles of the same colour have subtle random shading applied (e.g. light red or dark red); this is
simply to make it easier to tell whether a queue of vehicles for the same destination is moving or
static.

23.6.3 Average queues

This mode uses a single colour (blue) to show the average amount of traffic queueing on each lane,
for that point of time within the modelled time period.
In the snapshot above, you can see relatively modest queuing across the signalled roundabout.
Note that average queues may be shown in upstream lane levels even though there appears to be
space in the downstream lane levels – e.g. as shown on the approach from Location 5 (bottom right)
in the screenshot. This can have two causes: firstly, the downstream parts of the network can be
partially starved of traffic due to blocking from an upstream queue. Secondly, because the values
are averages, there will be times when the overall queue is short, and this will reduce the average
below the value of the storage of the lane.
23.6.4 Shaded percentile queues
This mode uses a single colour (blue), with the intensity of the shading representing the probability
of queues. The darker the colour, the more likely it is that the queue will reach that point.

Page 478
Generally, the shading will be darker towards each stop-line. I.e., it is highly likely that the queue
will be at least 1 PCU, but unlikely that it will be, say, 100 PCU. As you drag the Time slider, the
diagram will show how these probabilities evolve over time.
In the snapshot above, the offside lane on the approach from location 5 feeding the flared area is
pale, indicating that the queue is only occasionally there, while the adjacent lane has no queue
shown indicating that the likelihood of a queue reaching this far back is less likely.
23.6.5 Single percentile queues at X%

This mode is similar to Shaded percentile queues, except that only queues above a certain threshold
are shown. By default, X is set to the minimum of 50%, but can be increased using the slider control.
In the first snapshot below, there is a 70% chance that the queue on each lane will be longer than
the blue bars. In the second snapshot, the slider was changed to 90%, and so the blue bars
represent the 90th percentile queue lengths – i.e., there is only a 10% chance that the queues will be
longer than the bars.
The queue bars are capped to the physical storage within the entry traffic streams so
may be longer than those shown.)
Unlike the Standard TRANSYT models, Simulation mode allows you to model accurately the full
effect of controller streams operating on different cycle times. You should see the ebb and flow of
queues and delays as parts of the network drift in and out of coordination throughout the modelled
time period.
See section 16.10 on how to set different cycle times for individual controller streams.

Demand dependent scenarios come in many forms – pedestrian crossings triggered by pedestrians,
bus priority systems, level crossings, and of course vehicle actuation to name but a few. All of these
examples and more can be translated (approximated) into how intermittently a particular stage runs
throughout the modelled time period.
Two options are available, in the Library Stage’s properties:
 Run every N cycles: by default this is set to 1, meaning that the stage will run every cycle. If
you set it instead to 2, then it will only be used every 2nd cycle, and so on. For instance if the
Stage Sequence is 1,2,3,4, and Library Stage 4 is set up only run every two cycles, then the
resulting sequence in Simulation would be 1,2,3,1,2,3,4,1,2,3,1,2,3,4….

Page 480
 Probability of running: by default this is 100%, meaning that the stage has a 100% chance of
appearing in each cycle (assuming it is contained in the Stage Sequence of course). If set to,
say, 50%, then there will be a 50% chance of any given cycle containing the stage. (The
overall rate will be apparent over a large number of cycles.) This can be used to simulate an
event that occurs randomly, such as a pedestrian stage.
To confirm the behaviour of such stages, it is useful to use the Signals log (section 23.12).
This choice is not limited to Simulation Mode, but is mentioned here in order to reinforce how in
simulation mode lane choice and traffic stream choice differ.
The use of traffic streams to represent multiple lanes ensures traffic is free to choose the lane with
the shortest queues, while the use of one traffic stream `to represent each individual lane allows
you to predetermine the choice of lane via the extensive flow allocation local OD Matrix options.
Your traffic stream choices are basically the same ones you would make whether or not you are
using Simulation Model or one of the standard models. For example, as a fully signalled
roundabout, with expected good lane discipline one traffic stream for each lane is a good way to
construct your model. Where there is sufficient lane choice to be made by drivers such that queue
lengths will equalise, multiple lanes per traffic stream will be best, subject to the usual rule that
lanes presented with different signal states must be represented by different traffic streams.
Simulation inherently models both the effects associated with traffic blocking back into upstream
junctions and also the effects of blocking back from the short bays associated with flares.
Generally it is a lot easier to see what is happening and when it is happening within the modelled
time period compared with the standard ‘average cycle‘ models.
Simulation inherently models oversaturation within a model. Where you wish to see the rise and fall
of queues and delay associated with a peak period, and take into account the recovery period after
an oversaturated period of time, it is recommended that multiple time segments are employed, so
that you can specify the time varying traffic demand associated with your peak period.
.
Because the full modelled time period is presented as one seamless time frame of visualisations that
can be stopped at any point, it is generally a lot easier to see what is happening and when it is
happening compared with the standard ‘average cycle‘ models.

Following or during a Simulation run, pressing the Signals Log link at the top of the main Simulation
screen will show a “recording” of the signal state of each phase, for a given Controller Stream, for a
portion of the simulation. This can be useful to confirm that the pattern of signals is as expected.
Use the Spacing slider to control the appearance.
The numbers at the bottom show the time in seconds, and the ID of each Library Stage when it
begins.
In the example above, the Signals Log confirms that the stage sequence shown in the Timings
Diagram simply repeats every cycle, as expected. If however, Stage 2 is set to only run every 2 cycles
(see section 23.8 on modelling intermittent stages), the Signals Log confirms this behaviour:
If you enter a Traffic Stream ID (e.g. “2/1”) and tick the adjacent box in the lower half of the screen,
you can then tick one of the “Queue” options to display a recording of the queue count for each
second of the simulation for that stream. In the example below the stream is under-saturated, so
the queue builds up during each red and then clears during the green. Because the simulation
models the entire time period (as opposed to a single cycle), the variation between cycles due to
random arrivals at the outside of the network is clearly visible. Please note that the data is taken
from a single simulation trial and you will see a different pattern (but of the same overall general
shape) if you do a new run.

Page 482
In the example below, the stream is oversaturated and the greens are not long enough to clear the
queue, so it builds up over time.
It is also possible to show the flows for a given movement, as recorded by the simulation. To do
this, firstly turn on Data Outline>Options>Simulation options>Do flow sampling. Then in the Signals
Log screen, enter the IDs of the ‘from’ and ‘to’ Traffic Streams and tick the adjacent box. You then
need to run the simulation. Please note that when recording flow data the simulation may take
longer to run. Finally use the “Flows” options in the bottom-left corner of the screen to choose
which type of flow and drawing style.

Briefly, the flow types are:
 Measured: “raw” value; unlikely to be useful

 Max: a “profile” applied to the “raw” value based on the signal pattern and other
information
 Result: the result of the operation above. In the example below this is the yellow pattern,
which shows how at the start of green the flow is the stream’s saturation flow and then
drops to a smaller value once the queue has cleared. The shape differs between cycles due
to random variation.
 Long-term: rolling average over all seconds so far.
If a traffic stream provides a controlling flow for a give-way stream, it is the ‘Result’ flow shown in
this screen that is used.
There is a certain degree of “noise” in the data shown in this screen, partly from the
modelled random variation in traffic arrivals, and partly due to the way the data is collected.
Therefore the data should be treated as indicative rather than a precise rendition.
Options controlling Simulation can be found in Data Outline: Options> Simulation Options.
23.13.1 Critical type

Select the simulation output that is checked to see if the results have converged.

Page 484
23.13.2 Stop criteria (%)

The simulation will stop automatically when the Convergence shown in the simulation screen
reaches this value. You can, of course, stop it manually at any point.
Convergence is a measure of how much the results from each trial vary from the overall average. By
default, the simulation will continue to run until the convergence measure of all items reach the stop
criteria. The actual data values of the convergence measure are accessed from the Data Outline’s
“Advanced” results for each traffic stream.
You can also set a Stop Criteria Time and a Stop Criteria Number of Trials; the simulation will stop
when any of the criteria is met. For example you can limit the duration of all runs to 5 seconds by
entering the Stop Criteria Time as 5s.
23.13.3 Random seed

This is used to seed the random number generator used in the simulation. By default, a new
random seed is used for each simulation, which means that repeatedly running the same model will
give slightly different results. If you want to be able to exactly replicate a set of results on repeated
runs, you should set the seed to a fixed number before running the simulation.
23.13.4 Results refresh speed (s)

When the simulation is running, the main user interface (UI) windows will be refreshed at regular
intervals according to this value. By default this is set to a few seconds. If you find that the
simulation runs very slowly or the UI seems to lock up, try setting this to a higher value.
23.13.5 Average animation capture interval (s)

When animating average queues, these are ‘stored’ by the simulation by default every 60 seconds.
(The animation interpolates between sets of queues to give the impression of a smooth animation.)
Optionally you can configure the simulation to store queue more frequently by entering a smaller
number. This can be useful if animating signalised lanes where the queues need to be stored
multiple times per signal cycle. However, reducing the interval will use more memory and it may be
easier to instead simply rely on the Individual vehicles animation, which is always available for each
simulated second.
23.13.6 Use queue response

The core give-way models assume that the capacity of a give-way entry is based on the current
opposing flow of the controlling/opposing traffic stream(s). This also applies to opposed right-
turners in signalised cases. When using Simulation, the controlling flows are re-assessed
continuously and so can vary within a time segment. However, there is a limit to how often this re-
assessment can be reliably performed.
Access to this parameter is special provision to ensure that any controlled streams act as if the
relevant controlling flow has immediately dropped to zero while the controlling stream is stopped.

This makes various assumptions and ignores any queues that may be discharging from the
controlling stream when the crossing/red light first activates. If you wish to NOT use this provision,
turn this option off.
The individual vehicle animation can be useful for checking whether traffic responds to crossings in
the way you would expect, although note that the random nature of arrivals and departures can
often be a more important factor.
23.13.7 Do flow sampling

Switch this option ON to enable flow sampling. This is required if you wish to show any diagnostic
plots.
23.13.8 Uniform vehicle generation

Select this option if you wish to assume that vehicles entering your network (i.e. entry traffic
streams only) arrive in a uniform manner, rather than their arrival distributed randomly.
23.13.9 Last run

The values of these items used in the most recently run simulation are shown here for reference, i.e.
 Last run random seed

 Last run number of trials
 Last run time taken (s)

Page 486

Analyser (X-Y Graph) Page 487
Click this button on the vertical toolbar to show the Graph analyser.
The Analyser is a powerful analysis tool that allows you to investigate how the performance of the
network is affected by any numerical data item. It is common for engineering packages to include
'sensitivity analysis' or 'marginal analysis' features, where the output shows the effects of certain
predefined changes – for example, the change in delay due to changing the cycle time by 1s.
TRANSYT does not include sensitivity analysis in its output but the Graph analyser allows any such
effects to be studied. The results can be exported to a word processor or spreadsheet, enabling
several graphs to be compared or combined.
The two modes of the Analyser Screen are selected via the large buttons at the top of the screen, with
sub-modes appearing as appropriate.
Depending on the input variables selected, you may

wish to plot your graph by either carrying out a
series of evaluation runs, or a series of fully
optimised runs using whatever optimisation options
are set within the file. Select either “Evaluation
results” or “Optimise results” as needed.
The lists of input and output variables are used for

all modes, although certain items and columns will
become disabled or may disappear depending on
the mode selected.
Before using any Analyser mode, we recommend

performing a TRANSYT run first to make sure there
are no errors in the file.
Tip: It is not possible to embed Analyser graphs and charts within TRANSYT reports, however it is easy
to use them within your own reports: simply right-click on a graph and select one of the Copy options,
then paste it into your application.
24.1.1 Adding inputs and outputs

The Analyser Screen is split between ‘inputs’ in the upper half of the screen and ‘outputs’ in the lower
half.
Inputs cover any data field item that can be entered in the Data Editor. To add an input to the list of
input variables, click on it in the Data Editor (or a Data Grid) and then click on the Add: option in the
Input Variables panel.

Page 488
Outputs cover any data field that is shown in the Data Editor as a result type, i.e., any item with a light
green background. (Advanced users can also add other data items as outputs.) To add an output to
the list of output variables, click on it in the Data Editor (or a Data Grid) and then click on the Add:
option in the Output Variables panel.
For inputs and outputs, turn on Auto-add in order to automatically add each field clicked on in the
Data Editor. This is useful when adding a large number of data fields.
Only numerical items can be added. Items may refer to a particular traffic stream and/or time-
segment, or may be more general items such as overall flow scaling factor.
Use the Remove options to clear the lists and Reset Ranges to reset all ranges to default values.
Once you have added items, you can quickly go back to the corresponding item in the Data Editor by
double-clicking any row in either list.
Outputs may have a colour assigned for each item, to distinguish the various outputs on graphs. Set a
colour by double clicking in the colour column. Use the Auto-colour to quickly assign colours.
The lists can be sorted by any column by clicking the column header.
24.1.2 Saving graphs

You can save the definition of X-Y graphs and Time graphs by clicking Save Graph at the bottom of
the screen. To retrieve a saved graph definition, select it from the dropdown list.
These definitions are saved with the file. Note that only the definition is saved (i.e. the
input/output variables and ranges), not the actual graph itself.
24.1.3 X-Y Graph Mode

This mode produces graphs showing how one or more outputs from TRANSYT vary as an input
variable is altered over a defined range.
If there is only one input and output variable, then the input variable is used as the graph’s x-axis, and
the output variable as the y-axis. If there are more items, then you must select the items to use by
clicking in the Input/Output Variable lists and, if necessary, holding down CTRL to select multiple
rows.
A simple example of using the Graph Analyser might be to draw a graph showing how weighted
delay costs changes as the network cycle time varies. As the cycle time is varied between its
minimum and maximum values, TRANSYT re-runs the network and plots the resulting performance
index.
To set this up, follow these steps:

 Show the Analyser Screen and select X-Y Graph mode.
 Use the Data Outline to navigate to Network Options > Network Timings. Double-click to bring
up the Data Editor. Click on the Network Cycle Time. Click on the Add option in the Input
Variables section of the Analyser screen to add this variable.
 Use the Data Outline to navigate to Network Results > Stops and Delays. Double-click to bring
up the Data Editor. Click on the Weighted Cost of Delay. Click on the Add option in the Input
Variables section of the Analyser screen to add this variable.
 The range of the input variable is set by default to the built-in range of the variable, but you
can change this manually when needed. A step-size is also set automatically, but you may
wish to change this depending on the accuracy and speed required. Having adjusted the
range and step-size, the Analyser screen should now look like the below:
 Rather than manually entering the Min and Max values, a more convenient method is to turn
on Auto-set ranges and then choose a range, such as 10%, in the drop-down box. The Min and
Max will then automatically be set to 10% below and above the current value of the
parameter, and will be updated whenever the current value changes.
 Press either the Line or Bar button under the X-Y Graph mode button to generate the graph.
This will perform a set of TRANSYT runs and plot the results, while also tabulating the results
as it goes. It is normal for some points to be missing; this usually occurs at the extremes of the
x-axis range.

Page 490
Because TRANSYT re-runs the entire file for each data point, the process may be slow.
Do not use a small step size unless you are prepared to wait some time for the graph to be
completed.
the order of graph points is assigned randomly; this is so that the shape of the graph
becomes apparent quickly and you do not have to wait for each point to be plotted one by one.
When plotting a line graph/ bar chart the data points of the graph/bar chart are also reported on
the right hand side of the graph. This data can be used to plot the same graph in third-party
products such as a spreadsheet program. Right-click on the grid to copy the data to the clipboard.
Similarly, right-click on the graph to access a menu for copying the graph to the clipboard.
The “Show Table” option allows you to optionally hide/show the grid of data point values.
Switch off “Auto Range” in order to define the range of the displayed graph. This is particularly useful
when you want to zoom into part of an already plotted graph. Use the two “Force” boxes to activate
your choice of axis range (min max values).
Almost any parameters can be investigated in this way by using the x-y graph analyser.
To plot more than one item, simply add the items required to the Output Variables list and then select
all those to be plotted by holding down the CTRL key whilst clicking on the rows.

The example below shows how the three separate fuel consumption figures vary as the network flow
scaling factor is changed. It shows that, as overall traffic flows are increased, the fuel consumption
attributed to delay increases considerably (blue line) while that attributed to stops (green) and cruise
time (red) increases relatively little in comparison.
If the items plotted are different items but of the same type, then the scale and gridlines are shown as
usual, as is the case for the example above, i.e. all shown in units of litres per hour. (To use different
units, change them via the Options>Units section of the Data Outline or via Data on the Main
Menu.)

Page 492
If the items plotted are of different types then the scale is removed and the graph becomes schematic
only. In these cases, such as the below, the lines should only be used to study trends and not to read
absolute values. The units of each item are shown in the key as usual and, by choosing different units,
the relative ‘sizes’ of each type of item can be controlled.
24.1.4 About X-Y Graphs

When running x-y graphs, one variable is altered while everything else in the file remains constant.
Sometimes this will be unrealistic, since there are interactions between the chosen variables, such
as give-way geometric ones. In particular, if plotting a geometric item such as entry width as the x-
axis, remember that all other geometries will be held constant. In reality, if there is a flare, then the
effective flare length would also alter as the enter width changes. However, the x-y graphs are still
extremely useful in terms of showing trends and the overall effects on results.
It is also important to remember that each data point in the graph represents a complete re-run of
TRANSYT including optimisation, if that’s selected in the file. Unless using un-optimised evaluation
timings, this means that the actual signal timings may be different for each data point. In some
cases, consecutive data points may represent quite different sets of signal timings, leading to
correspondingly different performance indicators. This in turn can sometimes lead to local ‘spikes’
or other discontinuities in the graph. Usually these are small in magnitude and are to be expected
given the nature of the signal optimiser. We recommend switching on the “auto redistribute”
optimisation option to ensure that the starting timings are the same for each optimised run. If
larger effects are still noticeable, these may be worth investigating further – for example, by saving
two or more versions of the TRANSYT file with the x-axis item set to values either side of the ‘spike’,
and studying the results for each file.
The speed of running graphs will depend heavily upon the network size and the model parameters.

Many graphs give intuitive results, for example confirming that delay decreases as saturation flow
increases. Some graphs, however, are more complex, and the shape of such graphs may arise from
the interactions between the many variables in TRANSYT.
24.1.5 Time Graph Mode

This mode provides a way to see how any output variable varies over time (if at all). Note that, unlike
the other modes, you must have previously run the file.
The Input Variables panel is not active in this mode. In the Outputs Variables panel, set up the
output(s) that you want to study. If any of the variables do not vary over time (i.e. they are not part of
a time-segment input or output), then they will be ignored.
Press the Line or Bar buttons to plot the data graphically, or use Table to show the data numerically,
as shown in the examples below which show how Highest DoS varies over time. The data in the Table
screen can be selected and copied into a spreadsheet or similar.

Page 494
In the examples above two collections have been defined within the network, and results of each
assigned a colour in the Analyser, allowing the highest DoS to be shown for each time segment and
collection.
It is also possible to plot charts where different types of item are shown, as in the example below
where a different output for each collection is shown. In this case, the label and scale on the y-axis is
removed as there is no scale that can be used for all of the items; the graph is schematic only.
For more advanced analysis, we suggest using the Table mode and then selecting the entire table and
pasting it into a spreadsheet.
Advanced users may wish to make use of a further mode: if the Line or Bar button is pressed using the
right-mouse button, the graph window will appear outside the main program window and will be
semi-transparent, allowing several graphs to be overlaid as in the screenshot below. This can be
useful if overlaying graphs that use different units and scales, where, for example, one set of points
would be much smaller than another and so would not show up. Instead, plot the graphs separately
and then overlay them using this right-click mode. Remember that the graphs will become ‘detached’
from the main TRANSYT window.

Additional Tools and Features Page 495
One of the most laborious tasks associated with Network construction is the naming or renaming of
the many network item ID’s to match your needs. TRANSYT now includes a tool to automatically
rename each type of Network item automatically. This tool is access from Main Menu > Tools >
Automatic Network Item Naming.
To use this tool complete your network as much as possible,

and then carry out the following actions:
1. Open the renaming tool, and select the first (type of)
network item that you wish to rename, such as “Nodes” or
“Arms”, etc.
2. Select the method you wish to use to name your item, such
as “Nearest Node”, “Network Position” etc.
3. Now define the scope of the renaming process – You can
rename either the “Entire network” or “Select Objects” by
selecting in the network diagram
4. Select any of the additional “Options” which may apply.
5. Press <Apply>
6. Repeat the process for as many object types you wish to
rename
“Traffic Stream Names” + “Movement”: This selection allows you to populate the “Name” (not
the ID) of each traffic stream with the letters L, R and T, for Left, right and through respectively.
This facility is useful when examining TRANSYT reports, as it will allow you to more easily track
the performance of each movement of each approach.
“Scope” / “Selected Objects”: When using this option, it is recommended that you specify a
“Prefix” in order to prevent duplicate names.
“Nearest Node/controller” In some cases the “nearest” item will be the item it is already
associated with, rather than the nearest one.

Page 496
25.1.1 Renaming Options:

“Use roundabout naming method”: When set, TRANSYT tries to identify loops in the network that
may represent a roundabout, and will base its naming on any such loops identified. This feature
does not work for all network layouts.
“Name arms based on direction”: When set, this option allows you name IDs based on their
physical direction using eight points of the compass.
For auditing purposes it can be useful to be able to record information about the current state of a
file when it is saved, and furthermore, to record the changes that have been made to the file over
time. TRANSYT offers an integrated facility that does this.
The Audit Trail facility is accessed via the main Audit Trail Window ((File>Audit Trail), which consists
of a horizontal toolbar and an event grid below that displays a single line for each recorded event
(see below).
Events fall into three categories:
 File status/comments
 File changes
 Save/run events
Each row of the event grid reports the date and time of each event, the event description, what
particular item it applies to and which user made the change. All recorded events are stored within
the TRANSYT data file.
How to record file changes and save/run events is explained in section 25.2.1. How to record File
status/comments is explained in section 25.2.2.

25.2.1 Recording file changes

To start recording changes to your TRANSYT file select the Log Everything option. When active this
item will turn red (as shown) and while it is active every file change that appears in the main
TRANSYT “UnDo” event list will be added automatically to the top of the Audit Trail grid. The logging
of ‘everything’ can be switched off and on whenever you like. Note how the switching on and off of
this facility is also recorded as an event. This ensures that any gaps where recording has been
stopped and restarted will be evident in the Audit Trail.
In addition to direct changes to the file, key actions taken by the user are also recorded and shown
with a grey background. These are events such as carrying out an evaluation or optimised run or
saving the file. These are recorded because they cause changes to important data in the file.
If you want new files to Log Everything by default, then please select File>Preferences, and then
under the General section set the option “Log Everything in Audit Trail for new files”.
25.2.2 Recording the File Status and Commenting

The toolbar Add Status & Comments option will reveal a new Window (see below) that allows you to
record a file status and to add any comments about the file at the same time. The User data field is
used to identify who is recording the status and comments. This is populated automatically from
your login name and PC ID, but can be changed before saving.
You can type anything you like into the File Status box, but for your convenience a dropdown list of
some commonly used descriptions is available (see below). Pressing Save will add the
status/comment as an event to the Audit Trail grid and close the File Status window. The
status/comment updates are shown with a blue background in the event grid.
If you want to be prompted to save a status/comment each time you save a file (excluding the
saving of Library Files), then you can tick the box “Prompt on each save”. Furthermore, to get all

Page 498
new files to prompt you each time you save them, then please select File>Preferences, and then
under the General section set the option “Prompt to save Audit Trail status for new files”.
It is sometimes useful to display only the status updates, especially if the event grid is particularly
long, therefore the toolbar option Show only status update is provided to filter out the file changes.
25.2.3 Customer Copy

It may be desirable or necessary to provide copies of TRANSYT files to clients. You may wish to give
your clients files with comments and file changes stripped out of the file, while at the same time
retain all your Audit Trail events within your file for future reference. You do this in TRANSYT using
the main menu option File > Create A Customer Copy.
When you chose to Create A Customer Copy you will be prompted to provide a file name and folder
location for the new customer file. The default is the existing file location and the file name with the
words “Customer Copy” appended to it.
This process is similar to an Export of a file, rather than a Save As function, in as far as
the file you are working on does not change.
25.2.4 Additional features

The toolbar Copy option can be used to copy either all of the events or just those you have selected
onto the Windows clipboard, ready to paste into some other application.
The toolbar Clear Events facility has three options - clear ALL events, clear up to a particular row, or
clear everything except the status/comments.
The headings of each of the columns of the event grid can be used to sort the list of events.
You may sometimes need to combine two networks, or fragments of networks, into a single
network. You may also want to save Library File ‘building blocks’ that represent small parts of
networks and then add these blocks into new networks. You can repeat this process as many times
as necessary, to cumulatively build up larger networks.
Use the File>Merge Network… option to accomplish this. The Library File selection dialogue will
open, from where you can either select a Library File, or browse and select the TRANSYT file that will
be merged with the current file. The screen shown below will then appear.

Usually, both the current network and the network being merged, will share various IDs such as
those associated with links, traffic streams, controller streams, e.g. both will probably contain a
Traffic Stream 1. Since IDs must be unique, a prefix/suffix mechanism is used to distinguish the
items in the network being merged from the existing items. In the screenshot, the letter N is
entered as the prefix for all items requiring a unique ID. When the Merge button is pressed, all the
items from the new network will be prefixed with an N, as long as this does not cause any other
errors. You can of course rename items once the merging process is complete. To use different
prefixes de-select the “Same for all” option.
By de-selecting the “Copy All” option you can also selectively merge the different components of a
file.
You can only merge other TRANSYT 15 files. To merge files created with older versions
of TRANSYT you will need to open these files, save them as TRANSYT 15 files and then carry out the
merge.
Use the 3x3 ‘location’ grid to tell TRANSYT where the merged network should be positioned relative
to the existing network. In the screenshot the right-hand button has been selected, so the new
network will be positioned to the East of the existing network.
You should check carefully the Task List after merging a network and will generally want to link up at
least one traffic stream or link from the original network to the new network.

Page 500
As an illustrative example, the screenshot below shows a left-right stagger Library file after being
merged with itself. In this example, the network runs successfully without requiring any changes
and gives a total Performance Index of exactly twice the value from the original network, as would
be expected.
Alternatively you can also use the “Add new… Junction” option in the network diagram to merge in a
file. This method works subtly differently – firstly you need to click where you want to place the
new item in the diagram and secondly you then need to select the file to merge. Otherwise, this
method works in the same way.
TRANSYT can model both drive-on-the-left (for UK, etc.) and drive-on-the-right (for continental
Europe, North America, etc.) situations. The driving side can be set simply by setting the Driving
Side data field in the File Description data section of the Data Outline. The driving side can be
changed at any time. Alternatively you can select File>Preferences and in the “Localisation” section,
adjust the option “Driving Side”, which will force all new files to a particular driving side.
Throughout TRANSYT, the terms nearside and offside are used in place of left and right wherever
possible, so no actual data changes occur when the driving side is changed, other than the
automatic arrangement of nodes, traffic streams and links in the network diagram.
When merging files TRANSYT checks to see if the file being merged has the same driving side as that
of the current file. If different, TRANSYT automatically “mirrors” the file as it is merged so that the
whole network is consistent. Additionally, there is the “Tools” option - “Mirror File (Swap driving
side)” that can be used to instantly mirror the currently displayed file.
Importantly, this means that the supplied sample and Library files, which are in drive-on-the-left
format, can be quickly switched over.

PLEASE REFER TO YOUR PRODUCT LICENCE AGREEMENT FOR DETAILS OF THE TERMS AND
CONDITIONS OF USE OF THIS PRODUCT. ANY UK/INTERNATIONAL RESTRICTIONS OF USE WILL
STILL APPLY. YOU MUST STILL BE LICENSED TO USE THIS PRODUCT IN THE COUNTRY IN WHICH IT
IS BEING USED.
There are a number of situations where you may want to run a series of files that you have
previously set up, such as those associated with different designs. If the networks are large the run
times can be significant. To cater for such situations, a (batch) facility to run multiple files is
provided via Main Menu > Tools.
1. Select “Run Multiple Files”

2. Click the “Select Files” button
3. Select a folder and the files within it that you wish to run, using the standard multi-file
selection facility.
4. Now press the “Run Files” button (The button will indicate the number of files you have
selected).
Each file will be opened one after the other, and run in the same manner as if the “Full Run for all
data sets” had been selected, i.e. existing optimisation options within the file will be used, and all
combinations of analysis and demand sets defined to run will be run.
For each file and associated set of data, a row of summary results will be displayed. The result items
that are shown can be edited using the “Result Items” menu items, either before or after running
the selected files.

Page 502
Please note that the summary results are not stored within TRANSYT - A “copy” button is provided
to allow you to conveniently copy the summary table if necessary.
By default, the original files will be left unchanged. However, if you wish to retain copies of the files
after they have been run, you can switch on “Save files after running” within the “Options” menu.
This will save copies of the newly run files in a sub-folder off the folder containing your selected
files.
(Tools>Collections>Find Shortest/Best Route) Use this tool to find the shortest route between two
links or two locations. Normally this operates by finding a route that minimises the total length
(trivially), but you may select any other data field and the tool will then find a route that minimises
this field. For example you can find a route between two links (or locations) that minimises
performance index, or journey time per PCU, and so on. Optionally you can then display the route in
the network diagram and save it in the file as a new TRANSYT Collection of items.

Traffic Behaviour Models (PDM/CTM) Page 503
For modelling of traffic behaviour within the network, you have the choice of using a macroscopic
model or the simulation model – This chapter describes in detail only the macroscopic models – for
details on the Simulation model see Chapter 23.
Having chosen to model your network macroscopically, you have four choices – You can use either the
platoon dispersion model (PDM); cell- transmission model (CTM); link-by link PDM; and for flared
approaches a “Flare” model. This last choice is not a single model, but an option that ensures that
TRANSYT will use the most appropriate model for the given situation – Either the CTM model or a
variation of the PDM model will be employed.
The PDM and CTM models can be applied to each individual traffic stream (or link) or across the whole
network. However the use of the Cell transmission Model (CTM) on entry traffic streams (and links)
offers no advantages and will slow down runs of TRANSYT so it is best to use PDM for entry traffic
streams and links.
For all three models the common cycle time is divided into a number of intervals called steps. These
are typically one second in length, but can be shorter. The program running time is related to the
number of steps – the more steps there are the longer it will take. For any cycle time, it is often
convenient to make the number of steps equal the cycle time, by setting the “Resolution” to 1. The
maximum resolution (number of steps per second) is five.
An alternative platoon dispersion model, previously used in the Santiago version of TRANSYT
(TRANSYT 8S), is selectable. For more information please see section 26.8
The following sections give details of the three model types, plus the triangular PDM option.
The PDM model is an adaptation of the original PDM model developed by TRL (as used in previous
versions of TRANSYT) that has been enhanced to include extra functionality, such as the ability to
model mutual opposition.
TRANSYT’s PDM calculations are made on the basis of the average values of traffic demand and
queues for each step of a typical cycle. The resultant histograms of traffic arrivals per step are termed
cyclic flow profiles.
26.1.1 Cyclic flow profiles

An example cyclic flow profile is Figure 26-1. Such profiles are useful in validating the model; after
running any file, you can see the cyclic flow profile for any link or traffic stream via the Graphs button
on the main vertical toolbar.

Page 504
In the TRANSYT traffic model, all of the calculations are carried out by manipulation of these profiles.
No representation of individual vehicles is made. In most calculations it is assumed that the profiles
are repeated during each cycle of the signal. In practice, the flow profile during any one cycle will vary
from the average, due to the random behaviour of individual vehicles. Direct calculations are made to
correct for this effect.
The operation of the traffic signals is represented by time points within the cycle when each stage
green period ends and the change to the next stage begins. These, combined with interstage
periods, start and end time lags, and appropriate start and end displacements allow ‘effective
greens’ to be determined when traffic on a link can actually flow through the junction.
40 units = 1 cycle
0 10 20 30 40
Time (seconds)
Figure 26-1 A traffic flow histogram
26.1.2 IN, OUT and GO profiles

To model traffic behaviour on individual links, TRANSYT uses cyclic flow profiles. There are three
main types of profile which make use of different combinations of arriving and departing traffic.
These are illustrated in Figure 26-2.
(i) the IN-profile is the pattern of traffic that would arrive at the stop line at the downstream
end of the link if the traffic were not impeded by the signals at that stop line;
(ii) the OUT-profile is the pattern of traffic that leaves a link;

(iii) the GO-profile is the pattern of traffic that would leave the stop line if there was enough
traffic to saturate the green.
(a) ‘IN’ PROFILE
(b) ‘OUT’ PROFILE

Page 506
(c) ‘GO’ PROFILE
Figure 26-2 Definition of IN, OUT and GO flow profiles
The traffic flowing into a link or traffic stream is obtained by taking the appropriate fraction of the
OUT-profiles from the upstreams. The profile of traffic entering a link will be displaced in time and
modified during the journey along the link due to the different speeds of the individual vehicles.
Thus, platoons of vehicles will be partly dispersed. The amount of dispersion is determined by
applying a form of exponential smoothing, related to the cruise time along the link, to the
incoming traffic. The platoon dispersal coefficient for normal traffic can be modified for individual
traffic streams (or links) (see section 26.1.4). The cruise time is the average un-delayed travel time
for vehicles flowing from the upstream stop line to the downstream stop line. Cruise times (or,
alternatively, cruise speeds) are specified separately for each inflow source. Figure 26-3 illustrates
the smoothing (dispersion) process.
You can specify in the Main (Common) Data screen (Outline: Network Options>Traffic Options)
whether you wish to use cruise times or cruise speeds. This determines which of these you will
need to specify in the Traffic Stream or Links Data screens.
The inclusion of a model of traffic dispersion means that TRANSYT automatically takes into account
the importance of having good progression on short links.
The calculations using the IN, GO and OUT profiles are carried out for each step of the cycle for each
network item (traffic stream and link repeatedly until a stable result is reached, starting with an
assumed queue of zero at the stop line. The pattern of queue growth and decay, and hence delays for
this stable situation, represents average traffic behaviour throughout the period being studied.

Figure 26-3 Example of measured and predicted dispersion on a link
26.1.3 Simplified traffic behaviour

By using the profiles as described, TRANSYT in effect simplifies traffic behaviour. Although individual
vehicles are not modelled, the technique used is equivalent to, and may be thought of in terms of, the
following description. Each vehicle is assumed to proceed un-delayed along a link until it reaches the
stop line at the end of the link. If the vehicle then meets a red signal or a queue which has not yet
discharged it is modelled as stopping instantaneously. Traffic queueing is assumed to take place
entirely at the stop line from where vehicles discharge during the effective green with instantaneous
acceleration up to cruise speed on the downstream link. This simplified behaviour is illustrated in
Figure 26-4 by the trajectory in time and distance of vehicle 1.

Page 508
Realistic trajectory
D1 = Effective green displacement
at start of green
TRANSYT trajectory
D2 = Effective green displacement
Undelayed vehicle trajectory at end of green
Time
D1 D2
Effective signals
Stop- as in TRANSYT
line
Red Green Red (Actual signals)
Red/Amber Amber
Delay for vehicle
Figure 26-4 Simplified traffic behaviour in TRANSYT
It will be seen that, despite these simplifications, delay (the amount of time by which a delayed vehicle
falls behind an un-delayed vehicle) is equal to the time spent in the TRANSYT queue. In this respect,
there are thus no errors in the estimation of traffic delay. The times in the cycle at which vehicles join
and leave the queue are, however, displaced.

26.1.4 The platoon dispersion coefficient

The platoon dispersion coefficient is a number, K, which modifies the smoothing factor F as
follows:
1
F=
Kt min
1+
100
Where the default value of tmin = 0.8 times the average cruise time (measured in steps).
The default value of K is 35, which various studies suggest is fairly typical. However, K is believed
to vary somewhat from site to site and from country to country, so occasionally, it may be
advisable to measure some cyclic flow profiles of traffic arriving at a signal to check that the default
value is not seriously unsuitable.
tmin is the minimum travel time along the traffic stream (or link). The normal traffic “travel time
coefficient” is a value that defines the value of t as a percentage of the average cruise time, so its
default value of 80% means that by default tmin is 0.8 of the average cruise time.
The values of t and K are in fact related, and each one can be derived from the other. Therefore
TRANSYT only needs and only allows the travel time coefficient to be specified directly.
NOTE: In the triangular PDM the expression for F and the value of the travel time coefficient are
different (see section 26.8).
For details of how TRANSYT deals with dispersion associated with different source types, e.g. buses
and trams see section 27.7.

Page 510
The cell transmission model (CTM) is a macroscopic traffic flow model developed by Daganzo (1994,
1995). It is based on the discretization of the classical hydrodynamic traffic flow model (Lighthill and
Whitham, 1955; and Richards, 1956). The CTM is offered as an alternative traffic flow model to the
platoon dispersion model.
The road network representation for the CTM is the same as that for the PDM, that is, the road
network being modelled is represented by nodes and links. In addition, the division of time into
steps in TRANSYT also applies to the CTM in the same way as to the PDM. However, the CTM is
discrete in space as well as in time. Thus, within the CTM, the road (or links) is divided into
homogeneous sections called cells. The lengths of cells on each link are different.
Like all macroscopic traffic models, the CTM describes traffic using variables of flows, speeds, and
densities (or occupancies equivalently). The traffic state on the network at a given time step is
represented by the cell occupancy. Traffic is transmitted from one cell to the next down the link
according the flow-density relationships, and the cell contents (occupancy) are updated at each time
step from the flows in and out of each cell.
Measures of the network performance such as stops, queues, and delays have the same definitions
as those in the PDM. They are also calculated using the same principle as that for the PDM.
However, Degree of Saturation does have a different definition - When using CTM degree of
saturation is based on available green time, i.e. lost time due to blocking is taken account of, unlike
the PDM model.
When using CTM, both a stop line saturation flow and a cell saturation Flow is required. The CTM
stop line saturation flow is specified as the standard “Saturation Flow”. The “Cell Saturation Flow” is
used as a link saturation flow. This additional value is required because this is the limitation on
traffic progression applied along the entire length of the link. If significant changes in saturation
flow exist along a link, these changes can be accommodated by introducing bottlenecks (non-
signalised non give-ways) along the link length. Usually TRANSYT’s provision to automatically set
each cell saturation flow to 1800 PCU/hr per lane will often be sufficient. For more help deciding
what cell saturation flows to use see section 19.3.
26.2.1 Link Flows and occupancies

The CTM calculations have two major components:
1) Calculation of the flows from one cell to the next, and
2) Updating of the cell occupancies from the calculated flows.
This process is repeated for all steps of the cycle time. For all intermediate cells (cells other than the
first and the last) on a link, the flows from one cell to the next depend on traffic presenting at the
upstream cell (i.e., occupancies), the road capacity crossing the two cells, and the spare road space
available at the downstream cell (i.e., the reminder of cell occupancies).

At each junction, the flows from the last cell of each incoming link to the first cell of each outgoing
link are calculated from the occupancies of the last cells of upstream links, and those of the first cells
of the downstream links, with relevant turning proportions applied, as well as the GO flows. These
flows are also subject to constraints on traffic merging and diverging at the node. This is where
potential blocking back is modelled.
Consider a junction at which there are flows from the final cell of each incoming link to the first cell
of each outgoing link. In the absence of congestion, any traffic from all incoming cells can be sent to
directly to the appropriate outgoing links. When traffic is congested because the first cell of one or
more outgoing links is partially occupied, the actual flow is calculated such that the first cells of
outgoing links receive only the amount of traffic they can hold. If the first cell of an outgoing link is
fully occupied, a blocking-back occurs. In this situation, none of any traffic is sent from its upstream
links.
The input parameters for each link in the CTM include the cruise speeds, the maximum flow (or the
saturation flow), the traffic flow wave speed, and the maximum occupancy (or the maximum
holding capacity). The cruise speed and the maximum flow are input parameters of TRANSYT. Both
the wave speed and the maximum occupancy are calculated within TRANSYT.
Cell 1 2 3 4 5 ... ...
Figure 26-5 Spatial representation of traffic on the road in the CTM
26.2.2 Shared links in the CTM

Shared links are modelled in CTM in very much the same way as in the PDM. The flows, queues and
delays are calculated for each of the shared links separately. Vehicles from each link are discharged
over the stop line according to their arrival time at the stop line, but at rates and times common to
all links sharing the stop line.

Page 512
However, there are some restrictions in the CTM for modelling shared links. In the CTM, each set of
shared links is treated as a single link representing one physical traffic stream / queue. This has the
following implications.
1) In the PDM, it is possible for traffic on shared links to have different cruise speeds. The CTM,
on the other hand, assumes that traffic on all links in the group of shared links have the same
cruise speed. An average cruise speed is used for all shared links for in a group of shared
links. As a result, it is not advisable to model very slow or fast traffic on shared links with
CTM. This includes mainly minor shared bus link with a bus stop, and minor shared links
carrying emergency vehicles
2) Each minor / major shared link can have its own separate upstream links. However, in
considering blocking back situations, shared links at one stop line are considered as a whole.
Suppose a downstream link has an upstream link which is a minor link. If the downstream
link is blocked, then no traffic from any of the set of shared links at upstream can move.
3) Each group of shared links is physically one link, and so must share the same upstream-end
node as well as the same downstream-end node or stop line. They must also be of the same
length. More generally, each link (or group of shared links) must head for a node where it
meets all the downstream link(s); a link must not have a downstream link sharing the same
downstream-end node. Similarly, each non-entry link (or group of shared links) must come
from a node where the upstream link(s) end; a link must not have an upstream link sharing
the same downstream-end node.
The restrictions to the network in item (3) in the above list, mean that some link-based network
modelling techniques cannot be used for the CTM. When the CTM is selected, TRANSYT will
perform a check on the network; any “non-standard” network scenarios identified will be reported
and it will be necessary to modify the network.
TRANSYT Shared links represent different traffic sub-streams on one link, i.e., either traffic of
different vehicle types, or traffic with different origins / destinations of travel. The use of the CTM
should be aimed at keeping track of different flows of traffic, especially in terms of their destination,
and modelling their behaviour at the end of the link. Modelling mixed traffic flows with different
cruise speeds is not a strength of the CTM.
26.2.3 Modelling flares (short bays) in the CTM

The recommended method of modelling flares is to represent the flared area using separate traffic
streams or links which are set to use a “Flare” Traffic Model. This option will automatically use the
most appropriate model for the circumstances. In some cases this will be CTM, i.e. where flares are
longer than can reliably modelled using the other blocking model - CPDM. How to model flares
(short bays) is fully described in chapter 17 - “Working with flared approaches”
26.2.4 Modelling give-way links in CTM

The CTM models traffic flow both in uncongested and congested situations. This has an implication
in the modelling of give-way traffic streams (or links). The standard TRANSYT give-way model

assumes that the maximum give-way flow or capacity F decreases linearly with the increase of flow
q on the controlling traffic stream (or link), with the interception F0 and slope A1. The relationship
may be written as F(q)=F0-A1q. As controlling flow increases gradually from zero to saturation flow
s, the give-way capacity decreases from maximum value of F0 to F(s)=F0-A1s. This model applies
only to the uncongested situation of traffic flow on the controlling traffic stream (or link). Note that
the minimum uncongested give-way capacity is either zero or F(s), whichever is larger.
In the congested situation for the controlling traffic stream (or link), at the onset of oversaturation
due to reducing downstream capacity, the flow starts to drop from the saturation flow. As the
controlling traffic stream (or link) becomes more and more congested, the flow decreases eventually
to zero. In TRANSYT (since version 13.1.2) the congested give-way situation is modelled in CTM by
extending the original TRANSYT give way model. It is assumed that there is a maximum congested
give-way capacity when the controlling traffic stream (or link) is over saturated, and that the give-
way capacity decreases linearly as controlling traffic stream (or link) flow decreases. Eventually both
controlling flow and the give-way capacity becomes zero when traffic is completely jammed. This
relationship may be written as F(q)=B1q, where B1 is the slope and is given by the ratio of maximum
congested give-way capacity over the corresponding controlling flow.
Thus, there are two linear relationships - one for uncongested situations and one for congested
situations. See Figure 26-6. The minimum uncongested give-way capacity can be conveniently
taken as the maximum congested give-way capacity. This is the default value for the minimum
uncongested give-way capacity.
Figure 26-6 Give-way capacity relationship

Page 514
Alternatively, if there is reason to believe that the maximum congested give-way capacity is
different from the minimum uncongested give-way capacity, then a different value may be entered.
The value for the maximum congested give-way capacity may vary from zero to 300 vehicles per
hour. For the model to work properly, the maximum congested give-way capacity should be larger
than, or equal to, the minimum uncongested give-way capacity. If this is not the case, then the user-
specified maximum congested give-way capacity will be ignored and the minimum uncongested
give-way capacity taken as the maximum congested give-way capacity instead.
The Congested Platoon Dispersion Model is adaptation of the standard PDM model (referred to in
TRANSYT as CPDM) which is used to model short flares. The adaptation has been worked out for
both the standard and the triangular PDM options. This model is a superior alternative to the ‘quick’
flare model.
It has the ability to model blocking effects where traffic on a particular traffic stream (or link) will fill
up with traffic preventing more traffic entering it and potentially blocking traffic entering other links
in the process, such as associated with short flares/bays. It is the feeding traffic streams (or links)
upstream of a short traffic stream (or link) that will experience the blocking effects. This in turn can
prevent traffic on these upstreams reaching other downstreams.
It is however, NOT designed or suitable for modelling the blocking of upstream junctions – To model
this effect you should use the CTM traffic model.
This particular model is not directly selectable within TRANSYT. It is only one of the two traffic
models that are capable of modelling blocking back from one traffic stream or link into another – the
other model being CTM. TRANSYT selects the most appropriate of the models for you.
Details of how to use this model are in section 4.12 and chapter 17.
The PDM and the CTM differ mainly in two aspects: platoon dispersion, and congestion effects. The
PDM models platoon dispersion. However, it employs the vertical queuing model which does not
model the spatial extent of queues. The CTM is just the opposite: it models congestion effects, but
not platoon dispersion in free-flow traffic. The main advantage of the CTM over vertical queuing
model is its explicit spatial representations of roadways. It is therefore able to build up an accurate
model of queues, not just in terms of numbers of vehicles in the queue, but also the spatial extent of
the queue. The model can be used to predict the evolution of traffic over time and space, including
transient phenomena such as build-up, propagation and dissipation of queues.
The PDM and the CTM emphasise different aspects of traffic flow behaviour; it is inappropriate to
assume that one mode is best suitable in all road and traffic situations. The PDM is appropriate to
long links and un-congested traffic, while the CTM is suited to short and congested links. The later

situation is typically found in city centres where the free-flow dispersion is not dominant and where
traffic is more likely to be restricted by downstream traffic and traffic signals.
Although the CTM is computationally more efficient than most other discretized macroscopic traffic
models, it is still computationally more demanding compared with spatially aggregate models, such
as the PDM. The runtime depends mainly on two factors:
1) Level of congestion, because it affects the amount of traffic to be "transmitted"
2) Size of network, in terms of numbers of links / nodes, and the length of links. This affects
they affect the number of cells traffic is “transmitted”.
How to select the models is described in chapter 19.
These two models differ in the same way as PDM and CTM differ (see section 26.4) except for the
modelling of the spatial extent of queue. CPDM traffic streams (or links) do have some spatial
awareness - TRANSYT has awareness of the availability of space for traffic upstream of a CPDM traffic
stream (or link) for traffic to flow into – i.e. CPDM traffic streams (or links) can block upstream traffic
streams (or links). This ability allows it to be used to model short bays (flares). The CPDM does not,
however have the ability to accurately model longer links, which the CTM model does have.
Furthermore, the minimum length of road-space which the CTM model can model is limited, whereas
the CPDM has no minimum. For these reasons the blocking of upstream junctions is best provided by
the CTM model and short flare blocking by CPDM – This is now automated within TRANSYT 15.
26.6.1 The limitation to a network

Currently there are certain restrictions on the use of the CTM. If any of these restrictions are
broken, either an error or warning will be shown in the Task List.
1) Minimum length of a traffic stream or link is equal to the distance travelled in one time step,
and is therefore determined from the Network Timings “Resolution” and the “Cruise
Speeds”, e.g. if the average cruise speed is 50 km/h and the resolution is set to 2 steps per
second then the minimum length will be 7 metres.
TRANSYT generates a warning message if the link length is significantly different to that used
internally by the CTM, based on the fastest cruise speed of any source of traffic entering the
traffic stream (or link).
2) Recommended maximum length of a link = 200 meters (A warning message produced.)

Page 516
3) Each group of shared links is physically one link, and so must share the same upstream-end
node as well as the same downstream-end node or stop line. They must also be of the same
length. (An error message produced.)
4) Each link (or group of shared links) must head for a node where it meets its downstream
link(s); a link must not have a downstream link sharing the same downstream-end node. (An
error message produced.)
5) Similarly, each non-entry link (or group of shared links) must come from a node where the
upstream link(s) end; a link must not have an upstream link sharing the same downstream-
end node. (An error message produced.)
26.6.2 TRANSYT 16 functionalities that CTM does not handle

CTM requires all traffic on a link share to move at the same speed over the same distance (i.e. must
have the same cruise time and cruise speed, hence the following restrictions:
1) Slow buses, i.e., buses with stops are not represented / modelled by the CTM; they are
treated as having the same speed as the traffic flow on the link
2) Emergency vehicles are not represented / modelled by the CTM; they are treated as having
the same speed as the traffic flow on the link
3) It is inappropriate to model trams by the CTM. If the CTM is selected and if there is a tram
link in the network, an error message is issued.
4) Time segment analysis with time-varying entry link flows is now supported by the CTM
The link-by-link model is a quicker variation of the standard PDM model that can be used when
model run times need to be as fast as possible, and still offer good results. The speed gains are
substantial – some optimised runs will be four or five times faster. The significant speed gains come
at a cost however - The link-by-link model cannot be used in conjunction with neither CTM nor
CPDM and hence cannot be used to model flares or blocking back effects.
We recommend considering the use of this model type for very large networks, and also to consider
its use early on in the modelling process, due to the need to model flared approaches using “quick
flares” which affect how the network is constructed.

In the standard platoon dispersion model, it is assumed that link travel times are distributed
according to a shifted geometric distribution. TRANSYT now offers the option of using an alternative
dispersion model based on a discrete symmetric triangular distribution of link travel times. This
model was developed at the University of Chile (Gibson and Wityk, 1988) and has been previously
implemented in TRANSYT 8S in Santiago.
These travel time distributions are different in two main features: shape and range of variation.
Regarding shape, in the geometric distribution the most likely value is the minimum travel time
while in the triangular one it is the average travel time. The range of variation, which depends
mainly on the difference between the maximum and the minimum travel times, is generally larger in
the geometric distribution than in the triangular distribution. Thus it is possible in the latter case to
have quite shorter ranges for link travel time: the region between 0 and cycle time is available here
but not in the geometric distribution.
Figure 26-7 shows an example of both link travel time distributions for a case where cycle time is 60
steps, mean travel time is 25 steps and the typical value for the normal traffic dispersion parameter
is used for each distribution. The abovementioned differences can be easily seen. It is to be noticed
that in the geometric distribution there are non-negligible probabilities up to a travel time of 79
steps but they are very low - less than one thousandth- from step 49 to 79. In fact, the link travel
time range for the triangular distribution is [16; 34] while for the geometric distribution it is [20; 79].
Figure 26-7 Example of link travel time distributions
The triangular PDM option is most suitable for networks where it is believed that actual link travel
times tend to be symmetrically distributed and/or have a range significantly smaller than the cycle
time. Also, as stopping and non-stopping buses have different travel time ranges the ability of the

Page 518
triangular PDM to manage such differences should prove useful in networks where there are high
bus flows.
NOTE: in the triangular PDM the same formula for F is applied to all link types (normal traffic, buses
and trams) while in the geometric PDM there is a different formula for bus/tram links (see section
25.7.1).
The average link travel time, t,̅ is supplied by you so it will have the same value whatever PDM
option is selected. In the triangular PDM the minimum link travel time T is also estimated in relation
to the average link travel time with the following expressions:
Normal Traffic 𝑇 = 𝐼𝑁𝑇[𝛽t̅ + 0.5], 0 ≤ 𝛽 ≤ 1,
Bus/Tram
Without a stop 𝑇 = 𝐼𝑁𝑇[𝛾1 t̅ + 0.5], 0 ≤ γ1 ≤ 1,
With a stop 𝑇 = 𝐼𝑁𝑇[𝜎𝑏 + 𝛾2 𝑟 + 0.5] , with b + r = 𝑡̅ and 0 ≤ γ2, σ ≤ 1

where:
INT is the integer function
b is mean stationary time at a bus/tram stop (steps)
r is mean cruise time (steps)
β, γ1 , γ2, σ are travel time coefficients.
The values of the travel time coefficients control the shape of the platoon and the range size: the
greater these values, the shorter the range. As the triangular distribution is quite flexible in this
respect it is advisable to pay attention to features that may justify the application of different sets of
coefficient values to some link classes. For instance, it is expected that in bus links with a stop there
will be more dispersion than in a link with only non-stopping buses.
Some experiments to calibrate the travel time coefficients have been conducted in Santiago, and
have produced the following values of travel time coefficients:
Normal traffic link

Travel time coefficient (β) = 0.65
Bus/tram link without a stop

Cruise time coefficient (γ1 ) = 0.60
Bus/tram link with a stop
a) Moderate to significant bus flows and efficient fare collection method and stop design
Stationary time coefficient (σ) = 0.60

b) Significant to high bus flows and low operating standards at stops
Stationary time coefficient (σ) =0.30.
The value of travel time coefficients may vary according to local conditions, not only in bus links with
a stop as shown.
The above recommended travel time coefficients for bus / tram links dependent on whether or not
the link has a stop. TRANSYT only allows you to enter one set of coefficients for bus / tram links at
the network level. However, you can modify the values of coefficients at the link level, to make use
of the above values of the parameters. Note: Such changes to the coefficients can be made quickly
and easily by using the right-click “Edit All” facility within a TRANSYT data grid.
The choice of platoon dispersion model can be made via the “First time Wizard”, which will appear
when you first run TRANSYT, by selecting the “Chile” option. This choice can also be made anytime
via the user preference (Main Menu > File > Preferences… > 2. Localisation > Use Triangular PDM
option and defaults). Once the user preference is set, any new or library file will have the
corresponding data item “Use Triangular PDM” selected. This can be found in the “Network options
> Traffic options” section of the Data Outline. Please note that this file option will be hidden unless
it is already selected in the file, or the “Use Triangular PDM and defaults” user preference is set to
true.
Network-wide dispersion coefficients can be set to use “defaults”. When the “Use Triangular PDM
and defaults” option is selected, the default dispersion coefficients will be alternative Chilean values
derived from Chilean experiments as shown below:

Page 520
Standard TRANSYT
(Geometric) PDM Triangular PDM
Traffic type Normal Normal
Travel time coefficient 80 65
Traffic type Bus Bus

Acceleration (ms-2) 0.94 1.00
Stationary time coefficient 30 60
Cruise time coefficient 85 70
Traffic type Tram Tram*

Acceleration (ms-2) 0.94 1.00
Stationary time coefficient 100 100
Cruise time coefficient 100 100
* Trams default to zero dispersion
The default value for the cruise time coefficient in bus links applies both to links with
and without a stop. If you want to set different values for each case or make any other kind of
differentiation, this can be done by taking advantage of the option that allows the specification of
dispersion coefficients separately for each stream or link. For details in this respect regarding bus
and tram links see section 27.7.3.
When switching from, or to the triangular PDM, the local dispersion travel/cruise time
coefficients (for individual traffic streams or links) will only change to use the relevant default values
if their dispersion type is set to use the “Network Default”, i.e. set to take their value from the
network-wide value.

TRANSYT Model Features in Detail Page 521
This chapter gives in more detail where needed of those features already mentioned in the
Modelling Basics (section) which described an overview of the TRANSYT traffic model.
In this chapter, where there are descriptions of how certain results are calculated, these
only refer to the standard models – not Simulation. Simulation uses its own appropriate techniques
to derive equivalent values of queue, delays, stops etc.
Full details are given in section 0
27.2.1 Queue length derivation

The queue length is derived from the IN, GO and OUT cyclic flow profiles during each step of the
typical cycle as described in chapter 4.7. The queue and delay model used in TRANSYT consists of
three components.
27.2.2 Uniform delay rate

For links on which traffic arrivals do not exceed capacity, the average queue corresponds to the rate at
which delay is incurred with an identical pattern of traffic arrivals during every cycle. This component
of the queue and delay model is called the “uniform delay rate”.
27.2.3 Oversaturation delay rate

On links where traffic arrivals exceed capacity, the traffic queue increases each cycle by the amount by
which arrivals exceed departures throughout the period of oversaturation. Thus, the uniform delay
during the typical cycle does not account for this additional delay due to the steady increase in
queues. In TRANSYT, the “oversaturation delay rate” is calculated as the average value of this
oversaturation queue during whatever period is being modelled (the “modelled time period”. Thus,
the queue is zero at the start of the modelled period and twice the average at the end.
You may prefer to use Simulation Mode to study oversaturation in your network, because it models
the whole modelled time period – not just an average single cycle. See Chapter 23
27.2.4 Random delay rate

A further element of delay not accounted for in the uniform delay calculation is that due to variations
in traffic arrivals from cycle to cycle. This is known as random delay. It may be conveniently thought

Page 522
of as the average number of PCUs that fail to discharge during the green time and hence form an
initial queue at the start of the following red period. On links where arrivals exceed departures, a
steadily increasing oversaturation queue will also be added to the average random queue to give the
queue at start of red.
Figure 27-1 illustrates, for a particular case, the way in which the three delay elements (uniform,
oversaturation and random) vary as the degree of saturation on a link increases.
stopline data:
60 saturation flow = 3600 pcu / hour
Cycle time = 90 seconds
Red time = 50 seconds
Duration of flow = 30 minutes
40
Oversaturation
delay
Random
delay
20
Uniform
delay
0
0 60 70 80 90 100 110
Degree of saturation (percentage of maximum discharge flow)
1000 1200 1400 1600 1800

Mean arrival flow rate (pcu/hour)
Figure 27-1 Traffic delay on a link

27.2.5 Delay calculation

TRANSYT calculates the sum of the oversaturated and random delay elements using one of two
possible formulae, the ‘simplified formula’ as used in TRANSYT since version 6, and the revised ‘less
simplified formula’ available optionally since TRANSYT 13:
The ‘simplified’ TRANSYT formula is as follows:

  
1/ 2


Random  oversaturation  T4 f  F    f  F pcu  hours / hour
2 4f

 T 

where f = the average arrival rate on the link (PCU/hour)
F = the maximum flow that can discharge from the link (PCU/hour)
T = the duration of the flow condition for which signal timings are being
considered (hours)
Where f and F are approximately equal, the random delay rate is extremely sensitive to small errors
in either of the flow values. For example in Figure 27-1 an increase in the degree of saturation from
95 to 100 per cent will increase random delay by some 80 per cent. This sensitivity is thought to
reflect actual traffic behaviour. In such conditions it is advisable to check the flow data being used.
Even so, there are practical limits to the data accuracy that can be achieved and the estimates of
random delay may be expected to differ significantly from actual values on links near to 100 per cent
saturation.
Whilst the estimates of random and oversaturation delays correspond approximately to true traffic
behaviour, they also serve to deter the signal optimiser from selecting green durations that have
little or no spare capacity. This is important, for example, where the green time on a side road
needs to be reduced to provide better co-ordination along a main arterial road; as side road green is
reduced, random-plus-oversaturation delay increases and should prevent the optimiser from
choosing unduly short green times.
A less simplified (and hence more accurate) random delay equation is used by default by all newly-
created TRANSYT files. The choice of random delay formula is selected in Network options>Traffic
Options>Advanced. However, the Random Delay Mode option, which is set by default to the
“Complex” formula can be reset to “Simplified (TRANSYT 12)” if there is a requirement for backwards
compatibility with older runs of TRANSYT.
The “Complex” formula is the recommended one – the simplified formula will tend to
overestimate the random component of delay, particularly for links that are well below capacity.
When comparing signalised solutions produced by TRANSYT with unsignalised solutions produced by
ARCADY, the complex formula will also produce answers that are more comparable.

Page 524
27.2.6 Comparing real and predicted queue lengths

Queue lengths are average values derived by the model from traffic counts taken (ideally) over a
number of days. Obviously traffic flows can vary from day-to-day and this will, in turn, lead to
variation in queue length from day-to-day. As a result, individual observations of queue lengths on
site on any one occasion may differ considerably from those predicted. Indeed, assuming that the
average flow used to model the junction was unbiased, predicted queues will be exceeded by
observed queues half the time. Therefore, if proper validation of the TRANSYT model is required,
the junction(s) operation will need to be observed on many occasions (at least 10) and the measured
queue lengths averaged. Only then could the queue lengths predicted by TRANSYT be compared
with those found on-site.
TRANSYT calculates the total rate at which vehicles are forced to stop on a link as the sum of
‘uniform’ and ‘random-plus-oversaturation’ stop rates. As for delay, the uniform component is
obtained from the cyclic flow profiles and the random-plus-oversaturation component is calculated
from simple equations.
27.3.1 Uniform and fractional stops

All traffic which suffers uniform delay contributes to the uniform stop rate but traffic delayed by only a
few seconds will, in reality, merely slow down and not make a complete stop. Consequently, a
correction in TRANSYT includes a fractional stop for short delays; the fraction depends on the length of
the delay.
Cruise speeds on individual links are accounted for and the fractional stop is calculated according to
the estimated proportional loss of kinetic energy. Fractional stops, for traffic experiencing short
delays, and full stops, for traffic which is delayed sufficiently to come to a halt, are accumulated as
‘equivalent full stops’ to provide the uniform stop rate component for the link. Figure 27-2 shows the
way in which full and fractional stops are valued for inclusion in the Performance Index relative to a
standard full-stop from a cruise speed of 12m/sec (43km/h).
An estimate is made of the additional stops caused by random variations in traffic arrivals from cycle
to cycle and also caused by steadily increasing oversaturation queues on links where average arrivals
exceed capacity.

Figure 27-2 Valuation of full and fractional stops

from various cruise speeds
As discussed in section 27.2 the random-plus-oversaturation delay rate may be visualised as the
average number of PCUs in the queue at the start of the red period. On the assumption that all such
vehicles stop each time the signals become red, then the average number of stops per vehicle can
be estimated by dividing the average start-of-red queue by the average number of vehicles which
discharge from the link during each green. This quotient is the average number of red periods which
each vehicle must wait before crossing the stop line and thus equals the average number of
‘random-plus-oversaturation stops’ per vehicle.
On links where traffic arrivals exceed or are near to capacity, long queues will form and the average
number of stops per vehicle will be large. There is some evidence that, in such circumstances,
drivers well back from the stop line will move forward at only low speeds (10-15 km/h) when it is
obvious that they will have to stop again. Hence, an arbitrary upper limit of 2 random-plus-
oversaturation stops per vehicle is imposed to avoid unrealistically large estimates of the kinetic
energy wasted by stops in long queues. As this upper limit is approached, the number of stops per
vehicle is discounted to avoid discontinuities in the relationship between stops and the random-
plus-oversaturation delay. The random-plus-oversaturation stop rate is then calculated as the
product of flow on the link (Veh/hour) and the discounted average stops per vehicle.

Page 526
Wasted green time is a measure of the amount of green time presented to a link which is unused,
i.e. the total time in which no traffic flows over the stop line during green. This time is made up of
two components – “blocking back time” and “starvation time”. “Blocking back time” (or “spill back
time”) is the green time during which traffic on a chosen link is prevented from using the green due
to the blocking effect caused by traffic queues reaching back from a downstream link, to which
traffic on the chosen link is trying to progress to.
“Blocking back time” includes ALL of the time during which the downstream link is blocked during
effective green upstream AND traffic is trying to use that green, i.e. it includes periods of time even
when the inflow rate of the upstream link is zero, but only if there is a queue.
“Starvation time” is the amount of effective green in which the inflow rate is zero AND no queue
exists, i.e. the green time given to the link is unused by traffic. This might be due to poor
coordination or simply due to excess green time being provided. In the case of the platoon
dispersion model (PDM) it is the same as when there is zero outflow during effective green.
Both values are provided as part of TRANSYT’s detailed results. The overall wasted green time, due
to either effect being present, is also provided.
Blocking back time is a reasonably reliable result when all the downstreams are either
CTM or CPDM links. However, PDM downstream links have no blocking awareness and hence only a
rough estimate, based on mean maximum queue and max queue storage values, can be calculated.
A simple output flag indicates when an estimated blocking back time is being reported.
27.4.1 Calculation accuracy

The way the “blocking back time” is calculated depends on the traffic model used. The CTM (cell-
transmission model) can more easily identify when blocking occurs and will generally give more
accurate “wasted green” results than the PDM (platoon dispersion model).
When the PDM model is being used the program estimates the amount of blocking back during
effective green using a combination of the mean maximum queues, downstream queue lengths, and
the user-defined link “Maximum Queue Storage” value (see section 28.6.2). If the optional
“maximum queue storage” is provided by you, it is used, otherwise a TRANSYT estimate of this value
is used instead. The accuracy of the wasted green times will be improved wherever you set your
own maximum queue storage value.

Linear relationships between give-way capacity flow (F) and various controlling flows have been
observed for UK conditions at priority type T-junctions and for roundabouts, as reported in SR 582
(Kimber & Coombe, 1980) and LR 942 (Kimber, 1980). The coefficients in the linear relationships are
dependent on a number of site-specific quantities and anyone who wishes to model roundabouts can
either use the built-in ARCADY and PICADY models within TRANSYT (subject to having a licence to use
ARCADY and PICADY) or use TRL’s separate ARCADY and PICADY software products.
The ARCADY and PICADY products are specialised tools recommended for the evaluation
and modelling of isolated unsignalised roundabouts and priority junctions. Both ARCADY and PICADY’s
capabilities extend well beyond that of the original two research reports, having been added to over
many years. They are easier to use than TRANSYT and offer a comprehensive set of design, modelling
and evaluation capabilities some of which are beyond that of TRANSYT, e.g. queue variability, accident
prediction. However, within the context of a network, particularly a signalised one, the modelling of
give-ways and roundabouts is best done within TRANSYT, due to the existence of the determinable
traffic patterns within the network which can significantly affect junction performance.
At priority junctions a traffic stream that has right of way is considered to suffer no delay. It is
referred to as a controlling traffic stream or link. The rate at which traffic can enter from a minor
road that gives way depends on the controlling link flow which, in general, varies from step to step
during the cycle. TRANSYT calculates, during each time step, the maximum flow which can leave the
give-way traffic stream (or link) as a function of the flow on one or more controlling links. This
calculation produces the GO-profile for the give-way link. This profile is then used in the same
manner as that for a signal-controlled link to obtain delays, stops, and an OUT-profile.
The same basic facility can be used to represent traffic on a traffic stream or link which, although
signal-controlled, must also give way to an opposing flow. Such situations occur frequently at
signalled junctions where offside traffic turns without a separate signal indication (see section
18.14).
Give-way junctions (priority intersections) that have their performance affected by the presence of
nearby upstream signal controlled junctions, (due to give-way drivers’ knowledge of the signal
states, are also catered for within the give-way model. See section 18.16 on Indirect traffic control.

Page 528
1000
q
FR 2
Major road q
1 FL
800
q =q
1 2
600 FL= 715 - 0.22q 1
Minor road
400
200
FR= 600 - 0.22q1 - 0.19q 2

0
0 500 1000 1500 2000 2500 3000 3500 4000
Major road controlling link flows, q 1, q 2(pcu/h)
Figure 27-3 Give-way capacity relationships for a typical junction
Figure 27-3 shows two examples of typical linear relationships between major (controlling) and
minor (give-way) traffic flows. Figure 27-4 gives the ‘most basic’ TRANSYT representation of a
T-junction that is controlled by a priority rule. The junction can be represented as a traffic stream
(or link) with an unrestricted flow or as a ‘bottleneck’ both of which will give a continuous green for
main road traffic, thereby providing the necessary cyclic flow profiles to control minor road
‘give-way’ links.
Please note that when using the CTM traffic model, congested give-way situations can also be taken
account of. See section 26.2.4 for full details.
27.5.1 Parameters controlling the give-way model

Give-way traffic streams (or links) are specified in the same general way as signal-controlled ones
within TRANSYT, but with the addition of those parameters which determine their GO-profile.

Signalled node Signalled node
'Give-way' links for minor-road traffic,

controlled by major-road flow emerging
from the 'bottleneck'.
Figure 27-4 Basic representation of a give-way junction in TRANSYT
References to ‘links’ here, can also be interpreted as a TRANSYT ‘movement’ of traffic.
One controlling link:
It is assumed in TRANSYT that the maximum flow (F) from a give-way link through a flow (q) on a
single controlling (priority) link is given by the linear relationship:
F = F0 - A1q
where F0 is the maximum flow from the give-way link when the controlling flow is zero; A1 is a
constant. The user must specify F0 and A1.
Two controlling links:
In this case, the linear relationship is of the form:
F = F0 - A1q1 - A2q2
There are two possibilities here for minor road traffic:
(i) all of the traffic gives way to both of the controlling movements; e.g. a lane of right turners
across a two way road,

Page 530
(ii) some of the traffic gives way to only one of the controlling links and some of the traffic gives
way to both of the controlling links; e.g. where there is a lane of mixed left and right turners.
Thus, to cater for the various possible situations, it is necessary to specify the F0, A1, A2 values, and also
define the TRANSYT link or lane structure to model to take account of the fact that some of the mixed
traffic is opposed by one movement and some by two. Details of how to set up the various
movements and conflicts is described in chapter 18.6.
When a give-way is controlled by more than one controlling traffic movements, these movements can
be either signalised or unsignalised - The TRANSYT model allows mixed types of opposing traffic
streams movements or links as well as allowing many more conflicts to be defined.
Three or more controlling links:
In reality the number of controlling (conflicting) links can be considerable, remembering that traffic
movements that do not even cross the path of each other will still influence each other at give-ways.
Although you can chose to set these up manually, the Priority objects in TRANSYT, will automatically
create the required give-way conflicts for you, based on the priority object data, so it will model give-
ways in a more comprehensive manner.
27.5.2 Choice of give-way parameters

For T-junctions, a simplified treatment is given below, but a fully specified model (such as that provide
by the Priority Object Model) should be used if the priority junction is a critical element of the
network.
Consider a give-way link on which the traffic is queueing in a single lane and must give way to traffic
approaching from only one direction as, for example,
left turners from the minor road in Figure 27-3.
Typical (not default) coefficients in this case are:
F0 = 715 PCU/h
A1 = 0.22
These values are related to the following situation: give-way traffic is queueing in a lane of width w
= 3.65m (averaged over the last 20m of the approach), visibility for this give-way traffic is V = 80m
towards the controlling flow, and the width of the roadway occupied by the controlling flow is W1
= 4.5m.
F0 changes by about +10 per cent per metre increase or decrease in w, and by about +1 per cent
per 10 metres increase or decrease in V. The slope (A1) varies similarly with w and V but also
varies inversely by about -10 per cent per metre change in W1.

Now, consider a give-way link on which the traffic is queueing in a single lane and must give way to
traffic flows approaching from two separate directions. An example of this is the right-turning
stream from the minor road in Figure 27-3. The give-way capacity is determined by the flows (q1
and q2) on the two controlling links as follows:
F = F0 - A1q1 - A2q2
with typical (not default) coefficients being;
F0 = 600, A1 = 0.22, A2 = 0.19
These values relate to site characteristics w and V as described above: w = 3.65m and V = 80m.
They also relate to the total main road width (W2) occupied by both controlling flows, where W2 =
9m. Coefficients F0, A1 and A2 vary by +10 per cent per +1m in w, and by +1 per cent per +10m in
V. The slopes (A1 and A2) also vary inversely by about +5 per cent per +1m in W2.
The above relationships apply only where give-way traffic forms one queue. Sometimes, however,
traffic on a give-way link will form two or more separate queues in adjacent lanes, each lane giving
way to the same controlling links. The coefficients F0, A1, A2 should then be estimated for each
lane individually and the overall link coefficient for use in TRANSYT obtained by adding together
the two or more corresponding lane coefficients. For example:
F0(total) = F0(Lane 1) + F0(Lane 2) etc, and similarly for A1, A2.
Sometimes give-way traffic in a single lane contains some vehicles which must give way to only one
controlling link flow and other vehicles which must give way to two such flows, as, for example, a
mixed give-way stream of left and right turn vehicles rather than separate turning streams as in Figure
27-3. You can allow for this in TRANSYT by modelling the mixed traffic using two separate shared links
which allows the correct give-way coefficients to be applied to each shared link (hence movement)
separately. This is the recommend method of modelling this situation.
Alternatively (using a retained functionality from earlier TRANSYTs), the proportion of give-way traffic
which gives way to only the first controlling link flow can be specified ; the remaining proportion of the
traffic is assumed to give way to both controlling link flows.
In both cases, TRANSYT automatically calculates the combined-manoeuvre capacity as the weighted
harmonic mean of the individual manoeuvre capacities.
The most recent versions of PICADY provides slope and intercept values as part of its
report. Flow-weighted averages of these values can be used as required in TRANSYT or elsewhere.

Page 532
27.5.3 Vehicle In Service and Random Parameter

These two parameters define the assumptions made by the traffic model of how traffic arrives and
queues at give-ways and stop lines. Full details of these two important modelling parameters are in
section 19.2.
Normally no distinction is made in TRANSYT between the various types of vehicles on a link. A facility
known as a ‘shared stop line’ allows vehicle types to be distinguished within a common queue.
This facility was initially developed for use in ‘BUS TRANSYT’ (see section 27.7). The facility has
subsequently proved suitable for other purposes such as the production of timings for signalised
roundabouts.
The shared stop line facility allows up to seven separate classes of vehicles to be represented in any
one queueing situation where, in reality, the classes of vehicles are mixed together. The classes need
not be different types of vehicles but may consist of vehicles which, for example, entered from
different roads at the upstream intersection. There may also be separate classes for buses or trams
that follow particular routes and service different bus/tram stops. You must decide how many classes
of vehicles are necessary to represent the conditions being studied. Each class of vehicle at a common
stop line is represented by a separate link. For vehicles in a given class at the shared stop line,
TRANSYT calculates the delay for that class taking into account delay caused by the interaction
between all vehicles using the shared stop line. The number of stops is also calculated. The procedure
is as follows:
a) For each class of vehicle, the average arrival flow profiles (IN-profiles) are calculated
separately.
b) Vehicles from each class are discharged over the stop line at rates and times common to all
links sharing the stop line. Saturation flow across the stop line is divided between the
different classes of vehicles according to their arrival time at the stop line. This means that
the order in which the vehicles in the different classes join the queue is preserved. A
separate OUT-profile is calculated for each class of vehicles.
c) The rate at which uniform delay is incurred by each class of vehicle is calculated from the
average queue on the link in the normal way. The random-plus-oversaturation delay rate is
calculated initially as a total for all traffic sharing the stop line and is then apportioned to
each class in proportion to the flow in the class.
27.6.1 Shared link stop line specification

Links forming a shared stop line group are defined as one ‘master’ or ‘main’ link and up to six other
‘minor’ links. The grouping of these is done in the Links Data Screen (Outline: Links>Link n>Is
Minor Shared Link?). See Figure 27-5. The definition of which link in a group is the master is

arbitrary, and does not affect the calculations of queues, delays, etc. It does have some effect on
the output listing; this differing slightly between the master and minor links in a group.
Figure 27-5 Specifying a Link as a minor shared link
27.6.2 Shared link give-ways

In the same way as for shared stop lines it is possible to group links which share a give-way. These are
defined as a ‘master’ or ‘main’ give-way link and other ‘subsidiary’ give-way links. The grouping of
these is done in Shared Stoplines Data (see Links > Link n) exactly as for shared stop lines. It is not
necessary to complete any of the Give-way specific data, e.g. controlling link numbers, A1/A2
coefficients, maximum flow etc. for minor give-way links as the information is taken from the Give
Way Data for the major give-way link. The Percentage opposed or percentage opposed by one link
only on the master link refers to the percentage of total flow on all the shared links combined.
27.6.3 How shared links relate to traffic streams

Traffic Streams make use of a hidden structure of shared links in order to keep traffic on each OD
path separated, but still sharing the same road space. Hence, if you were to compare a link network
with a traffic stream network, a link share will generally become a single traffic stream (with one or
more lanes) and non-shared links will become separate traffic streams.

Page 534
There are strong arguments for optimising network timings in terms of the movement of people
rather than of vehicles. On this basis buses or trams would be given some degree of priority over
normal traffic. Of course, the advantages to bus/tram passengers would be partly offset by dis-
benefits to other vehicles.
The effect of representing buses or trams separately from other traffic can be illustrated by an
example. Figure 27-6 is a time distance diagram showing a one-way progression between two signals
which are assumed to operate on a common fixed-time cycle.
Time
Bus
Distance
SIGNAL 1
Green Red
One-way Bus stop

progression
SIGNAL 2
Red Green
Bus
A platoon
of traffic
Figure 27-6 A time-distance diagram showing the different typical movements of a

platoon of traffic and a bus

The movement of a platoon of traffic is represented by the dotted band and a bus is shown crossing
signal 1 in the centre of the platoon. The cruise speed of the bus is less than the average platoon
speed. There is a bus stop between the signals. As a result of stopping, the bus arrives at signal 2 after
the main platoon. If the bus behaviour is not represented, the green period of signal 2 would be
optimised to give unimpeded progression to the platoon of other traffic and the bus would be delayed
by the red period. In Figure 27-6, the green period is offset to reduce the delay to the bus even
though the platoon of other traffic then suffers some delay.
27.7.1 The BUS TRANSYT model

In real traffic situations, the interactions between buses and other traffic are more complex than in
this simple example. For this reason, bus behaviour is modelled in TRANSYT using either traffic
streams or the shared stop line facility, together with a special ‘bus dispersion’ formula. This is used
for both link and traffic stream network representations – the difference being that the underlying link
structure is hidden in the latter case.
The dispersion formula takes account of the variation in the journey times of buses along a link. Bus
journey times vary due to differences in their cruise speeds and in the time spent at bus stops. The
formula is a modified version of that for general traffic dispersion. For buses, the smoothing factor is
given by:
1
F
1  70100
b 15r
where r = mean cruise time (measured in steps)
b= mean stationary time at a bus stop (steps)
“Dispersion coefficient 1” = 70 (default) for bus stationary time
“Dispersion coefficient 2” = 15 (default) for bus cruise time
“Stationary Time coefficient” = 100 – “Dispersion coefficient 1”, hence = 30 (default)
“Cruise time coefficient” = 100 - “Dispersion coefficient 2”, hence = 85 (default)
the formula for F and the default dispersion coefficients are different for the triangular
PDM (see section 26.8).
Once delays and stops have been calculated separately for buses and for other (normal) traffic, by
using the shared stop line facility or traffic streams, total passenger delay can be estimated by
weighting the results for each class by using either link weighting factors (see section 28.1.3) or

Page 536
special traffic stream weighting factors which are applied to either all traffic or to individual OD Paths
on each traffic stream (see section 28.1.3.1). Weightings can be applied proportional to an assumed
number of passengers. The optimising routine will then attempt to find signal settings which minimise
total passenger delay.
This method of optimising specifically to take account of the different behaviour of buses within the
network and their value in terms of passenger numbers, is likely to be most effective where bus flow
rates are relatively high (more than 10 to 20 buses per hour) and the average time spent at bus stops
is considerably less than the cycle time of the signals. When the method was tested in Glasgow by
TRL, it produced bus journey times which were, on average, 8 per cent less than those measured with
signals co-ordinated to minimise delay to vehicles rather than people. The dis-benefits to other
vehicles were too small to be measured reliably.
27.7.2 The TRAM TRANSYT model

Currently there is no specific model for trams – the existing bus model is copied, so the same
parameter types that affect behaviour within the model are assumed. In order to accommodate, as
far as possible, the differences between buses and trams or simply specific types of buses, the
existing bus model parameters and tram model parameters can be specified separately.
If you wish to model a different vehicle type, such as bicycles, then you can use the TRAM network
to model these instead of trams. You should set the dispersion coefficients to ones appropriate for
modelling cyclists, and change the Bus Parameter “Name” to “Tram” to make it clear what particular
traffic type you are now modelling.
27.7.3 Bus/Tram model coefficients

The bus and tram sets of coefficients are stored separately and can therefore be changed
independently (Outline: Network Options > Traffic Options > Advanced > Bus/Tram
Parameters).
Because the dispersion coefficients can be derived easily from the travel time coefficients,
TRANSYT only allows the two travel time coefficients to be specified directly - The bus and tram
dispersion coefficients are hidden entirely in TRANSYT. The required coefficients are as follows:
Acceleration (ms-2) (which is the assumed acceleration of the vehicle moving off from rest)
Stationary time coefficient
Cruise time coefficient
Individual traffic streams and links can use their own individual dispersion settings, for all
traffic types (except for pedestrian crossings).
To specify zero dispersion for buses or trams, both the cruise time coefficient and stationary
time coefficient should be set to 100. This can be selected by changing the “Dispersion type”
to “None” either at the network wide level (Outline: Network Options > Traffic Options > Bus
Parameters or …> Tram Parameters) or on individual traffic streams or links (Outline: Traffic

Stream x > Bus/Tram > Advanced). Note that the local dispersion type will by default be set to
“NetworkDefault”, hence the local values will use the network-wide values by default.
Figure 27-7 Network-wide bus parameters
Further details relating to bus dispersion are given in TRL Laboratory Report LR666.
27.7.4 Defining what traffic types can use each part of the network
While traffic streams and “Link shares” allows you to separate classes of vehicles which are part of
the same queueing situation, the Traffic Type (Outline: Links > link n, or Traffic Streams > traffic
stream n) allows you to define what category of traffic is using these links or traffic streams (see
Figure 27-8)

Page 538
Figure 27-8 Traffic Types
There are currently three traffic types – Normal (traffic), Bus and Tram. The default ‘Normal’ is the
name given to a link which is assumed will not be modelling buses or trams.
Traffic streams can be set to contain any combination of traffic types. In TRANSYT 15 links can only
contain one traffic type. Previous versions of TRANSYT did allow ‘mixed’ links – Please see section
27.7.4.3 on what happens to imported files that have ‘mixed’ links.
In place of the normal cruise speed / cruise time entry for the “Source” data of normal links and traffic
streams, the model requires for the representation of buses, the following information:
The average free-running speed (of buses/trams) in km/h (range 15 to 100)
The average time stationary at bus/tram stops in seconds (range 00 to 99)
Specifying these parameters differs depending on whether or a link or traffic stream network
structure is being used – These differences are described in sections 27.7.4.2 and 27.7.4.1.
27.7.4.1 Specifying bus data for traffic streams
The average Bus free-running speed is defined for each source of the traffic stream (Outline:
Traffic Stream Data > Sources > Source n).

The average time stationary at bus/tram stops is defined within the traffic stream data under
whichever traffic type it is, i.e. Bus and/or Tram (Outline: Traffic Streams > Traffic Stream n >
Buses/Trams).
Figure 27-9 Traffic Stream Source Data
A traffic stream containing any bus flow is identified as a bus traffic stream by the program
and all such traffic streams are marked on the output with ‘B’, and are separately totalled.
Mixed traffic is allowed, as the different traffic types are still kept separated within the
internal model. The same applies to trams.
For convenience, traffic flows for each traffic type are shown, e.g. Source Normal Flow, Bus
Flow and Tram Flow. These are read-only ‘resultant’ values since they are derived from the
OD Matrix used to define the traffic flows.
The separate modelling of buses that stop and those that don’t can easily be
accommodated, since most of the time they will be on different TRANSYT paths. If buses on
the exact same path have, say, 10 percent or more that don’t stop while the rest do it may be
advisable to add an extra path manually so that one path can represent stopping buses and
the other non-stopping buses.
27.7.4.2 Specifying bus data for links
The average free-running speed and average time stationary at bus/tram stops are set in the Link
Data (Outline: Links > Link n > Source n)

Page 540
Bus links are marked in the output with “B”, and are separately totalled. The same applies to
trams, with the output marked with a ‘T’. Imported pedestrians links are marked with a ‘P’.
Figure 27-10 Link Source Types

If the proportion of buses that do not stop at a scheduled stop exceeds, say, 10 per cent then
it may be advisable (see SR 266, Peirce and Wood, 1977) to represent the bus stream by two
parallel links - one carrying stopping buses and the other carrying non-stopping buses.
27.7.4.3 Importing files with ‘mixed’ traffic type links
Traditionally the traffic type of a link was defined by what traffic entered it from its upstream
sources, rather than defining the link itself. This method allowed some links to be fed by more
than one traffic type – e.g. buses and normal traffic. This is no longer permitted for new files
in TRANSYT 15.
However, existing files that are imported will retain this method of defining link types. The
Link “Traffic Type” will be set to “By Source” (see Figure 27-11). If this value is changed to a
different setting, e.g. “Normal”, “Bus” or “Tram” it cannot then be reset back to “By Source”
as this option will have been removed.
If ALL sources for a link are BUSES or TRAMS, then the Dispersal Type for the link is best set
to DEFAULT simply to avoid any confusion over what dispersion is being modelled. The Car
Dispersal Coefficient will then appear as 35 but will be ignored by TRANSYT because it only
applies to normal traffic.

Figure 27-11 Link Traffic Type “By Source”
If the sources of a link are of different types, then the GUI will show a warning to ensure that
you are aware of this mixed traffic.
27.7.5 Modelling bus lanes and bus set-backs

Buses can be modelled on a bus lane by use of a separate traffic stream. Simply specify
the traffic stream “traffic type” as bus, set the bus stopped time and (bus) average cruise
speed. The flow is just the buses flowing along that bus lane.
Bus set-backs are commonly found in traffic networks, as they are needed wherever a
nearside turning movement is required for non-bus traffic, assuming that the bus lane is
adjacent to the kerbside. The diagram below shows the general setup of a bus set-back.
Set Back
Bus Lane
Figure 27-12 A typical bus setback

Page 542
A bus set-back looks like a flared approach to non-bus traffic and can be modelled as such.
The average utilisation of the ‘bay’ needs to be estimated. Buses will start off later as a
result of having to wait for any traffic in front to discharge. This can be modelled with an
increased “relative start displacement” for the bus phase, which will be approximately 2
seconds per vehicle that queues in front of the bus on average. N.B. this will necessitate
the creating of an extra phase for the buses in order to be able to apply the “relative start
displacement”.
(If using a link structure, buses can be modelled on a bus lane by use of a non-shared bus
link (instead of a traffic stream) with traffic type set to “Bus”.)
TRANSYT allows the specification of ‘Collections’. A ‘collection’ is user-defined subset of the traffic
streams, links, controller streams and pedestrian crossings within a network, so can also be used as
a tagging system, allowing you to disaggregate the results. Although a very simple concept, they are
a very powerful and useful tool.
You can, if you wish, create collections of traffic streams (or links) that are consistent with a route
through the network, and some tools within TRANSYT also generate collections for you that are
essentially ‘routes’ through the network.
Figure 27-13 Collection Data

27.8.1 Why use Collections?

Collections have a number of uses/benefits. Some of these are listed below:
1. They allow specific parts of a network to be individually identified, or categorised.
2. Groups of traffic streams, links, pedestrian crossings and controller streams can be identified
graphically within the network diagram or filtered using the data grids.
3. Allows you to define all the network items associated with a particular junction.
4. Allow specific parts of a network to be associated with a specific feature, e.g. bus route,
congestion charge zone, controlled parking zone, etc.
5. For each collection, a very similar set of collated results as are calculated for the whole
network, is presented
6. To provide aggregated results for each individual traffic node, controller stream, or individual
junction
7. Allows the storing of collections that can define valid routes through the network, and hence
offers the only method of storing Time Distance Diagrams in the file.
8. Provides route journey times across multiple local OD matrices.
27.8.2 How to define your collections?

Collections consist of an ID, name, description and a list of existing items within the network.
They can be specified in three ways:
1. Using the data editor (Outline: TRANSYT Network > Collections): A number of options are
provided to make it easier to define the network items you want in your collection, as shown
in the “Resultant Items” list. These are:
(a) “Include associated controller streams”: When this option is selected the
collection will store which controllers are controlling the items currently within
the collection. N.B. Since TRANSYT 16, the controllers are part of the collection,
but also used to help define the collection of traffic streams and links.
(b) You can manually add traffic nodes to the list of items that help define the
collection. Traffic Nodes have no associated outputs, so they do not form part of
the collection.
(c) “Include associated items”: When this option is selected the “Resultant items” list
will be populated with all the traffic streams and links identified as being

Page 544
associated with the resultant controller streams or traffic nodes (to help define
the collection).
2. Using the combination of ‘multiple-selection’ in the network diagram and the right-click
menu options ”Add to new Collection” and ”Add to existing Collection”
3. Using the main menu option Tools > Collections > Store new collection from currently selected
items.
4. The menu item Tools>Collections>Calculate all routes in network, which will replace all
existing routes. Note that the term ‘route’ is used here to refer to the fact that the
collections generated are in fact routes through the network. TRANSYT identifies and reports
which collections form a ‘route’ using the “Is Route” flag.
Up to fifty collections can be specified, and a name assigned to each one. The name helps to
identify the particular collection. You can add a list of road names, a description of the start and end
points, the number of the bus using that collection for example. The description can also be left
blank.
The collections do not have to make any logical sense as they can be any combination of
network items, e.g. traffic streams and links do not have to be contiguous, i.e. they don’t have to be
‘routes’. Items can also appear in more than one route, but duplicates in a collection will be
automatically removed. The defining of collections has no effect on the calculations – only on how
the results are collated.
For details of how to find the shortest route between two links or locations/traffic streams see
Section 25.5.
27.8.3 Collection Results

How much of the collection results are shown is controlled from within the collection data and the
report configurator. In each collection there are two options as follows:
Tick “Show aggregate results in reports” if you want the results for a particular collection to appear
in reports.
Tick “Show individual results in reports” if you want individual results for each item in the collection
to appear in reports.
The selected collections results are then presented throughout the report depending on contents
selected in the report configurator.
To display Collection results within the Report, you need to switch on the items within the
“Collections” section of the report configurator. You can choose to either show just the collections,
or set the “Show individual results for non-collection items” option as well. When ticked, the report
will show, the results for all the non-collection items, for each of the selected individual tables (see
below).

The following screen-shot shows how the network results tables will appear in the report when
collections are selected.
The following screen-shot shows how the individual results tables will appear in the report when
collections are selected and “Show individual results for non-collection items” is ticked.

Page 546
The defining of collections has no effect on the calculations – only on how the results
are collated.
In order to avoid misinterpretation of collection results, it is recommended

that the glossary screen is examined as this shows how the values are derived, i.e. SUMMATION,
AVERAGE, WEIGHTED-AVERAGE, or 'SPECIAL' calculation. For some values further thought is still
needed as the results may not be what you think they are, e.g. averages and weighted averages are
always ‘PER LINK’ or ‘PER TRAFFIC STREAM’.
TRANSYT provides an approximate estimate of the fuel consumed in a network when a particular set
of signal timings is in operation. The estimate comprises three components: (i) fuel consumed while
travelling at constant cruise speed between stop lines, (ii) extra fuel used during delay and (iii) extra
fuel used due to making each full stop and having to resume cruise speed. Pedestrian crossings and
links are excluded automatically from the calculations
The original principles behind these estimates are explained in LR 934, (Robertson et al, 1980).
However, the latest equations and associated coefficients are now taken from the more up-to-date
DfT WebTag: TAG Unit 3.5: The Economy Objective “Vehicle Operating Costs – Fuel”3
3
WebTag is the Transport Analysis Guidance Website, provided by the UK’s Department for Transport (2010) to provide detailed guidance on the
appraisal of transport projects and wider advice on scoping and carrying out transport studies.

The equations used to estimate the fuel consumption at constant cruise speed, and that due to
stopping and starting, both depend upon the cruise speed for the link being considered. Figure
27-16 shows these relationships for the average UK car (as of March 2010). Details of the revised
fuel consumption equations and coefficients are in section 27.9.1
27.9.1 Fuel consumption coefficients

To use this feature, firstly you need to “Enable fuel consumption” via the fuel consumption screen
(Main Menu > Data > Fuel Parameters…) or via the Model and results options.
Fuel consumption differs substantially between one vehicle type and another, and these differences
are reflected in the fact that WebTag provides separate a, b, c and d coefficients for seven
categories of vehicle.
The cruise fuel consumption formula is of the form:
L = (a + b.v + c.v2 + d.v3) / v
Where:
L = consumption, expressed in litres per kilometre;
v = average speed in kilometres per hour;
a, b, c, d are coefficients defined for each vehicle category.
TRANSYT provides extrapolated coefficients for each of the vehicle categories for the base year
(currently 2010), and also for future years. New files automatically start off with using the
extrapolated fuel parameters for 2010.
To replace these coefficients, press the “Generate extrapolated fuel Parameters…” button, and then
enter the year for which you wish the fuel parameters for. This will overwrite the existing
coefficients. The description field will also be populated with the chosen year, what base data the
extrapolation process made use of, and the WebTag publication date of that data e.g. Year 2016
extrapolated from 2010 base figures (WebTAG, October 2013).

Page 548
Figure 27-14 Fuel consumption data
Reference to a non-existent set of coefficients will result in an error on the task list. Generally,
extrapolated parameters are available with TRANSYT for any future year within the same range as
published data is available in WebTag.
Alternatively the coefficients can be entered directly, therefore allowing updated or alternative
values to be used if necessary. To use your own values, you simply type over the existing ones. If
you do this however, it is advisable to record this fact by also editing the description field; so that it
does not give the impression the new values are from WebTag.
Global (network-wide) vehicle composition also needs to be provided so that a weighted-average

fuel consumption can be calculated for the network (see Figure 27-15). Again, TRANSYT provides
default vehicle composition appropriate for the UK, but this can be easily replaced if necessary.
27.9.2 Fuel used as a result of delay

The fuel used during delay periods is calculated using the same formula above, multiplied by speed
(v) and then using a zero value of v (i.e. the a parameters becomes the only relevant parameter).
Historically there have been significant improvements in fuel efficiency and the
projected estimates (see WebTag) continue to indicate this trend will continue. If you wish to
estimate fuel consumption for a year other than those provided, you will need to apply the relevant
adjustment factors for efficiency as documented in WebTag TAG Unit 3.5 Table 13 or elsewhere.
27.9.3 Fuel used as a result of stops

The fuel used as a result of stops is formulated to take account of the wasted kinetic energy as a
consequence of having to slow down and accelerate back up to the cruise speed. This requires the
average weights of each of the seven categories (see Figure 27-15). Again, defaults are provided,

but your own values can be specified directly. If you wish to bypass the calculation you can specify
the E parameter directly by changing the ECoefficent Mode from “ByWeights” to “Custom” for each
vehicle category.
The stops consumption formula is of the form:
L = E.V2
Where: L = consumption, expressed in litres per stop
Figure 27-15 Vehicle categories: proportions and weights

The calculations used in the fuel model always use traffic flows (and saturation flows) in PCU/hour. If
you enter flows in vehicles/hour the program uses the relevant vehicle mix and PCU factors to
calculate the flows in PCU/hour and provides the model with flows in PCU/hour.

Page 550
Average Car Consumption (litre/100 miles)

cruise speed (litre / 100 miles)
Fuel consumption at constant
Link cruise speed, V (km/h)
Figure 27-16 UK Fuel consumption relationships
If you are from outside of the UK, or have specific knowledge relating to your particular locality, you
can modify the parameters in the formulae. However, pleased note that the simple traffic behaviour
assumed in TRANSYT sets limits on the accuracy of prediction that can be achieved.

The TRANSYT assignment model is a journey-time based User Equilibrium assignment (Beckmann,
1956) and so is referred to as the Journey Time Equilibrium method here. Journey Time Equilibrium
Assignment is a method of ‘assigning’ traffic to a network in such a way that it reaches a Wardrop
‘user equilibrium’ (Wardrop, 1952). The assigned flows will result in a situation where each driver
will have chosen the least expensive route and any change in route of any one driver will result in
higher costs for that individual, as well as higher costs for that particular route within the network.
Drivers are not assumed to cooperate in any way, but instead seek the lowest cost route unilaterally.
The overall effect is to achieve equalised costs across alternative routes within the network (based
on the particular cost term(s) used - in TRANSYT’s case this is journey time).
The assignment method performs a number of iterations of cost calculations and flow allocations in
order to find an equilibrium point for the traffic flows. During these iterations costs are recalculated
given the latest flows and traffic is transferred from path to path based on the objective - which is to
find the lowest cost. N.B. more than one run of TRANSYT is also run in order to establish certain
capacity values such as those at give-ways.
The cost function used makes use of traditional TRANSYT costs such as LR909. The costs are derived
from uncongested travel time, signal uniform delay and random plus oversaturated delay (LR909).
The delay calculations also take account of the TRANSYT traffic (model) options “Type of Vehicle-in-
Service” and “Type of Random Parameter” values. Weighting factors such as “delay weight
multipliers” and limit penalties such as “excess degree of saturation penalties” do not affect the
assignment process, as their purpose is to influence the signal timing optimiser.
The assignment process should be regarded as a separate task to that of optimisation of

the network. It may be tempting to repeatedly assign the traffic flows after each
optimisation of the signal timings as a means of improving the TRANSYT model
predictions. However this should be avoided as it may produce unrealistic signal
timings and link/traffic stream flows.
Although it may be sensible to re-assign flows from a wide-area matrix when there
have been major changes to the network structure, the repeated re-assigning of
traffic flows will not generally improve the accuracy of the generated local matrix
flows and hence the model predictions will not improve either. This is principally
because repeated assignments between optimisations can result in self-fulfilling
results, e.g. if a particular path has more spare capacity than other paths, the
optimisation of the signal timings may result in more traffic being assigned to it
during the next assignment, and this in turn will encourage the optimiser to assign
more green time next time also. TRANSYT optimises, and this again encourages more
traffic onto that path during the next assignment, and so on.

Page 552

TRANSYT Optimisation in detail Page 553
As explained in section 4.4, co-ordination between signal-controlled intersections requires a

convention which relates the green periods of any one junction to those at the other junctions in the
network. In TRANSYT this is achieved by relating all stage change times to a common, although
arbitrary, zero time as shown earlier in Figure 4-8. The offset of an intersection is defined as the start
of stage 1 (based on the standard definition of stage start). In this way the offset may be thought of as
the start of the cycle for the controller stream concerned.
TRANSYT obtains its optimum settings by using the selected optimisation process. Whichever
optimisation technique is used, the optimisation process searches for a set of timings for the network,
which in its simplest case, minimise queues and delays. The optimiser alters both the signal offsets,
which affect the co-ordination between signals, and the durations of the individual stage green times
(the green split) at each junction.
Cycle time is not automatically considered by the signal optimisers, but TRANSYT’s “Cycle Time
Optimiser” tool, can be used to evaluate a range of cycle times, from which the optimum can be
selected. The operation of, and output from the Cycle Time Optimiser is described in section 28.11
which also discusses issues related to the choice of cycle time.
The controller streams which are to be optimised are listed in the Optimisation Order (Outline:
Network Options > Optimisation Options > Advanced). If a controller stream is omitted from the list
its initial settings will not be altered. Thus, a network can be studied in which one or controller
streams within the network do not have their initial settings altered and act as a constraint on the
optimisation of the remaining controller streams. If the “Auto Optimisation Order” option is enabled,
all controller streams will automatically be included in this list.
Individual traffic streams, links and pedestrian crossings can also be excluded from the calculation of
the Performance Index and from the full set of network results by setting the “modelling” option
“Exclude from results calculation” (Outline: Traffic Stream n > Modelling or Outline: Pedestrian
Crossing n > Modelling). A global setting to exclude all pedestrian crossings from the results
calculation (no matter what the above option is set to) is also provided (Outline: Network Options >
Traffic Options > Advanced).
If you wish the P.I of a particular part of the network not to influence the optimiser, but
still wish its results to contribute to the full set of network results, you should set its local delay and
stop weighting multipliers to zero in order to achieve a zero P.I. for that part of the network.
In TRANSYT the main (and default) measure of performance considered is a weighted combination of
the delay and stops on all the traffic streams and links in a network, and additionally the delay only on

Page 554
pedestrian crossing ‘sides’ in a network. It represents the cost of traffic congestion, where traffic is
not limited to vehicular traffic. The Performance Index (P.I.) is defined as follows:
Nv Np
P.I. =  (Wv.widi + (K/100).kisi) +  (Wp.wjdj

i=1 j=1
where Nv = overall number of traffic streams and links
Wv = overall cost per average PCU-hour of delay
K = overall cost per 100 PCU-stops
wi = overall delay weighting on traffic stream (or link) i
di = delay on traffic stream (or link) i
ki = overall stop weighting on traffic stream (or link) i
si = number of stops on traffic stream (or link) i
Np = overall number of pedestrian crossing ‘sides’
Wp = overall cost per average pedestrian-hour of delay
wj = delay weighting on pedestrian crossing ‘side’ j
dj = delay on crossing ‘side’ j
The TRANSYT signal optimisers attempt to minimise the P.I. If it were possible to reduce the delay
and number of stops to zero, then this would mean that every vehicle which approached a traffic
signal would find the signal at green and would thus proceed to its destination without any delay or
stops and hence with minimum journey time. The TRANSYT optimisers are therefore seeking to
produce multi-directional ‘green waves’. Clearly, it is usually not possible to eliminate all delay or
stops within a signal network, but the minimum total value will be sought automatically by the
TRANSYT program.
TRANSYT allows for varying traffic conditions, involving the use of several contiguous time
segments making up the overall modelled time period. When this option is used the overall P.I. value
presented is the AVERAGE P.I. for all of the time segments combined. The highest P.I. within the time
segments is also provided. For purely cost benefit purposes the average P.I. value is the one to use.

28.1.1 Choosing the monetary value of vehicular stops and delay

The monetary for vehicular stops and delays is accessed from Main Menu > Data > Monetary Values…
TRANSYT evaluates the P.I. in monetary terms (£ sterling - by default) and you are required to select
values Monetary Value of Delay and Monetary Value of 100 stops (in Network Options > Economics),
for the coefficients Wv and K that they judge are most appropriate. The values of Wv and K
appropriate for a traffic stream of average composition, at the time of release of the product, are set
as the defaults within the software. A lower valuation of delay (Wv) would be more appropriate if the
cost of non-working time was to be considered negligible. Clearly the proportion of heavy goods
vehicles and buses within a traffic stream may also affect the cost of delay. Occasionally it may be
advisable to use a traffic stream (or link) specific coefficient wi to correct the estimates of the delay
costs on traffic streams (or links) where, for example, there is a high proportion of goods vehicles.
Figure 28-1 Economics – Stop and delay Costs
Similar arguments apply to the selection of a value for K. This value is for a standard full stop from a
cruise speed of 12 metres/sec; stops on links with other cruise speeds are automatically increased or
decreased in value by the TRANSYT program in proportion to the loss of kinetic energy. The
relationship between the K and Wv values has for many years been maintained at the values
developed for LR 888. This relationship between stops and delays has been dropped in favour of a
system that allows you to update your own values using the UK Government’s web-based Transport
Analysis Guidance known as “WebTag”. As a consequence of the revised method you will notice
how little the cost of stops has become in relation to delay. This reflects the far larger increases in
the cost of people’s time compared with the costs associated with stops. If it is thought that
accidents are partly caused by vehicle stops or some cost is placed on the nuisance value of a stop
then you might wish to increase K.
The signal optimisation procedure is affected only by the relative values of Wv and K and not by their
absolute values (assuming no other penalties have been applied). Further, where signals are initially
uncoordinated or badly co-ordinated, then both stops and delay can usually be reduced by the
TRANSYT optimisers. However, the balance between delay and stops that is finally achieved by the

Page 556
signal optimiser is likely to be affected by the relative values chosen for Wv and K (Robertson et al,
1980, also describes how Wv and K may be chosen to minimise the overall fuel consumption).
28.1.2 Choosing the monetary value of pedestrian delay

With the addition of the pedestrian behaviour (walk on red) model TRANSYT 15 now allows both the
explicit specification of pedestrian flows and an associated pedestrian delay cost. The pedestrian
monetary value of delay (WP), at the time of release of the product is to the same as that for vehicular
traffic.
The monetary for vehicular stops and delays is accessed from Main Menu > Data > Monetary Values…
The cost associated with pedestrian delay is very much dependant on the value of time you wish to
attribute to the pedestrians in your network relative to vehicular traffic. Due to the high saturation
flow values associated with crossings generally, the delays to pedestrians for all but the busiest sites
(in terms of pedestrians and vehicular traffic) is likely to be relatively small compared with vehicular
delays. However, it could be argued that even relatively modest delays to pedestrians could
encourage red-running of pedestrian signals, discourage walking generally (which could lead to
increased vehicular traffic) and also reduce the distances of journeys that pedestrians are willing to
make on foot. The type of pedestrians and the reasons for their journeys may also be important
factors in determining suitable values of their time, and hence the delay costs you may wish to use.
Please note that there are also a facility to suspend the addition of pedestrian delay costs to the
overall P.I. either for individual pedestrian crossings or for all crossing in the network, giving you
control over which crossing costs influence the optimiser.
28.1.3 Stop and delay weightings

Stop and delay weightings are applied differently to depending on whether it is a link or a traffic
stream. To understand how weightings apply to traffic streams you should read both the text below
and the additional section 28.1.3.1.
The link stop weighting is a number representing the percentage of the stop valuation used when
calculating a link’s contribution to the Performance Index The stop valuation is set in Data Outline:
Network Options > Economics > Monetary Value of Stops (per 100 stops). The default stop weighting
of 100% means that the specified cost will be used unchanged; a value of 0% will mean there will be
no stop costs incurred. Negative percentage weightings will cause the optimiser to seek settings
which increase stops on this link.
Similarly, the delay weighting is a number representing the percentage of the delay costs (uniform +
random-plus-oversaturation) used when calculating the link’s contribution to the Performance Index.
The default delay weighting of 100% means the specified cost will be used unchanged; a value of 0%
will mean there will be no delay costs incurred. Negative percentage weightings will cause the
optimiser to seek settings which tending to increase delay on this link during optimisation.

Stop and delay weightings allow you to place a different emphasis on specific links. For example, a
large delay weighting factor on a particular link or series of links will ensure that the optimiser will
derive greater benefit from reducing delay on those links and thus delay will tend to be reduced more
on those links than others.
This method of specifying weightings is NOT the same as in versions prior to

TRANSYT 13, i.e. the use of -9999 to represent zero weighting and 0 to represent the default TRANSYT
value, i.e. 100%, is now redundant, and if used will result in undesirable effects. The weightings of
older files are converted to the new method when imported into TRANSYT 16.
28.1.3.1 Specifying traffic stream weightings
Figure 28-2 Weighting Multipliers
When using a link structure, buses and trams are naturally separated onto their individual links
(normally as part of a link share) and therefore delay and stop weightings can be easily applied
directly to them. However, the stop and delay weightings that can be applied to traffic streams will
apply the weightings to all vehicles using that traffic stream, and unless it happens to be a normal-
only, bus-only or tram-only traffic stream, the weightings will be applied to the full mix of vehicle
types – which will not allow weightings to be applied to favour normal traffic, buses or trams.

Page 558
Figure 28-3 Weightings per vehicle type
In order to provide the same capabilities, as provided by the link structure, TRANSYT additionally
allows stop and delay weightings to be applied selectively to normal flows, bus flows or tram flows
(Outline: Traffic Stream n > Normal traffic, Buses or Trams). These “stop and delay weightings” are
multiplied by the “Stop and Delay Weighting Multiplier”.
Note carefully how the ‘delay multipliers’ and ‘stop multipliers’ can be used simply as
normal stop and delay weightings – i.e. applied to all traffic on a traffic stream, if the individual
weightings for each traffic type are left at their default 100%.
Figure 28-4 Weightings per vehicle type and path
Furthermore, TRANSYT provides a “Per Path” facility where weightings can be applied to each traffic
type using a particular TRANSYT path. This provides the required flexibility to favour particular
vehicle types using a particular traffic stream or those using a particular path on a particular traffic
stream.

The most commonly used optimisation settings are to be found in the Optimisation Options screen
(Outline: Network Options > Optimisation Options). These are described in the following sub-sections.
Figure 28-5 Network Optimisation Options
28.2.1 Establishing Initial Signal Settings (Auto-Redistribute)

Before optimisation, TRANSYT must calculate the Performance Index for an initial set of signal timings.
Auto Redistribute removes the need for you to provide these initial timings by calculating valid starting
signal timings. When selected, Auto Redistribute values will ALWAYS overwrite any existing initial
stage start times. Auto Redistribute affects only those controller stream listed on the Optimisation
Options > Advanced > Optimisation Order for inclusion in the optimisation process. You specify
whether or not Auto Redistribute is to be used in Network Options > Optimisation Options.
The previous method of calculating initial timings, called EQUISAT, is no longer used.
28.2.2 Optimisation Level Selection

TRANSYT offers a choice of four Optimisation levels (Outline: Network Options > Optimisation
Options). These are:
 “Offsets only”
 “Offsets and Green Splits” (default)
 “Custom”
Of course, optimisation can be switched off entirely, when you wish to evaluate an existing set of
timings by switching off “Enable Optimisation”.

Page 560
Selecting “Offsets only” allows TRANSYT to optimise only the offsets between controllers, i.e. the start
of stage 1 on each controller, without changing any of the red and green split times.
Selecting “Offsets and green splits” allows TRANSYT to vary green split times as well as the offsets.
Please note how green split optimisation cannot be select on its own. This is simply because offset
optimisation is inherent within any green split optimisation.
“Custom” allows advanced optimisation parameters to be set – see section 28.5.2.
28.2.3 Out profile accuracy

The optimisation parameter “Enable out profile accuracy” is switched on by default. This option,
when ON, speeds up optimisation considerably – especially for larger networks. However, the
optimisation results will generally be poorer ‘on average’. When ON the optimisation process makes
use of a set of accuracy parameters. How to set these parameters is described in section 28.5.2.1
Switch OFF “Out-profile accuracy” to carry out a higher-performing but slower optimisation. When
switched OFF, the highest accuracy values are used by the optimiser, ensuring the best results are
achieved.
Although optimisation levels are set at a network-level, TRANSYT also offers control over what
optimisation is allowed at the individual controller level – Both offset optimisation and green split
time optimisation can be disallowed.
The combined effect of the network-level settings and the local setting determines what
optimisation occurs for each individual controller. This ‘resultant’ effect of the two sets of
restrictions is reflected in each controllers own “Optimisation Level” – This value is not editable
directly, as it simply reflects the various optimisation options that have been set.
Figure 28-6 Controller Optimisation Options

28.3.1 Allowing Optimisation of offsets

During offset optimisation, all the stage change times at a controller stream are shifted
simultaneously, with the result that the green time allocated to each stage is unchanged.
Disallowing offset optimisation will also automatically disallow optimisation of green

splits (i.e. the separate green-split option will be ignored) – This is reflected in the resultant
“Optimisation Level” for that controller. This is because green-split optimisation inherently includes
offset optimisation, so that banning one will ban the other.
28.3.2 Allowing Optimisation of green times

When allowed, TRANSYT is capable of optimising the durations of the greens for the various signal
stages, by shifting stage change times individually, in an attempt to reduce the network
Performance Index. Such re-allocation of green time is not allowed to break any constraints, e.g.
reducing any green time below its specified minimum value or taking it over its maximum value.
The green times associated with a particular controller stream can also be ‘locked’ while still
allowing the offset (start of stage 1) to be optimised for that controller. N.B. if all controller
streams were disallowed from optimising green split times this way, it would be equivalent to
setting the network-wide optimisation level to “Offset only” and de-selecting the “Auto
Redistribute” option.
If a controller stream’s green times are locked to an invalid set of timings, e.g. broken intergreens,
TRANSYT will fail to run.
There are a number of situations where the ability to lock the start or end of a particular stage on
one controller to the start or end of a stage on another controller. This could be for either
operational reasons or safety reasons. In particular, in situations where storage areas for certain
traffic movements are limited, as you would have at a hamburger roundabout for example, the
locking of stages together can be beneficial. In TRANSYT we call this locking an optimisation “stage
constraint” as it ‘constrains’ how the optimiser is able to change the signal timings.
Stage constraints are specified from within the controller’s optimisation data (Outline: Controller
Streams > Controller Stream n > Optimisation) or via the Controller Streams screen, by selecting
“Enable Stage Constraint”.
Each controller stream can have a single stage constraint. The stage constraint locks the start, end,
or start and end of any stage on the controller containing the constraint to any stage on another
controller.

Page 562
Figure 28-7 Defining Controller-specific Stage Constraints
Setting the “Lock Type” defines whether it is the start time, end time or start and end times of the two
referenced stages that will be fixed relative to each other. You then need to specify the following
data:
 “Library Stage to Lock”, i.e. the stage you wish to lock on the current controller
 “Controller Stream to Lock to”, i.e. the other controller you wish to lock the first one to
 “Library Stage to Lock to”, i.e. the stage on the other controller you are locking the first stage
to
Optionally, you may also set the start and/or end of a stage to start earlier or later than that of the
other stage it is locked to. To do you this you will need to change the “Locked Start Offset” and/or
“Locked End Offset” from their default zero values. N.B. the offset is a positive offset for the current
stage relative to the other stage. For convenience the current start and end offsets are reported.
When manipulating timings manually and running evaluation runs of the model this information is

useful, as it allows you to see what offset data needs to be specified, in order to retain the current
offsets.
When setting a constraint, the current signal timings are likely to become invalid as they probably
won’t satisfy the constraint that you have just set. If the optimiser’s “Auto Redistribute” option is
switched OFF, this will result in an error message on the Task List. To turn this into a warning message
(so that you can run TRANSYT) switch auto-distribute on. “Auto Redistribute” is required as TRANSYT’s
optimiser must start with a valid set of timings, and it is the auto-redistribute process that does this for
you.
The setting of stage constraints influences the behaviour, and hence performance, of the
TRANSYT optimiser. Like any of the features that influence the behaviour optimiser,
such as delay weights and queue limits, the use of stage constraints will result in an
optimised solution that is further from the optimum solution in terms of the P.I. that
would be have been achieved without such constraints being applied. Therefore, stage
constraints should be used only where and when necessary.
Stage constraints can be used in combination with the controller grouping facility but it
is unlikely that the combined use will ever be needed in practice. Remember that
controller grouping will lock all of the stages on the grouped controllers together and
will also lock their green splits.
Stage constraints can also be used in combination with controller green-split locking.
Constraints that form a loop (e.g. a stage on controller 1 locked to one on controller 2
and a stage on 2 locked to 3 and a stage on 3 locked to 1) should be avoided as this is
likely to lead to unpredictable results as it will severely restrict the optimiser’s ability to
find a good solution.
Stage constraints are not taken account of by the phase optimiser.
28.4.1 Locked stage example

This example illustrates just one of the possible uses of a stage constraint between two controllers. It
is a pedestrian crossing controlled by one controller stream linked to the controller of the upstream
junction. The link is used in this case to ensure good coordination between the two, typically to place
the pedestrian green man at the quietest point in the signal cycle. In this case, it has been deemed
appropriate to allow the minor arm to be given a green while pedestrians are also given a green. This
means the movement of traffic from right to left on the main road is disrupted by both conflicting
movements simultaneously, thus avoiding having to stop twice.
A small offset of minus 4 seconds (Figure 28-8) has been set to ensure that the right-turning traffic
from the minor road does not hit a red signal as it approaches the crossing. This is illustrated in Figure
28-9 using the network diagram’s “Traffic (Queues and Occupancy)” overlay.

Page 564
Figure 28-8 Displaced Pedestrian Facility with stage constraint
Figure 28-9 “Traffic” overlay showing coordination of signal timings

TRANSYT offers a choice of optimisation processes – Hill-climb, Shotgun Hillclimb, Simulated

Annealing (Outline: Network Options > Optimisation Options > Advanced).
Figure 28-10 Choice of Optimisation Type
The choice of optimiser is basically a balance/choice between speed and performance. Hillclimb is
the fastest optimiser and although it generally gives good results, the other options can give better
ones. Simulated Annealing is the slowest but has the best performance, while Shotgun Hillclimb is
somewhere in the middle it terms of both speed and performance.
There are three levels of hillclimb optimisation offered – The “standard accuracy” matches the
parameters used in TRANSYT 15, while the “more accurate hill climb” matches the parameters used
in earlier versions of TRANSYT.
The actual speed and performance of hill-climb, shotgun hill-climb and Simulated Annealing are
determined by a number of user parameters and by the particular network being modelled.
Because of this, it is inherently difficult to predict the differences between optimiser types in terms
of speed and performance for a particular network file.
The following sections describe each of the processes in turn.
28.5.1 Hill-climb optimisation - the process

First, TRANSYT calculates the Performance Index of the network for an initial set of signal timings
which has either been provided by you or generated using either the auto-redistribute calculation.
Any set of timings that do not violate any of the constraints, such as stage minimum green
requirements and are capable of handling the traffic are suitable. Next, the program alters the offset
of one of the signals by a predetermined incremental change (time units) and recalculates the P.I. of
the network. If the P.I. is reduced, the offset is altered successively in the same direction by the same
incremental change until a minimum value of the P.I. is obtained. If the initial change increases the
value of the P.I., the offset of the signal is altered in the opposite direction until the minimum value is
obtained.

Page 566
The offset of each signal in turn is adjusted in this way; the signals are dealt with in the order which
is specified in the Optimisation Order (Outline: Network Options > Optimisation Options > Advanced).
The process of optimising the offsets of each signal in turn is repeated a number of times, to obtain
the final signal settings.
It is a characteristic of hill climbing methods, such as the one just described, that the ‘optimum’ they
find is not necessarily the best one; it may just be a local minimum. To reduce the possibility of
finding a poor local optimum, TRANSYT normally uses both large and small timing alterations for the
successive optimisation of each signal. The size and type of alterations are defined using hill-climb
increments. It is unusual to need or want to change these from their defaults. Please read section
28.5.2 if you wish to know more about these.
28.5.2 Hill-climb increments and accuracy

The size of the incremental changes made to the controller stream timings by the hill-climb process
is determined by the Hill Climb Increments (Outline: Network Options > Optimisation Options >
Advanced). These are only editable if you have chosen the “Custom” Optimisation Level in
Optimisation Options.
Figure 28-11 Hill-climb Increments and accuracy
The increments are listed as percentages of the cycle time. The number of increments must not
exceed 15. The increments must be less than 50 per cent. The program automatically multiplies the
percentages by the cycle time specified in Network Options > Network Timings. In this way, a list of
increments in 1-second units is obtained. To ensure that the increments list can contain a 1-second
increment for optimisation to the highest accuracy possible, a value of 1 input on Hill climb
increments is interpreted as 1 second - not as a percentage.
The hill-climb process takes the first increment (in seconds) from the list and adjusts all stage
change times of the first controller stream on the optimisation order list for a local minimum of the

Performance Index. The second controller stream is then adjusted in the same way and so on until
the end of the list. At this point, the second increment is used and each controller stream
re-optimised in turn. The process ends when all controller streams have been optimised for all
increments. Green times are not affected by this offset optimisation. The increments used are
chosen to give a good global minimum in least computing time.
The recommended (and default) values for use on Hill climb increments for the optimisation level,
“offsets only” optimisation are:
15 40 15 40 15 1 1
The 15 per cent increments find an approximate local minimum of the Performance Index whilst the
40 per cent increments avoid getting trapped in that minimum. The unity values, interpreted as
1-second increments, give the final settings.
Green times can be optimised by selecting the optimisation Level “Offsets And Green Splits”
introducing “–1” increments into the list, in which case each stage change time at a controller stream
is altered by one second at a time, whilst the remaining stage change times stay fixed. This has the
effect of varying the durations of the green times. The recommended (and default) values for use on
Hill climb increments for “offsets and Green Splits” optimisation are:
15 40 -1 15 40 1 -1 1
A fourth level of hill-climb optimisation (Extended - Offsets And Green Splits) is provided which
introduces larger negative increments into the list (see Figure 28-11)., in which case each stage
change time at a controller stream is altered by several seconds at a time, whilst the remaining stage
change times stay fixed, i.e. green split optimisation. There are more hill-climbing increments
demanded by this level of optimisation and this results in longer run times. The default values for use
on Hill climb increments for “Extended - Offsets And Green Splits” optimisation are:
15 40 -1 15 40 1 -1 1 -15 -5 -1 15 1
TRANSYT uses the default values as described above, automatically choosing the relevant sequence
depending upon the selected level of optimisation chosen in Network Options > Optimisation
Options. However, if the optimisation level is set to “Custom” the sequence can be edited directly
by the user, to suit whatever circumstances they may have. As with the default cases described
above, the absence or presence of negative numbers in the custom list of parameters dictates
whether or not green times are optimised or not.
TRANSYT has an “Enhanced Optimisation” option, specific to hill-climbing process, which forces
TRANSYT to (internally) cycle through the complete hill-climbing process until the final P.I. no longer
decreases (up to a maximum of four loops). This NEVER produces worse results and in the vast
majority of cases, has the effect of improving the results, i.e. lower overall Performance Index for
the network. This option is specified in the Optimisation Options screen. The option is switched off
by default since it increases the computational effort required and hence slows down each TRANSYT
run. However, you are unlikely to notice the speed difference unless you carry out an action

Page 568
involving multiple runs, such as the plotting of the Cycle Time Graph, or running a particularly large
network.
28.5.2.1 Accuracy parameters

On traffic streams (and links) that are remote from the controller being optimised, the recalculation
of stops and delay is often unnecessary. TRANSYT tests whether the OUT-profile on a traffic stream
(or link) has been altered sufficiently to require that the delay and stops on the adjacent
downstream traffic stream (or link) be recalculated. If not, the effects downstream are ignored. In
this way, delay and stops are recalculated only on those traffic streams and links that are
significantly affected by the signal optimisation.
The Optimisation Steps, “OUT Profile Accuracy” parameters field enables you to specify the
percentage changes in the OUT-profile below which downstream effects are ignored. The values
specified must lie within the range 0.05% to 100%. One such accuracy value must be specified for
each hill-climb increment.
The Accuracy Parameters are only editable if you have chosen the “Custom” Optimisation Level in
Optimisation Options.
It is not necessary to calculate results particularly accurately whilst the hill-climb increment is large.
Thus, small changes in flows on a traffic stream (or links) can be ignored until the signal settings are
close to optimum. This fact is reflected in the different default values that are set for each of the
different optimisation levels. Accuracy parameter values greater than 1% are not recommended for
the calculation of final signal settings. The initial signal settings are always calculated with an
accuracy parameter value of 0.05%
28.5.3 Shotgun hillclimb process

Shotgun hill climbing is an optimisation process where different valid initial signal timings are
selected more-or-less randomly and run one after the other, using the standard hill-climbing
process. You select the (Shotgun) Number of runs they wish to carry out. Any run that improves the
objective (P.I.) will automatically replace the existing one.
It has been shown that different initial conditions (signal timings) can result in different optimised
results. Therefore, this simple technique is an effective way to improve the overall optimisation
process. In many cases the extra time required to carry out multiple runs is repaid in significantly
better results. It is essentially a trade-off between speed and performance – the more runs you do,
the better potentially are the results. The default number of runs is set at 10. In practice, this has
been found to be a good compromise between improving the results (compared with a single
hillclimb) and the speed it takes. You may wish to limit the number of runs further when using
larger models or to using this option only for more finalised runs of the model.

Figure 28-12 Shotgun hillclimb optimisation
The benefits are file-specific, so there is no guarantee that different starting points will
produce significantly better results. However, the process will often produce significantly better
results and it will never produce worse results.
For full details of how the hillclimb optimisation process works please read section 28.5.1 on the
Hillclimb Optimisation Process.
28.5.4 Simulated Annealing process

Choosing this option changes the main part of the TRANSYT optimisation process to use this
alternative optimisation technique as part of its overall optimisation process. It is a technique which
can be effective at finding an acceptable set of good signal timings within a reasonable time period,
rather than necessarily finding the best timings. The name comes from metallurgy, in which by
heating up a material and letting it cool down it allows more initial freedom of changes within the
structure (while it is hot).
Just like the other optimisation processes, TRANSYT calculates the Performance Index of the network
for an initial set of signal timings. Any set of timings that do not violate any of the constraints, such as
stage minimum green requirements and are capable of handling the traffic are suitable.
Figure 28-13 Simulated annealing optimisation

Page 570
Next, the program alters the timings as dictated to by the optimiser logic and recalculates the P.I. of
the network. If the P.I. is reduced, these timings replace the currently best set of timings.
The timings of each controller stream, in the list of controller streams to be optimised, are adjusted
in this way. The two terms “SA Start Temperature” and “SA Cooling Factor” allows you to control
the optimisation process. The higher the starting temperature the longer the optimisation will take
as this factor is allowing the timings to become more ‘fluid’ to start with. The cooling factor
determines the rate at which the temperature drops to its minimum and therefore reduced the time
to optimise the larger the value. Too high a value however gives the optimisation process less time
to adjust to a better set of timings and may result in poorer results. In practice, the default values
have been found to be a good compromise between the performance of a single hillclimb run and
the additional time that it takes.
28.5.5 Optimisation when using time-varying flows

TRANSYT optimises the ‘complete situation’ in such a way as to provide optimised timings that give
the best overall Performance Index for the complete modelled time period, i.e. the timings are
NOT optimised for each separate time segment.
The optimised timings are applied across all time segments within the traffic model in order to
provide results for each time segment and for the whole modelled time period.
28.5.6 Defining a Master Controller and how to retain its offset

Some coordinated systems define a master signal controller, and use it to set up and/or report the
signal timings of other cascaded signal controllers, relative to those of the master controller. TRANSYT
allows you to define such a “Master controller” in Outline: Network Options > Optimisation Options >
Advanced.
Having set up a master controller, the additional option “Offsets relative to master controller” when
true, will set all controllers to automatically reference the master controller, and hence all “relative to”
offsets will be reported relative to the master controller. This facility saves having to direct each
controller individually to the master controller.

Figure 28-14 Defining a master controller and manipulating its offset
Furthermore, when looking to calculating signal plans that you plan to use contiguously, it is useful to
be able to set the main offset of the master controller to remain the same after an optimised run. This
can be achieved without changing the network performance by simply rotating all the timings in the
network by the same number of seconds. The dropdown “Master controller offset after each run”
offers three options:
 When “Do nothing” (default) is selected TRANSYT leaves the timings as they are, or as they
are calculated by an optimised model run
 When “Set to zero” is selected TRANSYT automatically rotates all the timings such that the
master controller’s offset is set to zero after each model run. Please note that if you carry out
an evaluation run with “Set to zpaste allero” ticked, the timings will still be rotated.
 When “Restore previous” is selected TRANSYT rotates all the timings such that the master
controller’s original offset is retained after each model run.

Page 572
You may have particular situations where it is necessary to prevent a queue from reaching back from
one junction to another, thereby blocking the upstream junction. This complex effect is not modelled
when using the traditional platoon dispersion model in TRANSYT which assumes that all vehicles
queue at the stop line. (See section 0 on CTM for how to model blocking effects) TRANSYT does,
however estimate a mean maximum queue (PCU) for each link.
It is then optionally possible to specify a queue limit for selected traffic streams (or links) so that the
signal optimiser attempts to find settings which make it less likely that the mean maximum queues will
exceed the limit values. The limit is set in the Modelling tab of either the Links Data screen or Traffic
Streams Data screen (Outline: Traffic Streams > Traffic Stream n > Modelling) or (Outline: Links > Link n
> Modelling).
As part of the queue-limit process, TRANSYT computes an average excess queue (PCU) where a
queue limit has been specified. The ‘mean maximum queue’ is checked against the queue limit
during each step of the typical cycle. During any step of the cycle when the limit is exceeded, the
excess queue is totalled and hence an average excess queue is computed for that link or traffic
stream. In this way, it is intended that the excess value will relate not only to the amount by which
the limit is exceeded (in PCU) but also to the duration of the blocking back.
It is then necessary to encourage the signal optimiser to avoid settings which cause any limit
queues to be exceeded. Thus, the average excess queues are weighted by a value specified by you
as Excess Queue Penalty, and are added to the Performance Index.
28.6.1 Setting limit queues

The mean maximum queue is, by definition, likely to be exceeded in a significant proportion of
cycles. It would be more helpful to know the size of the queue which would be exceeded in no
more than (say) 95 per cent of cycles. Unfortunately, the shape of the distribution of the cycle-by-
cycle values is not readily calculable.
You must therefore use judgement to set a limit queue which, usually, will be smaller than the PCU
storage capacity of the link. It has been found suitable in several cases to use a limit of about 60 to
75 per cent of the full storage, but a lesser value may be needed where the full storage
4
The use of the above queue-reduction facility, and indeed the use of large weighting factors on link
delays or stops, may result in the optimiser being unable to find satisfactory signal settings.
Consequently the TRANSYT output should be examined most carefully, looking, for example, for
poor co-ordination which seems unreasonable; the cyclic flow pattern graphs (Section 20.4) can help
in this process. To improve the ability of the optimiser to find acceptable timings and thus to lessen
the need for such checking, it is recommended to that you use a node optimisation sequence which
includes more than once any nodes connected by affected links. The nodes will thus be listed once
individually, again in pairs of adjacent nodes, and possibly in larger groups, using the facility
described in Section 28.5.1.

accommodates only a small number of vehicles, as variation from cycle to cycle is then relatively
more extreme.
28.6.2 Maximum Queue Storage

In order to assist in the identification of links which may have problems storing the number of vehicles
in the queue on that link TRANSYT estimates a maximum queue storage value for all links in the
network. N.B. previously known as “Link Capacity”. The calculation for vehicular links is as follows:
maximum queue storage (PCU) = link length (m) x saturation flow (PCU/h)
5.75 x 1850
This assumes that each PCU in a queue occupies 5.75m along a lane having a standard saturation flow
of 1850 PCU/hour of green.
If the mean maximum queue exceeds the above maximum queue storage, this is indicated in the
output, e.g. the Link Results table is marked with a ‘+’ symbol in the mean maximum queue column to
indicate a possible problem which you are advised to check if the timings are to be implemented in
practice. The amount by which the MMQ value exceeds the mean queue storage is also calculated.
For pedestrian crossings ‘sides’ the maximum queue storage defaults to a value of 10 pedestrians if it
is not specified. This may equate to the typical storage available on a smallish central refuge.
For Traffic Streams the automatic calculation of maximum queue storage is different:
Maximum queue storage (PCU) = link length (m) * number of lanes
PCU length
where the PCU length is defined by the user in Network Options > Traffic Options. The number of
lanes is the number of lanes that the traffic stream represents.
This calculation is only a rough calculation and in particular, is subject to

overestimation of the available storage space available to queueing vehicles.
Therefore, TRANSYT lets you specify your own Maximum Queue Storage value for
each link in PCUs (Outline: Link n > Modelling) and for each traffic stream (Outline:
Arm n > Traffic Steam > Traffic Stream 1 > Modelling). If it exists, this value is
always used instead of the internally estimated one.

Page 574
The ability to control the optimisation process in order to achieve a particular outcome is very
useful. To this end, TRANSYT has the ability to control the resulting Degree of Saturation on any
traffic stream or link by allowing penalties to be applied to DoS values above or below a target
value. The principal is exactly the same as for limit excess queue penalties, but allows you to either
set an upper or lower limit or both with associated penalties for each. This in effect allows you to
encourage the model to produce timings that allow a particular link or set of links to perform
above, below or ‘at’ a certain level (of DoS).
Figure 28-15 Degree of Saturation penalties
As the penalties only apply to the difference between the excess DoS and the calculated DoS, costs
need to be set high for them to have an appreciable effect on the final DoS.
When the pedestrian walk-on-red model is activated there is the option of applying a penalty cost
per link to the proportion of gap-accepting pedestrians over the limit set by you. This can be used
to influence the optimiser to produce signal timings that help to reduce the proportion of
pedestrians crossing in gaps. This may have the effect of reducing the pedestrian exposure to
danger at a crossing.
For further details of this feature please see section 15.5.
A controller stream-grouping facility is available:
(a) so that fixed relationships can be maintained between adjacent controller stream
(b) to improve optimisation between groups of controller stream.
Controller Streams are generally identified by positive numbers. However, in the Controller Stream
(Optimisation) List the number may be prefixed by a negative sign. In this case the controller stream
will be grouped with the next positive controller stream in the controller stream list and the

controller stream s in the group will be optimised together. For example in Figure 28-16 controller
stream list of (1,-2, -3, 4, 5, 6, 7) will result in controller streams 2, 3 and 4 being grouped and
optimised together.
Figure 28-16 Grouping controller streams 2, 3 and 4
Offsets can be optimised in this way but optimisation of green times will not be performed on
‘negative’ controller stream groups. The green times at controller streams included in a controller
stream group will, however, be altered by the “Auto Distribute routine if this option is selected to
give initial signal settings.
Grouping controller streams, so that their offsets are altered together and not individually, can be
used when an area is too large to optimise in one computer run and the area must be broken down
into sub-areas. Controller streams on the boundaries between sub-areas can be optimised initially as
part of one sub-area and then included as a group (keeping their relative offsets unaltered) in the
optimisation of an adjacent sub-area. Controller streams grouped in this way are unaffected when
TRANSYT optimises the green time distribution between stages.
TRANSYT provides the option to include a controller stream more than once in the optimisation
sequence. Thus, the offsets and green times for an individual controller stream can be optimised as
well as the offsets only for a group which includes that controller stream. This facility may be useful
when two or more controller stream are constrained, usually by being close together, to a rather
limited range of acceptable signal timings; the ability of the optimiser to minimise the network
Performance Index is likely to be enhanced by this process.

Page 576
Selection of the best cycle times for each controller stream within a network is a complex and, as
yet, not fully-resolved optimisation problem.
Choice of cycle time interacts with other fundamental decisions such as whether to divide the
signals in an area into two or more sub-areas within which different cycle times are used. Multiple
sub-areas may produce benefits by allowing signals to operate on shorter cycle times than would be
possible with the whole area on a common cycle time, but this may be at the expense of a loss of co-
ordination across sub-area boundaries. Further complications occur when multiple cycling and
repeated green possibilities are explored; for example, all signals in a sub-area may be able to
operate on a 70 second cycle, but a smaller Performance Index might be possible by operating the
sub-area on a 90 second cycle with several controller stream double cycling.
In the absence of a satisfactory formal procedure for choosing cycle times, a considerable amount of
ingenuity can be exercised by the traffic engineer in choosing a combination of sub-areas, cycle
times, double cycling, repeated greens, and also of stage sequences. Using TRANSYT to test a variety
of options is likely to provide worthwhile improvements compared with simply using a common
cycle for all controller streams in an area; 10 per cent reductions in delays and stops have been
obtained.
As an additional aid in this difficult choice process, the Cycle Time Optimiser Tool (Section 28.11)
provides information for a wide range of cycle times; it shows a graph of the Performance Index,
Practical Reserve Capacity or Total Delay for the complete network against cycle time. Suitable cycle
times for the complete network are quickly discernible. Multiple cycling options can also be
investigated using this tool.
It is relevant to comment that when altering signal cycles (and green time durations) the random-
plus-oversaturation delay term (Section 27.2) has a most important part to play; the main limitation
when using shorter signal cycles is the increase to higher saturation of the green times. This is
reflected in an increase of random-plus-oversaturation delay with shorter cycle times. It is also
worth noting that networks with a high proportion of flared approaches (short lanes) will also be
seen to benefit from cycle times that allow flares to only just clear by the end of their green. Longer
cycle times will then increasingly reduce the efficiency of the flares beyond this point. In some
circumstances longer cycle times may also result in longer queues which may then block upstream
junctions, particularly when link/lane lengths are short, such as those at signalised roundabouts.

The Cycle Time Optimiser is an optional aid to the difficult task of selecting the cycle time. It
provides information for a wide range of cycle times; it shows a graph of the Performance Index,
Practical Reserve Capacity or Total Delay for the complete network against cycle time. Suitable cycle
times for the complete network are quickly discernible. Multiple-cycling options can also be tried
out and compared with the current multiple-cycling situation by using the “proposed” set of multi-
cycling selections.
The calculations are based on full runs of TRANSYT, i.e. all controller streams, traffic
streams, links and pedestrian crossings are assumed to be part of the coordinated network. As a
result, all but the smallest of networks will take some time to run. To speed up analysis you can try
the following:
 Don’t use the default cycle time range – set your own limits.
 Use a step size of two or more to reduce the number of runs. This will give you the rough
shape of the graph quicker, from which you can judge what narrower range of cycle times
you wish to plot using a smaller step size.
 Use the traffic model “link-by-link PDM” if you are not using CTM or CPDM anywhere in your
network.
The Cycle Time Optimiser is accessed from the Main Menu “Tools” menu. The program makes use
of the currently selected TRANSYT file. The screen is split into three main areas – a Controller
Stream Table on the left; the graph itself, and various options along the bottom of the screen.
The contents of the list of “Signal Controllers” is determined (filtered) by the “Cycle Time Source”. This
is set, by default, to “network default”, so that all controllers that are using the network cycle time will
be listed in the grid below.
The “cycle time source” list is populated with all controller streams that have their own ‘manual’ cycle
time. Any controllers that also make use of that cycle time by referring to it, will also appear in the
filtered list of controllers below. The current cycle time of each controller is listed, and double-clicking
on that column of the grid for a specific controller will bring up the Data Editor so that you can make
changes if required.
The “cycle time source” determines which cycle time is going to be varied when plotting the Cycle time
graph.
The Controller Table indicates which controller streams are currently single, double, triple, or
quadruple cycled. The controller table can be hidden using the Hide button.

Page 578
Figure 28-17 Cycle Time Optimiser results
Pressing the Run Graph button creates a graph of Performance Index against a range of cycle times.
A full run of TRANSYT is carried out for every cycle time in order to produce the results. Points are
plotted for every chosen step (in seconds) within the chosen range.
Although the cycle time that is being varied may only affect a sub-set of controllers in
the network the whole network is still being run.
Using the dropdown list below and to the left of the graph, the reported P.I. on the Y-
axis can either be set to display the “Network P.I.” or the “Cycle Time Source P.I. When “Network
P.I.” is selected the graph will display the total P.I. for the complete network. When “Cycle Time
Source P.I. is selected the graph will show the P.I. of just the sub-set of items whose cycle time is
being changed. This allows you to investigate the performance of each cycle time ‘zone’ within your
network.
The second dropdown allows you to plot Practical Reserve Capacity (PRC) or Total Delay instead of
the P.I. The default is for the P.I. graph. If one of the graphs has already been run, TRANSYT won’t
need to re-run it, unless the range or step size has changed.
The graphs also display sets of results for either the “Current set” or “Proposed set” as defined in
the grid above.
The graph’s vertical bars show the P.I. values based on the proposed set of cycling options.
This data set also indicates the proportion of traffic streams or links exceeding the user-defined degree
of saturation threshold by colouring (in red) the same proportion of the length of the vertical bars. The
proportions not over-saturated are in green. ‘All green’ indicates that the whole network is within the
defined DoS threshold.

The orange coloured line graph indicating the P.I. values of the current multiple cycling options. The
cycle time producing the lowest P.I. is indicated with a purple outline while the minimum practical
cycle time is indicated with a blue outline.
The Cycle Time Graph for the “proposed” multiple-cycling options shows the P.I. for a range of cycle
times assuming these suggested changes have been implemented for the complete range of cycle
times.
Having examined the graphs the required cycling changes to the existing TRANSYT file can be made
by selecting “Use Proposed Cycling Options” and pressing <OK>. For those controller streams whose
cycling status is changing, the relevant controller stream and traffic stream (or link) data will be
changed. It is usually wise to back up the original data file prior to implementing cycling changes, in
case the original proves more suitable.
Similarly, the minimum ‘practical’ cycle time can also be implemented in the current file by selecting
‘Use Min Practical Cycle Time’. This is applied only to the currently selected cycle time source.
The ‘Min Practical Cycle Time’ is defined as “the lowest cycle time which will result in no traffic
streams (or links) exceeding the DoS threshold”, i.e. an ‘all green’ bar chart.
Traffic Signals within a co-ordinated network are, in the simplest case, all operated on the same
common cycle time and at each controller Stream the signal stages receive green once only during
the cycle. The common cycle time must be long enough to give adequate capacity at all signalised
junctions and therefore some are likely to operate on a longer cycle time than would be desirable if
they were operating in isolation. There are a number of ways of using TRANSYT whereby this
situation may be improved.
28.12.1 Multiple cycling

Some controller streams can be set to operate on a cycle time which is one half, third or quarter of the
common network cycle time; these are referred to as ‘double-cycling’, ‘triple-cycling’ or ‘quadruple-
cycling’ respectively.
‘Multiple-cycling’, as it is called, of lightly loaded junctions within a sub-area requiring a much longer
cycle time may reduce delay due to excessive cycle time at the quiet junction(s). Multiple-cycling is
most likely to give benefits when a group of junctions within an area can all be double cycled.
However, Multiple-cycling the occasional junction may give benefits. It is not easy to predict when
benefits will accrue - multiple-cycling often, but not always, reduces the overall network delay. It is
therefore important to try various possibilities, and make your final selection based on the TRANSYT
optimised PI’s achieved.
The effect of multiple-cycling at particular controller streams can be tested using repeat runs of
TRANSYT with first single then double-cycling, etc. on the controller streams in question. This process
can also be carried out using the Cycle Time Optimiser.

Page 580
The ability to set a controller to its own “manual” cycle time cannot be used
to help identify multiple cycling opportunities as you might expect, as TRANSYT does not currently
identify the fact that adjacent controllers are running on multiples of each others’ cycle times, and
therefore continues to flatten the flow profiles between them. Therefore any benefits of such
coordination will not show up in the results. However, this does not negate the usefulness of the
Cycle Time Optimiser in optimising cycle times within each sub-network and the “Proposed” settings
can still be used to investigate multi-cycling opportunities instead.
Multiple cycling can also be of use when attempting to model specific stages that come in only every
second, third, or fourth cycle (e.g. a pedestrian stage). In order to model this effect you will of course
need to double, triple or quadruple the cycling on all the controller streams which are running during
EVERY cycle while leaving those not coming in every cycle as single-cycled. Also an alternative method
using repeated greens – See section 28.12.3.
28.12.2 Equal-length and unequal-length multiple-cycling

The TRANSYT optimiser can be constrained to only allow “equal length” multiple cycling, e.g. the cycle
of a double-cycled controller stream is divided into two equal-length halves. There are however,
occasions where it is advantageous to allow the cycle to be split into two unequal ‘halves’, for instance
the traffic arriving at a junction may be split into a large platoon from the main through movement at
the previous junction followed later by a small platoon from the turning movement. Unequal cycles
can also be useful in tidal flow situations, where the platoon from the dominant direction arrives in
one half of the cycle, and the minor direction in the other.
Allowing unequal multiple-cycling gives the optimiser more flexibility to find good timings, and of
course does not stop the optimiser selecting identical timings for each set of repeated stages within
the cycle. The option that prevents unequal double-cycling is called “Equal Length Multiple-cycling“,
and is an option of each stage sequence (Outline: Controller Stream n> Stage Sequences > Stage
Sequence m).
Figure 28-18 Base stages

The original stages (which are ‘repeated’) are called “Base Stages” in order to differentiate them from
the ‘virtual copies’ of these stages.
TRANSYT re-creates these ‘virtual’ repeat stages every time TRANSYT is run. On the Timings
Diagram the virtual stages are shown slightly greyed-out.
Virtual (non-“base stages”) can be converted into real stages via the Timings Diagram option “Tools >
Convert All stages to base stages”. This system allows you to retain the original stages, while still
being able to see the newly created repeat stages, AND be able to edit the repeat stages if and when
needed.
28.12.3 Repeated greens

An alternative to multiple cycling a controller stream is to repeat one or more stage green time(s)
during the common cycle time. Thus, a controller stream with three separate stages A, B and C might
be operated with, for example, stage sequences A, B, A, C or A, B, C, A, B. At present, it remains a
matter of judgement when such modifications are likely to be of overall benefit in a network. The
traffic engineer must decide which stage sequences are of interest and TRANSYT may then be used to
compare the alternatives. There is evidence from unpublished work by TRL that, in some situations,
the correct choice of stage order can lead to substantial reductions in signal delay in a network.
Stage ordering of individual junctions can be investigated using TRANSYT’s stage and
phase optimisation facilities – accessed via the Timings Diagram and Signals Data screen. These can
automatically provide you with the best stage ordering for the isolated case.
TRANSYT has facilities which allow you to assess the effects of small changes relatively easily.
28.13.1 Small changes to flows

A vehicle flow scaling factor can be applied to all vehicular flows throughout the network (Outline:
Network Options > Traffic Options). This parameter, by default, applies to all analysis sets, but this can
be changed using the data sharing system, so that the value applies to each analysis set individually.
Similarly, a pedestrian flow scaling factor can be applied to all pedestrian flows throughout the
network (Outline: Network Options > Traffic Options).
This facility is useful in the study of the sensitivity of the optimum signal settings to changes in flow.
Flows for the whole network can be scaled within the range 10% to 500%.
28.13.2 Small changes to stop and delay weightings

The traffic stream (and link) stop and delay weightings specified affect the Performance Index and
signal timings. Switching off the “Use Link Stop weightings” and “Use Link Delay weightings”

Page 582
options, located in Network Options > Traffic Options > Advanced can be used to negate the effect
of any weightings specified. Thus, it is possible to investigate the effects of changes to these
weightings upon the Performance Index and timings.
The P.I. results are presented with and without the effects of all of the different types of
weightings, so that the ‘true’ P.I. is always available. This avoids the need to carry out non-
optimised runs with the weightings cancelled in order to produce a P.I. for, say, cost-benefit use.

Modelling Examples Page 583
This chapter describes an example file to assist you to familiarise yourselves with all the various key
aspects of TRANSYT, and to give assurance that they are using the software in correct way. The
example described in this chapter makes use of the Platoon dispersion Model (PDM). For CTM
examples see chapter 30, “Modelling Signalised Roundabouts”.
The Chapter 30 examples also include the use of Local OD Matrices as well as a detailed explanation
of modelling signalised roundabouts.
The files supplied with the software may show some small differences with those
described here as a result of creating and running the files with a more recent release of TRANSYT.
The units used throughout these examples are passenger car units (PCU). The units
selected should be set to reflect the data provided. Switching units does not convert the data.
Some sample data files (including those described in this chapter) are provided with your copy of
TRANSYT. They will be placed in a sub-folder either within the product folder or under your data
area during installation.
For further examples and documentation that may be added following product release, please see
the TRANSYT 16 section of our website at www.trlsoftware.co.uk. (Select Products from the top
menu and then select TRANSYT) The Knowledge Base button links to product-specific articles and
FAQs that may be of interest.
Figure 29-1 Additional website information and advice

Page 584
Figure 23-2 represents an imaginary small traffic network constructed using an Arm, Traffic Stream
and Lane structure. The equivalent network constructed using a traditional link structure is also
shown in section 29.2.16. The example is designed to demonstrate several of the facilities in
TRANSYT, while NOT suggesting ‘normal’ values for any of the parameters used. Explanation of
certain aspects of the TRANSYT model, data and results is made while the data file (containing
results) is supplied with the software (“TRL1 – optimised LANES.T15”, a link equivalent file “TRL1 –
optimised LINKS.T15” and also a variation using a Wide-Area OD Matrix (“TRL1 – optimised LANES
with ASSIGNMENT.T15” ).
Figure 29-2 A small network build with lanes

(TRL1 – Optimised LANES .T15)
29.2.1 Controller Streams and Traffic Nodes

Signal controlled junctions are controlled explicitly by the Controller Stream network diagram
object. There are four controller streams, numbered in an arbitrary manner, each controlling a
different junction, and one priority junction. The priority junction is modelled using a T-junction
Priority Object (see chapter 18).

Controller Streams 1 and 4 operate on a single cycle and nodes 2 and 3 are double cycled within the
common cycle time for the network of 96 seconds.
Controller Stream 1 has three stages: (1) Phases A (western arm) and C (eastern arm), (2) Phases B
(northern arm) D and E (southern arm) and (3) an early cut-off stage running phases E and D (southern
arm, offside lane – right-turn movement)
Controller Stream 2 has three separate stages serving each of the three approaches one after the
other – the western arm, then the northern arm and then the eastern arm. Each approach receives
two green periods per cycle as the controller stream is double-cycled.
Controller Stream 3 controls a signal-controlled pedestrian crossing and this has two stages: (1)
eastern arm vehicular traffic and (2) pedestrians in both directions. Pedestrians and vehicles alike
receive two green periods per cycle.
Controller Stream 4 has two stages: (1) Phases A (northern arm) and C (southern arm), (2) Phase B
(eastern arm)
29.2.2 Give-way control

The network contains one priority junction (Node P1) operating without signal control. There is no
need to use a “P” prefix, but doing so does help to quickly identify priority nodes within your
network. The north arm gives way to the controlling flow from the western arm.
In this example the approach on the main road from the right (C1/1) would be described as a “Full
Blocking” situation in PICADY. This means that traffic that a proportion of traffic going straight-on will
get blocked by right-turning traffic. However, in this case the flows that are turning are tiny so the
predicted queue at this point of the network is correspondingly very small.
At node 1, right-turning traffic from the South (Traffic Stream 17/2) is given a green signal during
stage 2 but must also give way to opposing flow (Traffic Stream 13/1) from the North. During stage 3
an unopposed right-turn for Traffic Stream 17/2 traffic is provided.
29.2.3 Arms, Traffic Streams and Lanes

An arm is a one-way section of the network between intersections. It acts like a container for the
traffic streams along that section of the network. Traffic Streams are the most important modelling
item. A separate traffic stream is used for each distinct queueing situation of interest, as discussed
in section 4.3.
There are approximately 21 arms, 183 path segments (underlying links) and 4 controllers. Generally,
the arms have been numbered for convenience so that the first digits correspond to the node number
which the exit flow travels through and the last digit corresponds to the alignment of the traffic
stream, numbering in a clockwise direction starting from the West. The arms entering the priority
junction have been named such that they correspond to the naming convention of PICADY. This is
purely down to choice, and is not a requirement of the model. Furthermore, unrestricted arms that

Page 586
exist within the network have been prefixed with “x” for easy identification. Again, this is not a
necessary convention.
Traffic Stream A1 is unrestricted, i.e. has no saturation flow as the traffic on it is not opposed to
anything and the nature of the road space does not change along its length. Cutting the road space
between nodes 1and 2 is necessary in order to provide the cyclic flow profile of the controlling traffic
flow at the priority junction where Arm B1 traffic must give way.
Traffic Stream C1 is modelled as a give-way as right-turning traffic gives way to traffic turning from
Arm A1 into the side road.
29.2.4 Buses and pedestrians

Traffic Streams 11/1, x13/1, A1/1, xB1/1, 21/1, x24/1 and x25/1 carry buses as well as normal traffic
(see Traffic Type). None of the buses stop. All other traffic streams carry just normal traffic.
The buses share common stop lines with the other traffic. The queues on shared traffic streams
intermingle and, for example, buses may be delayed by a queue of other traffic which arrived earlier
and is sharing the stop line.
The pedestrian crossing at Node 3 is modelled using TRANSYT’s new bi-directional pedestrian crossing
object (P1). In TRANSYT, prior to TRANSYT 15 you would have used two separate pedestrian links to
model both directions of pedestrian flow across the road.
Although this example does not use the walk-on-red model, this can be easily switched on if you want
to model this behaviour.
29.2.5 Queue Limits

A queue limit (Queue Limit (length and Excess Queue Penalty) is applied to both traffic streams on
Arm 17 in an endeavour to restrain the queue from exceeding the 10 PCU storage capacity of the
lanes concerned.
29.2.6 Flared approach

The approach from the East (Arm 25) flares out into two lanes (modelled using two Traffic Streams
25ab/1 and 25ab/2). The nearside is for left turning traffic and the offside for straight ahead traffic.
Both these traffic streams are set to us a “Flare” traffic model in order to model any blocking that may
occur due to one or the other lanes filling up.
29.2.7 Average flows

The inflows to each traffic stream and the total flows are shown on the diagram in units of PCU/hour
(or Veh/hour). Flow consistency is provided by the compulsory use of Local OD Matrices.
Discrepancies due to missing paths are quickly identified by examining the Resultant Flows.

29.2.8 Local OD Matrices

The flow allocation simplifies assigning traffic flows to traffic streams, links and pedestrian crossings
for small networks, such as this one, or for individual junctions. But there are some situations that
need to be dealt with carefully when automatically calculating all possible paths through the network.
In this example, there is scope for TRANSYT to generate several unrealistic paths are generated where
traffic does more than a complete circuit of the network. The option “Allow Looped Paths on Arms” is
switched off. On its own, this option reduces the unrealistic paths to just one. This remaining path is
filtered out because the “Limit paths by length” option is also switched on. This removes any paths
that are longer in length than the shortest path between two locations.
Traffic travelling from location 5 to 6 can take one of two paths. For this example it has been deemed
more likely that one path will be more popular and hence the percentage allocation type has been
employed to favour the more southern path over the other one.
Although a single OD matrix has been used in this example, it will often be more
appropriate to use more than one matrix if knowledge of the traffic flows is limited to the individual
junctions. This is because the accurate assigning of traffic to the correct paths (location to location)
through the network requires knowledge of the paths traffic will take - something TRANSYT does not
provide. For networks larger than this, multiple matrices MUST be used. This is necessary because the
underlying link network will become too large, resulting in very slow run speeds.
Pedestrian crossing flows can only be allocated to the network using an OD Matrix. In this case it uses
the same one that is used for vehicular traffic. You can choose to use a separate one, but there is no
need.
29.2.9 Saturation flows

The saturation flows for each stop line are shown in units of PCU/hour of green. Saturation flows
would normally be measured on-site or estimated from local knowledge of stop line width, gradient or
other site factors. If they are to be estimated, saturation flows can be calculated by specifying the
required RR67 data for each lane, and then letting TRANSYT sum the saturation flows of each lane to
give the overall traffic stream value.
The pedestrian saturation flow is calculated by the walk-on-red pedestrian behaviour model. If this
model is not used you would need to specify your own.
29.2.10 Traffic Stream length and speeds

Traffic Stream lengths are shown in the data editor at TRANSYT Network > Traffic Stream n, in this
case, shown in the chosen units of metres. The lengths specified on external links are arbitrary.
Although not used in this example TRANSYT 15 now offers the option to let TRANSYT to automatically
calculate the lengths from the network diagram. Obviously, if you choose to do this you will need to
scale the diagram so that the lengths are realistic.

Page 588
Average cruise speeds are set mainly in the range 30-36 km/h as seen in Traffic Stream n > Sources >
Source n, with some variations for longer, higher-speed links and lesser speeds on bus-only links or
links with turning traffic or parked vehicles.
29.2.11 Delay and stop valuation

Specific traffic stream weightings (on stops and delay) are used on certain traffic streams (see Traffic
Stream n > Modelling); PCU delay and stops weightings on bus links are set to 1000% (i.e. ten times
higher than normal); this corresponds to a factor of 20 per bus, since each bus is represented by 2
PCUs (Outline: Traffic Stream n > Buses).
For each pedestrian crossing “side” (P1: sides 1 and 2) delay weightings are set to 100%. Pedestrian
delay weights allow you to change the relative cost between each crossing (and side of crossing). The
relative cost of pedestrian delay to vehicle delay is affected by not only these delay weightings but
also by the now separate global costs of delay for vehicles and pedestrians.
Although the default cost of pedestrian delay is set to the same as vehicles, you might want to
consider setting the pedestrian costs lower on the basis that a smaller proportion of pedestrians than
vehicle occupants could be assumed to be working. Average occupancy of vehicles by those wishing
to travel (i.e. exclude taxi drivers, but include their passengers) may be another factor you might want
to consider when setting costs. For pedestrian crossings there is no such thing as stop costs, and
hence no stop weightings.
29.2.12 Cycle time selection

The information to aid cycle selection from the Cycle Time Optimiser shows that a cycle time of 80
seconds or longer is needed to prevent any node being more than 90 per cent saturated. The best
overall performance, without changing the multiple-cycling settings, is achieved around the 82 second
mark, but with a fairly similar performance over an extensive range either side of this value. As the
cycle time is reduced below 76 seconds the performance rapidly deteriorates (see screen shot).

Figure 29-3 Cycle time optimiser output
Experimentation of removing the existing double cycling suggested no appreciable improvement or

detrimental effects on the performance of the network as a whole, other than for very short cycles
where the lost time during two lots of intergreens results in a poorer performance (see screen shot).
All plots on the graphs use full runs of TRANSYT to calculate the Performance Indices values, so the
values you see are the same as you would get if you implemented any of the particular cycle times
plotted, or any of your multiple-cycling choices.
To run the Cycle Time Optimiser, the optimisation option “Auto-Redistribute” must be
enabled.
29.2.13 Optimisation
A standard sequence of change increments is used to optimise offsets and green durations as
specified in the Network Options > Optimisation Options > Advanced. The “Use Enhanced
Optimisation” option and the Optimisation Level “Extended – Offsets and Green Splits” could be used
to seek a further improvement in the final P.I. However, these options increase the time that
TRANSYT needs to run, but for a small network using the PDM model, the extra time needed would
be relatively small. Alternatively the new Simulated Annealing and Shotgun Hillclimb methods could
be employed. Both of these take considerably longer to run, but both have a good chance of
improving the result.

Page 590
29.2.14 Final settings

Results with the “offset and green times” optimised settings show considerable reductions in overall
delay and stops, compared with initial (uncoordinated and un-optimised) setting results.
Large weighting factors on buses ensure the final timings benefit buses significantly compared with
when the weightings are not applied. In this example, the use of weighting factors or excess queue
penalties has been satisfactory despite conflicting objectives, but this will not always be the case -
Results involving the use of weightings and penalties should always be studied carefully.
In this particular example , it is of limited value to consider improvements between the initial and final
settings since the starting initial offsets are arbitrarily set to zero at all nodes (by dragging the timings
within the Timings Diagrams such that Stage 1 of each traffic stream starts at the far left). Such
comparisons can, however, be most informative if some existing signal settings (such as those
previously calculated by another method) are used for initial settings.
In this example two user-defined Collections have been specified (i.e. two sub-sets of traffic streams)
have been defined. Results are shown for these below the “Final Prediction Table” results for the
network as whole. A full set of collated results for each collection is available via the results section of
the Collections in the Data Editor.
29.2.15 Graph plots

A number of graph plots of cyclic flow patterns (as described in section 20.4.1) are defined to appear
in the report. The graphs are laid out so that progressions can be followed on adjacent diagrams.
To aid interpretation, some of the CFP graphs are shown here annotated to illustrate some of the
many characteristics which the graphs display.
Using the “GoFlow” and “Outflow” options, it can be seen that the peak outflow from the give-way (B1/1) is during low-flow periods on the main
controlling (A1/1).

You will also notice the capacity of the give-way on one occasion dips low
enough to affect the traffic on the give-way (see below). However, most of
the queueing on the give-way is due to random traffic behaviour predicted by
TRANSYT.
Note although the saturation flow is shared between normal traffic and buses
on links such as 11 and 21, the cyclic flow profile of the traffic stream is a
combined one, and hence shows the typical flat OUT-profile ‘plateau’.
The yellow annotation highlights spare capacity during green
This series of 3 graphs shows how the “PointFlow” option can be used to observe the deterioration of the distinct platoon as it travels down a long
traffic stream due to dispersion effects. This useful option also allows model predictions to be easily compared with on-street observations at any point
along the traffic stream or link.

Page 592
29.2.16 Link equivalent of the same small network
Figure 29-4 A small network built with links

(TRL1 – optimised LINKS.T15)
A link is a one-way traffic stream between intersections; a separate link is used for each distinct
queueing situation of interest, as discussed in section 4.4.
There are 27 links. Generally, the links are numbered for convenience so that the first digits
correspond to the controller stream number which controls exit flow from the link and the last digit
corresponds to the alignment of the link, numbering in a clockwise direction from the West.
Furthermore, unrestricted links that exist in the network have been prefixed with “x” for easy
identification. Again, this is not a necessary convention.
Links 10, 1, 21, and 22 and x26 are bus-only links. Buses on link 1 share a common unrestricted
carriageway (see section 4.5.7) with the other traffic on link 2. These unrestricted links break the
carriageway (in modelling terms) between nodes 1 and 2, in order to provide the cyclic flow profile of
the controlling traffic flow at the priority junction where link 3 traffic must give way.
All the buses share common stop lines with the other traffic. The queues on shared links intermingle
and, for example, buses on a bus-only shared link may be delayed by a queue of other traffic which
arrived earlier and is sharing the stop line.

29.2.17 Equivalent small network with Wide-Area Assignment
Figure 29-5 A small network with wide-area assignment

(TRL1 – optimised LANES with ASSIGNMENT.T15)
This variation of the original TRL1 small network example has several noticeable differences. Firstly,
there are six wide-area locations which provide the mechanism to feed traffic (assign) onto the
network from the wide-area OD matrix. The Assignment will only have any effect if it assigns to
more than one Local Matrix, as otherwise the local matrix allocation process will simply replace the
flows using its own process. As with the local OD matrices it can contain bus and tram flows as well
as normal traffic flows. Four local matrices provide the mechanism to allocate traffic to each
smaller area – in two out of three cases (Local ODs 1 and 3) these are single junctions, while Local
OD 2 covers three junctions, and OD 4 covers the pedestrian crossing – This is NOT the only way of
defining the local matrices – it has been defined this way to illustrate the flexibility of TRANSYT. You
may, for example, have more or fewer local matrices. It all depends on what flow data you have
and how you wish to assign traffic to the network. Of course, the use of a wide-area matrix is also
optional.
You may also notice that there are two entry points to the network that are not included in the
wide-area – these are the two locations associated with the pedestrian crossing at Traffic Node 3.
Wide-area matrices are purely for use with the vehicular network so cannot be used to populate the
pedestrian flows of a Local OD Matrix.

Page 594
Although the flows specified in the wide-area matrix are the same as those in the one local OD
matrix of the TRL1 example files. The wide-area assignment process has resulted in different flows
through each junction (local OD matrices). Therefore, TRANSYT results are also different. However
the general performance is similar due to the limited choice of routes that exist within the network.

Modelling Signalised Roundabouts Page 595
This chapter incorporates all of the advice previously given in RR274 (Lines and Crabtree,
1990). The advice and guidance has been updated to reflect the changes that have taken
place in modern junction design and in the way TRANSYT works.
Arguably, the most significant feature in TRANSYT that makes it much easier to build a
roundabout model in TRANSYT is the direct representation of lanes, available since
TRANSYT 14. It is still necessary to decide how to model lanes in terms of traffic streams,
which is a similar concept to deciding which lanes to model with a link in earlier TRANSYT
versions, but the necessarily complex underlying network structure is now built for you and
largely hidden.
This chapter discusses in detail the factors to be considered in modelling signalised

roundabouts using TRANSYT. These factors include the network model’s structure,
estimation of saturation flows, the use of traffic stream weighting and queue penalties (to
avoid blocking back and ‘locking up’ of the roundabout), and finally the impact of the new
Simulation Mode introduced in TRANSYT 16. Four examples are used to illustrate the
techniques described. Use of the “Flare” Traffic Models (Cell Transmission Model (CTM)
and the Congested Platoon Dispersion Model (CPDM)) has been included selectively in the
examples.
An example of a roundabout build using a link structure is retained here to ensure

understanding of the issues surrounding this particular method of modelling roundabouts
and other networks.
The units used throughout these examples are passenger car units (PCU).
The units selected should be set to reflect the data provided. Switching units does not
convert the data.
At roundabouts, it is common practice to signalise one or more entry arms in an effort to

reduce delay and increase capacity. TRANSYT can model any roundabout, even those with
no signals (i.e. wholly priority). This is likely to be of values where such roundabouts exist
within a signalised network.
Signalling roundabouts to prevent queues blocking the junction was first studied in 1959
(Webster 1960), and the technique has been selectively applied over a range of
circumstances.

Page 596
Roundabouts where most or all the entries are signal controlled will normally benefit
from coordination of the traffic signals. TRANSYT can be used to optimise the signal
timings in such cases. However, roundabouts do need to be considered carefully as there
will often be short internal circulating links that may be prone to filling up and blocking
back, and in general it will be important not to let too much traffic enter the circulating
section if locking up is to be avoided. By using various facilities available in TRANSYT such
as traffic stream (or link) weighting, the shared link facility (when using links), and queue
penalties, the program can be used to model traffic behaviour on the roundabout,
control queue lengths, and find signal timings such that queues do not form to block
upstream junctions. Using one of the models that are capable of modelling blocking back
situations (CTM, CPDM and Simulation) can also assist in finding a good solution.
Note that many signal controlled roundabouts operate using MOVA or SCOOT. Indeed
the Highways Agency has issued a directive that MOVA shall be used on all trunk road
installations (see TD35/2006). However, in many cases it is important to understand the
way a roundabout operates before installing MOVA as SCOOT as it helps with
commissioning and validation of these systems, and should lead to a better solution.
Modelling such roundabouts in TRANSYT should help with understanding the operation
of a roundabout, as well as assisting in its design.
Several features are of special significance when using TRANSYT to model a signalised
roundabout. The original Platoon Dispersion Model (PDM) assumes vehicles have an un-
interrupted passage to the stop line, regardless of any queue on the traffic stream/link.
TRANSYT effectively queues vehicles in a vertical heap on the stop line, and this
simplification of the model has implications in situations where traffic streams/links are
short and flows are high - as can occur at signalised roundabouts. This effect is discussed
in more detail in section 30.5.7. The alternative models, CTM, CPDM, and Simulation are
likely to be useful when modelling a roundabout. CTM is suitable for the longer links
(over 30 metres) where blocking back needs to be avoided and CPDM for short links
(under 30 metres), which can be used to model flares and the shorter circulating
sections. CTM and its uses are discussed elsewhere in this manual (see section 26.2).
Simulation offers a different range of capabilities offered by the other models (See
section 23.1).
Stop and delay weighting and the limit-queue facilities may also be required.
Descriptions of these features are given in other sections of this user guide and are
discussed below. Another feature which may be significant is the give-way model and
priority objects which can be used if there are any unsignalled entries to the roundabout.
Traditionally, TRANSYT has been regarded as a modelling tool, i.e. one that can be used
to evaluate existing designs, assess new designs and establish the best staging

arrangements and timings. This is all still true, but TRANSYT can also be regarded as a
design tool too. TRANSYT can greatly assist in the design process though the use of the
‘Data Overlays’ (accessed via the network diagram’s “Data” menu). These allow a form of
lane flow diagram to be created, allowing quick analysis of the flow distribution across
your design as recommended by the UK’s Local Transport Note 1/09. Full details of the
flow overlay functionality is described in section 11.10.8 so is not repeated here. This
section is here solely to bring to your attention the fact that all of the following examples
could well have benefited from the use of this functionality. An example of the use of a
particular flow overlay can be seen in the following roundabout example.
The principals involved in modelling a roundabout are discussed below and illustrated by
using a simple, hypothetical, four-arm roundabout (Example 2) shown in Figure 30-1.
Further examples based on real-life sites are described in section 30.7 and section 30.8.
Figure 30-1 Site diagram of a four-arm roundabout
30.5.1 Cycle time

In networks which contain some short links (such as roundabouts), severe problems can
arise if traffic queues fill these traffic streams (or links) and block upstream junctions. If
this blocking continues for any significant time, the capacity of the network will fall
dramatically and traffic queues can block back and ‘lock up’ around a roundabout. One

Page 598
of the most important methods of keeping queues short is to keep the length of the red
time short. Achieving this is helped by having a short cycle time.
TRANSYT has a Cycle Time Optimiser that can be used to help select the lowest possible
cycle time at which the roundabout can operate satisfactorily The ability to plot P.I.
versus cycle time can be used to identify the best predicted cycle time by making full runs
on a range of cycle times. Using the default range is likely to result in you making too
many runs, many of which will be unnecessary. Therefore, it is advisable that you change
the range to something more suitable before running the cycle time optimiser.
30.5.2 Traffic stream structure

A network built with traffic streams automatically generates and uses a detailed
underlying network of shared links (called path segments in this context), in order to
preserve the separate cyclic flow profiles on each of the circulating carriageways.
A traffic stream in TRANSYT can be used to represent one lane, or it can represent more
than one lane if queues form in equal lengths. Where queues do form in equal lengths
over two or more lanes, it is more accurate to represent them as a single traffic stream.
However, even if in theory queues could equalise across two or more lanes, they will not
always do so. In this situation, separate traffic streams should be used and the
proportion of traffic in each must be measured or estimated separately.
Unequal use of lanes will occur when for example lane markings direct vehicles making a
left turn into the nearside lane, and other traffic onto the offside lane, as shown in Figure
30-1 (node 2). In this case, only one lane has been marked with a left turn arrow because
immediately downstream left turning traffic has only one exit lane. This means that it is
unlikely that any left turning traffic would be in the centre lane, so unequal length
queues could form and two separate traffic streams are required (see Figure 30-2).

Figure 30-2 Traffic stream diagram for four-arm roundabout
At node 3, the central circulating lanes have been marked for both straight ahead and left
turn traffic. It should be acceptable for left turning traffic to use the middle lane because
it exits onto a two lane road. As the centre lane is therefore likely to contain both left
turn and straight ahead traffic, it is possible that the queues on all lanes will form at the
same rate. Queues at the circulating stop line could therefore form equally for all lanes
and one traffic stream having two lanes, or even three lanes in this case can be used
(because straight-ahead traffic also has a choice of lane to use).
This assumption is only valid, however, when the arriving flow is reasonably balanced
between the turning and the straight ahead movements. If, for example, during any part
of the cycle more than 67% of the flow arriving at the stop line wished to turn left, then
the queue in the left and centre lanes would be longer than that in the offside (straight
ahead only) lane. Equally, if in another part of the cycle less than 30% of the arriving
traffic was turning left, then the queue in the left lane would be smaller than the queue
in the centre and outside lanes. In this situation, it would be necessary to use one traffic
stream for each lane.

Page 600
Figure 30-3 Flow overlay (by destination) for four-arm roundabout
Also at node 3, the approach lanes have been modelled as three separate traffic streams.
It may have made sense to model the left and middle lanes at the stop line as one traffic
stream, but the flow overlay diagram clearly shows that having modelled it as separate
traffic streams, the lane balancing routine predicts that all the left turning traffic (shown
in yellow) will use the left hand lane, due to the large amount of traffic travelling to
destination 1 needing to use the middle lane (shown in blue).
30.5.3 Modelling using links

[Skip to section 30.5.4 if you do not intend using a network link structure.]
Prior to TRANSYT 14, the network structure would always consist of links. Note that a
‘link-share’ (i.e. a major link and its associated minor links) is equivalent to a traffic
stream. TRANSYT 16 retains the ability to use links because there will be existing
TRANSYT network models, and still some advantages using them for large networks.

When modelling roundabouts, there are some well-established methods for using links,
but please be aware that using traffic streams will normally be easier. In order to
contrast the use of links and traffic streams, both are presented in the following two
Figures (Figure 30-2 and Figure 30-4)
The link diagram in Figure 30-4 shows one main circulating link for node 1 (link 11), and
two main circulating links for node 2 (links 21 and 25) where left turn traffic uses the
nearside lane exclusively. The link structure for node 3 is similar to node 1, and the link
structure for node 4 is similar to node 2. For nodes 2 and 4, where there are two main
links for the circulating traffic, one main link is used to model traffic continuing round the
roundabout and through to the next downstream junction (e.g. link 21), and a second
main link models traffic that turns left, leaving the roundabout prior to the downstream
junction (e.g. link 25). Vehicles on these second links have a ‘free left turn’ before they
reach the subsequent node (e.g. node 3 for link 25), and are not considered again by
TRANSYT.
It is also necessary to represent traffic on an entry arm by more than one link where one
lane is exclusively used for traffic making a specific movement. For example, the two
lane entry at node 2 is split into two links, the nearside lane is modelled using link 29 for
traffic making an immediate left turn before node 3, and the offside lane is modelled by
link 20 for other traffic.
Figure 30-4 Link diagram for a four-arm roundabout

Page 602
The use of shared links can improve the modelling of the junction significantly if you have
chosen to use link-based modelling, especially if origin/destination flows are available.
More accuracy is obtained as more information is added to the TRANSYT model
(providing the information is good). See section 27.6 for a detailed description of shared
links.
A network built with traffic streams will automatically generate and use the
necessarily detailed underlying network of shared links for you, so it is at least as
accurate a method to use as using a link structure.
TRANSYT models traffic flows in a series of time intervals or ‘steps’, which is normally 1
step per second. When modelling a discharging queue, TRANSYT calculates the
proportion of flow that continues into each downstream link from its knowledge of the
total flow on the discharging link and the total flow required to enter the downstream
link. For example, if 75% of the upstream link flow continues into the downstream link
(with 25% turning off), then for every step in the cycle, three quarters of the discharging
flow is taken as the entry flow into the downstream link. This is repeated for every step
in the cycle. The remaining flow is assumed to have turned out of the network and is not
considered further.
In many cases, this simplified model is not accurate, as in reality there will be
predominant movements across the roundabout. While on average one vehicle in four
will exit, it is probable that these turning vehicles will not be evenly distributed
throughout the cycle. It is not uncommon that for most of the cycle, there is little traffic
turning out at a given node, but then, for a short time, a platoon arrives of which the
majority exit.
Figure 30-1, Figure 30-4 and Figure 30-5 illustrate this for a simple four-arm roundabout.
Consider the flows arriving at the stop line X--X at node 2. Some vehicles will have come
from the entry at node 4, heading for node 3 (f43), and will exit before the stop line Y--Y at
node 3. The remaining vehicles arriving at X--X will have entered at node 1 (f13 and f14)
and a proportion of this (f13) will also exit before stop line Y--Y at node 3. The vehicles
from nodes 4 and 1 enter the circulating carriageway between nodes 1 and 2 at different
times in the cycle and so will form two distinct platoons at the stop line X--X. The
platoons are illustrated in Figure 30-5 (a). Of the two platoons only the proportion which
entered at node 1 and continuing to node 4 (f 14) will continue to stop line Y--Y. This
traffic alone should flow into the downstream link 32.
It is possible to model two entry flows separately using the shared link facility in
TRANSYT. If vehicles that are turning out of the roundabout before the next node (f 43)
are modelled as a minor shared link, then the fixed proportional reduction for circulating
traffic can be applied to the newly entered traffic only (f 13 and f14). This will give
significantly improved modelling compared to taking a (smaller) fixed proportion of the
total traffic on a single link between nodes 1 and 2.

This is further illustrated in Figure 30-5. The two platoons arriving at stop line X--X are
shown in graph (a), and their departure in graph (b). Graph (c) shows the flow along links
31 (circulating flow) and 32 (entry flow), and it can be seen that flows f 13 and f43 have
turned out of the roundabout. Graph (d) shows what would happen if only one link was
used to model all the flow between nodes 1 and 2 (f 13 + f14 + f43) - TRANSYT simply
reduces the flow leaving stop line X--X by the proportion which is turning out of the
roundabout. Hence arrivals downstream would be earlier in the cycle than in real life.
This can have a significant detrimental effect on the co-ordination of the final signal
timings, and wherever possible the shared link model described above should be used.
The shared link model does require complete origin/destination flow data.

Page 604
Figure 30-5 Use of shared links to model flows

Use of the shared link facility is required to separate circulating traffic such that, on each
section of circulating carriageway, either:
(a) traffic from each entry is represented by a different link; or
(b) traffic to each exit is represented by a different link.
The option (a) is described above - the equally acceptable alternative (b) is illustrated in
Example 2, section 30.7.
For roundabouts with five or more entries (or four entry roundabouts with significant U-
turning traffic) further inaccuracies of the nature described in paragraphs 1 and 2 of this
section may be introduced. This is because each circulating section may cater for traffic
from three different origins, (i.e. traffic having just entered plus circulating traffic from
two further upstream entries). Depending on the nature of OD movements, bearing in
mind paragraphs 2 and 3 of this section, it may be beneficial to model all three ‘streams’
separately.
Tip: As a general rule, if the roundabout has N approaches (and U-turns are negligible),
the minimum number of circulating links required will N-2, and more if the stop line has a
dedicated near-side turn lane.
30.5.4 Modelling using traffic streams

From (Figure 30-2) it can be seen that each lane is modelled separately. However, within
that, traffic streams are used to model lanes that can be equally used. In this example
there are situations where all three lanes have been combined as one traffic stream (e.g.
Arm 11) and where they have been split with the two offside lanes as one traffic stream
and the nearside lane as another (e.g. traffic streams 21/1 and 21/2). Underneath the
representation of lanes, the actual model still uses links. Hence, the use of shared links to
model the different origins and destinations within each traffic stream is handled
completely automatically in TRANSYT 15, and is largely hidden from you.
The model using links above (Figure 30-4) has not included the modelling of exit traffic.
However with the ever-improving graphical representation of the network the modelling
of exiting traffic has become more relevant. The modelling of exit traffic is required if the
OD matrix flow entry method is to be used. Exit arms are demonstrated in Figure 28. As
shown here, the exit arms allow pictorial representation of the exiting. However, the
model could be extended such that the interaction between the exiting and circulating
traffic can be modelled. A way of doing this is given in (Figure 30-6). Arm 24a would
have to be modelled with either CPDM or CTM to ensure any blocking effects are
included. However, there will be occasions when the ability to model such situations in
this way will be useful.

Figure 30-6 Exiting and circulating traffic interaction
Driver behaviour can be influenced by lane markings, and how the lanes are marked can
make a significant difference to the capacity of a junction in many circumstances.
Generally it is better to encourage equal use of all lanes by using, for example, combined
straight ahead and left turn (or right turn) arrows wherever possible. This tends to
maximise capacity by ensuring that lanes do not empty during the green while
neighbouring lanes still have queues.
The use of markings, however, cannot be guaranteed to ensure full use of all circulating
lanes, especially if flow on one of the entries is predominately for a particular destination.
Each case must be considered on its merits. Care must also be taken that markings that
are appropriate for one period of the day with a certain origin-destination pattern are
also appropriate for the rest of the day. This is particularly true of spiral markings on
multi-lane roundabouts where traffic flows are tidal.
30.5.5 Flared Approaches

Flared approaches are common on roundabout entries where extra short lanes are often
added. In these situations, the saturation flow will start at a high level and then drop
after the flare has emptied. For example where two lanes flare to three, the saturation
flow would begin at a rate determined by the three lanes, but once the three lanes have
discharged, the rate would reduce to two lane saturation flow – the rate being
determined by the fact the discharge is now from a two-lane queue.
Flares improve capacity and this can achieve this at shorter cycle times. TRANSYT has a
flared-approach model in which this ‘stepped’ saturation flow which is described in
chapter 17 can be represented. The “Flare” traffic model may also be useful for more
explicit modelling of flares where the lanes at the stop line cater for different movements
or even controlled by different phases for example. The lanes are added as they appear

Page 606
on street, connected as necessary to one-another as shown (e.g. Arm 42 representing the

three lanes at the stop line, and Arm 42f representing the two feeding lanes which will
feed traffic into the flared are in (Figure 30-2Error! Reference source not found.). The
blocking of the short lanes at the stop line is modelled and traffic upstream of the flare is
restricted from reaching the short lanes once the latter are full.
30.5.6 Saturation flows

At normal signalised junctions such as cross roads, saturation flows can be estimated
using formulae in TRRL report RR67 (Kimber, 1986). There has been much discussion
about whether these formulae give reasonable or optimistic estimates for roundabouts
(see Traffic Software News, Issue 33, March 2005 (Crabtree, 2005)). In general, it should
not be automatically assumed that these formulae give optimistic estimates. In fact, in
some circumstances it is likely that RR67 formulae are pessimistic about saturation flows,
even on circulating links. The real problem is that many roundabout features effect
saturation flow making any prescriptive method of estimating them less than ideal. For
example, flared approaches, stop lines with more than 3 lanes, oblique stop lines or
curved approaches can affect saturation flow, and possibly make the use of RR67
formulae less appropriate. Ideally, saturation flows should be measured. This can
present its own problems though as circulating queues can be short and with
accompanying short reds, the queues will not be long enough to make meaningful
measurements. It might be that the only way to measure saturation flows in cases like
this is to change co-ordination so that a longer queue forms. However, it is generally
appropriate to consider circulating saturation flow pessimistically, and entry saturation
flows as optimistic, to get an overall pessimistic view of roundabout operation.
30.5.6.1 Entry arms

Entries to roundabouts can have a number of stop line features that are less commonly
found at other types of signalled junctions. Perhaps the most obvious is flared
approaches. Other features that can affect saturation flow include oblique stop lines,
bends immediately prior to the stop line and gradients, especially on motorway slip
roads. Such features may tend to reduce the saturation flow and due account should be
taken of them, although, in general, entry-arm saturation flow is not unduly affected by
these features.
Saturation flow can decrease with increasing green time as the effect of slow-starting
vehicles (e.g. HGVs) becomes greater, especially on uphill gradients. Another problem is
the signal co-ordination itself. Saturation flow can also be reduced when vehicles
entering a short section of circulating carriageway can see that they will have to stop (for
a red lamp or the back of a queue, or both). Such effects have to be considered of
course. Ideally, coordination should be arranged such that vehicles do not discharge into
the back of a queue or into a circulating red. This aim can be aided by avoiding the
signalling of all the nodes, especially if it is possible to signal three nodes, as this leads to
easier coordination.

30.5.6.2 Circulating arms

Deciding on the saturation flow to use for circulating links in TRANSYT can be more of a
problem than for entries. The factors that can affect saturation flow are as follows:
(a) The need to change lanes in the next section may make drivers more
cautious (or perhaps more aggressive occasionally) in trying to fit into the
adjacent lane;
(b) Road curvature;
(c) Short next section with signals red and/or queue preventing ‘normal’
acceleration.
Item (c) above may require a great deal of thought if accurate modelling is to be
achieved. On most signalised roundabouts, there are at least some short circulating
sections of carriageway possibly with three or four lanes. Ideally, a single TRANSYT traffic
stream should be used to represent more than one lane only if the queue lengths are
similar in each lane throughout the cycle. Where lane usage (and, therefore, queueing
behaviour) is known or can be predicted (with destination markings for example) one
traffic stream should be used to represent one lane. In these circumstances the formulae
in RR67 may be applicable (once due account has been taken of the factors (a) to (c)
above).
Often, not all these lanes are fully utilised and where knowledge of lane usage for a
section of road is inadequate, it may not be feasible to use more than one traffic stream
to represent more than one lane. However, where it is necessary to represent more than
one lane on one traffic stream, the effects of uneven queueing may be compensated for
by reducing the saturation flow in TRANSYT. The amount by which to reduce the
saturation flow will depend on the extent to which queueing is uneven, but it is likely to
be in the order of a few hundred PCU/hour per lane. If there is doubt about the extent of
the unevenness of queueing, it will be necessary to err on the low side for circulating
traffic streams otherwise the capacity of the roundabout may be over-estimated. The
initial estimate can be refined following observation of the junction with a set of
TRANSYT timings.
In situations where coordination between upstream and downstream circulating sections

is assured, it might be important to specify a high saturation flow to avoid any spurious
queuing during the green period.
30.5.6.3 Measuring saturation flows

The correct way to measure saturation flows at signalised roundabouts is to measure the
lane or lanes represented by one TRANSYT traffic stream. Where a traffic stream
represents more than one lane, the saturation flow should be measured until the traffic
has ceased to flow at full saturation in ALL the lanes. The resulting saturation flow value
will then compensate for uneven queueing as explained in section 30.5.6.2.

Page 608
30.5.7 Blocking back

As already discussed, it is important that queues on circulating traffic streams and links
do not extend back and block the upstream junction. If this should occur the capacity of
the system can fall and queues build up very quickly. While a set of signal timings can be
found that prevent this occurring under ‘normal’ or average conditions, it is necessary to
consider the effect a sudden large increase in arrival flow would have on the system.
The use of a short cycle time is important, as described in section 30.5.1. The use of the
limit-queue facility and the effect of increased demand are discussed below.
30.5.7.1 Blocking: Prevention or cure?

Generally, it will be better to strive to find a solution that contains no blocking in the first
place rather than try to model such blocking from the start.
If blocking cannot be removed entirely then a blocking model such as CTM or Simulation
can be used to more accurately model the situation as it stands. By modelling the
blocking it will then possible to use the optimiser with CTM (but not Simulation) to
minimise that blocking.
30.5.7.2 Limit queues

One method of discouraging the formation of queues on circulating links is to use the
‘limit queue’ facility under Arm>Traffic Stream>Modelling. A maximum queue length and
a penalty factor to be applied as soon as the limit queue is exceeded is specified. The
penalty is added as soon as the back-of-queue modelled by TRANSYT exceeds the
maximum number of PCU (or vehicles) defined. The number of PCU specified in the limit
queue will normally be based on an estimate of the allowable queue length for each link,
assuming a default 5.75 metres/PCU per lane (or about 6 metres/vehicle).
The maximum back-of-queue (known as the Mean-Max-Queue or MMQ) in TRANSYT is

calculated for an ‘average cycle’ during the period under consideration. Because this
maximum back-of-queue is for an average cycle, it is expected that in approximately 50%
of cycles the maximum queue in real life will exceed the value calculated by the TRANSYT
model. Although it is possible to say the queue will be exceeded a significant amount of
the time, it is not possible to say by how much the queue will be exceeded. It is
necessary, therefore, to make an allowance for this by reducing the number of PCU
specified for the limit queue by a factor. A factor of 60 to 75 percent of the estimated
maximum allowable queue length has been found suitable, but a lesser value may
sometimes be needed, depending on the situation. Where there is likely to be a large
variation in numbers of vehicles arriving in each cycle, a smaller percentage factor should
be chosen (nearer 60%); but if there is unlikely to be much variation in arrivals per cycle,
a larger percentage can be used. It is possible that on circulating links there is less
opportunity for arrivals to vary much between cycles compared with entry links
especially if the entry link is relatively highly saturated; but each situation should be
considered carefully.

When choosing penalty values it should be remembered that the penalty is added to the
TRANSYT Performance Index only during those parts of the cycle when the limit queue is
exceeded. This is likely to be a small proportion of the cycle, but even this short time can
be critical when the link becomes full enough to affect the entry rate from upstream
links. Penalty factors should therefore be quite large, and values in the range £30 to £60
/PCU-hour (see section 28.6.1) are often appropriate.
There may be occasions when, despite a high penalty, the limit queue on circulating
traffic streams or links is still exceeded. This can occur because in order to reduce
queues on a given traffic stream, TRANSYT must increase the green time for the stage in
which the circulating traffic streams receive green. This can only be at the expense of
entry traffic streams that run in the other stage, and some of these entry traffic streams
may then be forced into oversaturation. This oversaturation causes the Performance
Index to increase considerably, and the optimiser will attempt to reduce the
oversaturation to lower the Performance Index. This in turn will cause the limit queue to
be exceeded, and even a very high excess queue penalty may not keep the queue below
the limit in situations where entry traffic streams running in the other stage have high
degrees of oversaturation.
In such cases, a low delay weighting for oversaturated entry links which can usually
accommodate a long queue may help to force the critical circulating queue below the
desired limit, but the consequences of having an oversaturated traffic stream should be
carefully considered. Sparing use of the facility is also advisable. Use limit queues only
where they are needed to minimise unwanted queuing.
Note that with CTM there will be less need for setting limit queues as queues that block
back will be more naturally avoided. However, keeping queues below a certain level is
not guaranteed and limit queues will still be useful for this. It is more important to
ensure they are applied selectively and the consequences understood.
30.5.7.3 Excess Demand

A situation can occur when a large increase in demand, (such as departures from a
football match or similar event) may cause queues to form on the circulating traffic
streams that block upstream junctions and cause the roundabout to ‘lock up’. If demand
is suddenly increased, queues are going to form somewhere, but it is important to ensure
they form on the approach arms and not on the circulating traffic streams.
This can be achieved by making sure all entry arms are running at a high degree of
saturation (typically 85 to 95 percent). This will ensure that, even if demands double,
flows on circulating traffic streams cannot increase by more than about 10% minimising
the chances of blocking back and ‘locking up’ the roundabout.
When modelling a normal urban network, TRANSYT will calculate the delay and number
of stops on each traffic streams in the network. It then multiplies these by the value of
delay and the cost of stops for each traffic streams to produce an overall Performance
Index for the optimiser to minimise. Unless specific action is taken to ‘weight’ particular

Page 610
approaches, this process treats them all as being equally important and, for individual
nodes, will distribute spare green time between approaches.
As discussed above, for roundabouts it is usually necessary to arrange entry approaches

to have high degrees of saturation, giving any spare capacity to the circulating traffic
streams. This can be achieved by removing the stop weighting for entry arms by entering
0; and by entering a low delay weighting of about 20 per cent so that only 1/5th of the
normal delay cost is added to the P.I. This will help to ensure that entry approaches run
at between the desired 85 to 95 per cent saturation, leaving any spare capacity to the
circulating approaches. Adjust the values if necessary.
This low weighting factor may not be appropriate where the entry approach is a
motorway slip road, as it may be dangerous to form large queues which could block back
onto the motorway. In this situation, a larger weighting factor may be used or perhaps
no weighting factor at all. This means that at these nodes, queues are more likely to
form on the circulating traffic streams, which could lead to blocking back, although the
queues on the entry slip roads should not be excessive. Fortunately, there is usually
more room to store on the circulating traffic streams here because they span the
distance between the on and off-slips.
Once the signal timings have been found using the suggested weighting factors and
queue penalties etc, the network should be run with flows increased by about 10-15%
with the timings set to those found without the flow increase, to check the network will
continue to operate in higher than average flow conditions. The results should be
carefully checked to ensure queue lengths remain short on circulating and other critical
traffic streams, with degrees of saturation below 90% ideally, so that blocking back to
upstream nodes is unlikely to occur. To do this in TRANSYT, after completing the
optimisation runs, simply increase your flows, and then use the “Evan Run” button to run
the file with the optimised timings from the last run. Check the results to see that
oversaturation is stored on the entries rather than circulating traffic streams.
30.5.7.4 Blocked Traffic Streams/Links

When optimising the signal timings and, in particular, the controller stream offsets, the
PDM does not take into consideration whether any traffic streams (or links) are blocked
or not. This means that situations can arise when TRANSYT produces signal timings that
would discharge traffic from an upstream traffic stream straight into a queue on a short
downstream traffic stream.
This happens because the TRANSYT model assumes that vehicles form a vertical queue at
the stop line, rather than a linear queue back along a traffic stream. The model can then
release traffic into a blocked traffic stream believing that by the time the traffic reaches
the stop line, the (vertical) queue will have discharged. Thus, the model does not
correctly take account of the green starting wave and the physical length of the queue.
When timings are implemented it is possible that some traffic stream can therefore be
poorly co-ordinated. In such situations signal timing offsets between adjacent signals
may have to be adjusted manually - This is a situation where the network diagram timing

wheels can be used effectively. The use of low limit-queue values and high queue
penalties will generally keep queues shorter and prevent this happening (see section
30.8.4.1).
Where two nodes are particularly closely spaced and the signal timings need to be fixed
in relation to each other, it is possible to model both nodes as one junction (i.e. as a
single controller stream). The stage sequence, hence the offsets can then be fixed, but
the green times can still be optimised relative to the rest of the roundabout.
Alternatively, a new feature of TRANSYT allows a stage constraint to be applied, allowing
a stage start and/or end on one controller stream to be locked to the start and/or end of
a stage on another controller stream, with a fixed offset between them.
However, for most signalised roundabouts, the use of CTM should ensure that the signal
timings minimise problems with unsuitable offsets.
Once the final timings have been derived, it is usually worthwhile to obtain Cyclic Flow
Profile (CFP) or CTM spatial occupancy graphs for every traffic stream. The graphical
outputs from TRANSYT should be studied carefully as they show a great deal about the
way queues form, and the way the traffic will behave at the junction.
Individual platoons should be followed from entry traffic stream, round the roundabout,
to final exit to see where red signals are encountered. Graphs are also useful to check
traffic stream which require special co-ordination.
If using CTM the graphical options are different. However, studying them should reveal
information about queuing and discharge patterns. Additional graphical options, such as
the animation of the cell occupancy, time-distance diagrams, and timing wheels will also
aid in the understanding of how a roundabout might function in practise.
TRANSYT offers a number of animation options which can offer a better insight into how
the roundabout is operating. To understand better both how the roundabouts described
below have been modelled and to see the way they behave, it is worth loading the
sample data files and library files supplied with TRANSYT and experiment with the
available facilities.

Page 612
The example roundabout shown in Figure 30-7 has been chosen as typical of a
motorway/trunk road site and to demonstrate the features described previously. Lane
arrows have been shown but not destination or ‘spiral’ markings; these would normally
encourage efficient lane use. The network diagram is shown in Figure 30-8. This diagram
gives traffic stream (or link) lengths, vehicle speeds and saturation flows. Saturation flows
are set to arbitrary values as the roundabout is a fictitious one. They should not be taken
as an indication that such values are recommended of even appropriate. Vehicle speeds
have all been set to 30 km/hour (again an arbitrary figure).
The roundabout has been modelled using a mix of traffic models – PDM, and “Flare”
models – in order to model the junction portrayed in the most accurate manner.
30.7.1 Modelling the junction

30.7.1.1 Traffic stream structure
As discussed in section 30.5.2, entries at nodes 2, 3, 5 and 6 have two or three lanes and
the lane arrow markings would encourage the formation of equal length queues; so
single traffic streams can be used for these approaches. For the entries from the
motorways (nodes 1 and 4), the nearside (left) lanes are marked for left turn only,
therefore two traffic streams are required on each of these approaches, the offside
traffic stream to model traffic continuing to at least one more node and the nearside
traffic stream to model traffic that exits immediately at the next downstream node.
The two flared approaches at nodes 3 and 5 have additional traffic streams to model the
additional short lanes, one traffic stream for the nearside flared area and a single traffic
stream for the remaining two lanes at the stop line. This is the recommended method
for modelling flared approaches with the “Flare” traffic model as it correctly models lane
use (provided the flows are allocated correctly).
The circulating arms are separated into traffic streams largely as determined purely by
the lane markings. In practice, it may prove necessary or desirable to separate out lanes
which also have other destinations, in addition to their common destination. E.g. the two
nearside lanes at node 6, where there is the common left-turn movement, but also the
separate straight-ahead movement in the middle lane. It depends on the balance of
turning movements and on the way the lanes are used in practice. An example of this is
given at node 3 where the four circulating lanes, which could in theory be treated as one
traffic stream, have been separate into two.

Figure 30-7 Site diagram of a signalised motorway roundabout

Page 614
Figure 30-8 network diagram for a signalised motorway roundabout
30.7.1.2 Flows
The Origin/Destination flow matrix is given in Table 30-1. This shows the flow from each
entry to each exit during the period under consideration.

To Location
1 2 3 4 5 6 Total
1 - 180 100 46 124 166 616
2 38 - 132 139 187 146 642
From 3 231 197 - 132 134 148 842

Location
4 26 95 75 - 267 108 571
5 132 153 135 35 - 125 580
6 94 135 156 106 26 - 517
Total 521 760 598 458 738 693
Table 30-1 Origin-destination matrix for signalised roundabout
An OD Matrix has been used to assign flows to traffic streams. When using the tool it is
necessary to be careful that the flows allocated to traffic streams or lanes are realistic,
and to adjust them if they are not. You may find that the “Flow Overlays” may assist with
this.
30.7.1.3 Weighting factors

In order to give all the spare capacity to the circulating traffic, all entry arms have been
given zero stop weighting and 20% delay weighting. This should ensure all these entries
will have a degree of saturation between 80 to 95 percent.
The exit arms have been excluded from the results calculations – they exist to allow the
OD table facility to be used, and to illustrate the exit arms only.
30.7.1.4 Limit queues and queue penalties

When deciding values for limit queues on roundabouts, the traffic stream should be
studied, and the queue length beyond which the free-left-turn would be blocked should
be estimated. This will normally be significantly less than the total stop line to stop line
distance. Limit queues should not be applied until it is known where the problems are
going to occur, and then applied in a controlled fashion to help ensure the resulting
queues are controlled. Check the operation is robust by running the optimised timings
with a 10% flow increase.
30.7.1.5 Cycle time

To establish suitable cycle times, the Cycle Time Optimiser can be used. A graph is
plotted and the cycle time that is likely to give the lowest performance index identified.
Be aware though that a cycle time that is too low/high may lead to entry arms having too

Page 616
much spare capacity. To alleviate this problem it may be necessary to try longer/shorter
cycle times.
It is also possible to use the X-Y graph plotting facility to plot degree of saturation against
cycle time for individual traffic streams which might help identify a suitable cycle time
when a particular part of the roundabout is very busy.
It might also be necessary to consider alternative cycle times in order to achieve practical
progression around the roundabout. It can be difficult to achieve ideal progression for all
approaches with roundabouts having four or more arms. However, it is important to
avoid major movements being stopped on the circulatory carriageway. Use the various
graphs and the animation facilities to examine platoon progression.
Please note that because some graphing facilities require multiple runs of TRANSYT, such
runs may be quite prolonged, but this depends largely on the size of the network, the
chosen level of optimisation, and the traffic models chosen.
30.7.2 The TRANSYT output

30.7.2.1 Normal flows
Example file “TRL3 - motorway roundabout.T16” gives the optimised TRANSYT output.
There are several points to notice.
a) The cycle time selected as best was 50 seconds.

b) The non-motorway entries (on Arms 20, 30, 50, 60) have degrees of saturation
ranging from 52% to 89%. Ideally, it would be better if some of these were higher
(due the reasons given earlier).
c) For the motorway-fed entries (Traffic Streams 10/1, 10/2, 62/1 62/2) the degrees
of saturation are 43% for 10/1, 55% for Traffic Stream 1/2, 70% for 62/1 and 42%
for 62/2. Given the desire to avoid queues blocking back onto the motorway, the
reserve capacity for these links needs to be carefully judged – too high and the
queue could queue back to the motorway; too low and it might allow too much
traffic on to the roundabout. There is scope in this example to make the nearside
lane cater for straight-on as well as left turn movements on link 10 which would
alleviate any oversaturation problems.
d) The degree of saturation on circulating traffic streams are all comfortably below
the desired 80%. Traffic Streams that are more highly saturated than the ideal
would need to be checked carefully by increasing the flows. None of the nodes
within the network appear to be critical.
e) Overall the optimised output shows that this signalised roundabout is operating
well within capacity. However, it is always worth careful checking of the more
highly saturated traffic streams, possibly during on-site commissioning and
validation.
30.7.2.2 Excess demand flows

Example file “TRL3 – Motorway roundabout 110 percent flows.t15” gives the TRANSYT
output with the optimised signal timings from “TRL3 – Motorway roundabout.t15” and
flows increased by 10% (Outline: Traffic options > Vehicle Scaling Factor = 110%). The
roundabout has survived this test with no obvious problems; the motorway-fed traffic
streams are not oversaturated. If they had been, it would have been worth a look at the
advanced result “Mean End of Red Queue EoTS” (End of time segment) to see if the
queues at the end of the hour came close to blocking the motorway.
The circulating links do not have large queues and there is little danger of blocking back
to the upstream nodes.
Increasing the flows globally for the whole simulation period is a severe test. Providing
the queues on circulating traffic streams do not look to be seriously impeding upstream
nodes, the roundabout should function comfortably within capacity most of the time.
30.7.3 Graphical outputs

TRANSYT generates many types of graphical output, e.g. time-distance diagrams, queue
graphs, performance index graphs, cyclic flow graphs, custom graphs and TRANSYT
results displayed on the network diagram representation of the network. In explaining
the TRANSYT output for this particular example, most of these have their part to play.
30.7.3.1 Network Diagram output

The following figures are generated using TRANSYT’s network diagram. The following
figures show a variety of views which can be used to interpret the results. As well as
showing a faithful reproduction of the network in the form of a traffic stream, controller
stream and node diagram, various input data and output results can be superimposed
onto it.

Page 618
Figure 30-9 Network diagram showing Mean Max Queues

The network diagram can provide a detailed diagram of the network – a lot of
information for each arm is shown, such as flow, degree of saturation, etc. Figure 30-9
uses the network diagram to show mean maximum queues (in orange) as a proportion of
the traffic stream length. For this example, it is clear that none of the traffic streams
suffer from capacity problems. It should be remembered, however, that the MMQ value
is an average and is therefore exceeded approximately half of the time.

Figure 30-10 Traffic Streams on green/red

Figure 30-10 shows a zoomed in view (in Network Diagram View) of node 1 and 2. The
traffic signal animation is activated in order to see which traffic streams are on green
during each second of the cycle. Stage 1 is currently running at node 1 - shown as “1 (1)”
within the signal controller symbol; stage 2 is within an interstage period at node 2.
Effective green times are shown on stop lines and by using the diagram option “Show
Effective Greens” (the yellow animated triangular arrows). The option to show amber
times is also enabled, which can be seen on Arm 21. The display of amber times has no
effect on the model results but can make the diagram more understandable to those
unfamiliar with TRANSYT. Furthermore, you may notice that the Arm arrows have been
individually set to match those that appear on-street. Again this does not impact on the
model, but can help to make the diagram more akin to what is seen on-street and hence
easier to relate to, as well as assisting in the roundabout design process itself.

Page 620
Figure 30-11 Value Comparison Tool

Figure 30-11 shows more-or-less the whole network with the value of Degree of
Saturation shown for every link in the form of varying shades of blue – the darker the
colour being the largest value and the lightest the smallest. This demonstrates how the
network diagram’s Value Comparison Tool can be used to highlight where traffic
intensities are highest. Note how most of the darkest blues appear on the entry links.
30.7.4 Traffic Model considerations

The motorway roundabout example described above has been modelled using a mix of
traffic models, including the Cell-Transmission Model (CTM). The flared approaches are
modelled explicitly, using the “Flare” traffic model - due to this model’s ability to take
account of blocking back into the feeding narrower approaches to the roundabout and
take account of random effects. This involves using a bottleneck traffic stream upstream
of the flared area that feeds two traffic streams representing the lanes at the stop line
(see Figure 30-8). This is more accurate than using the ‘quick’ flare feature, as it can
model the effects of having separate movements at the stop line (and, although not a
feature in this example, can also model situations where the lanes are separately
signalled).
Exit arms must have the ‘Has Saturation Flow’ option turned off, and optionally exit arms
can be removed from the performance index calculation altogether (and network result

totals), although their contribution to it should be minimal with the ‘Has Saturation Flow’
option turned off.
At the entry on node 3 there are two lanes on the approach and a third short lane at the
stop line. This has been modelled with one two-lane bottleneck arm (Arm 30f) with the
‘Has Saturation Flow’ option turned off, feeding both a two-lane traffic stream (30/2) and
the nearside flared area (30/1) at the stop line. The length of the short lanes is crucial if
the capacity and characteristics of the flare are to be modelled accurately. N.B. the three
lanes at the stop line could have been modelled as single stream with a three-lane
saturation flow since each adjacent lane shares a common movement, but for this
example it is thought (due to local knowledge of the junction) that queues will not be
evenly distributed as most left turns will use the nearside lane.
Figure 30-12 Modelling Flares using CPDM (or CTM)

Whether the lanes can be used evenly can be determined by setting up the flare as two
or three separate traffic streams, and seeing how flows are attributed to lanes after
entering the Origin-Destination flow data. If the lanes fill up at relatively similar rates, it
would be important to model such lanes as a single stream in order to calculate delay
correctly. If they don’t, modelling each lane as a separate traffic stream would be
necessary.
Where two or more lanes share a destination, but also have a non-common movement,
the ‘Allocation Mode’ in the OD table can be changed to even out the flows to achieve
the expected or observed queuing behaviour.
There are two 200 metre internal traffic streams where platoon dispersion could be
noticeable. The extent to which this matters or not will depend on how the queues form
and discharge. If it matters and these longer traffic streams (or links) are unlikely to block

Page 622
back these can be modelled as PDM traffic streams (as is the case in this example). If
blocking was evident/predicted it would be best to model them using CTM.
It is possible to get a good-looking solution at the fairly low cycle time of 50 seconds.
Alternative solutions can be easily found at other cycle times with little change in the un-
weighted performance index. The task is then to find a solution that will work the best
when implemented on street.

The example roundabout described here further illustrates the method of applying
TRANSYT described in previous sections. The subject is a gyratory-system which forms a
roundabout at the junction of the A413 and the B4443 to the south-east of Aylesbury
town centre. The TRANSYT model described is of the morning peak period. It shows a
typical urban situation in which the junction has reached or exceeded capacity during the
peak periods. It illustrates how such a junction can operate in an acceptable fashion,
even when demand exceeds capacity, by using TRANSYT to obtain signal timings that
control where the queues form. The CTM has been used to model the roundabout, part
from the entry and exiting traffic streams. Note that the roundabout has changed slightly
from the layout considered here, having three lanes on the Walton Street approach. The
model reflects the roundabout as it is now rather than the diagram below.
30.8.1 Description of the roundabout

The roundabout is triangular in shape (see Figure 30-13) with four main junctions, plus a
signalised pedestrian crossing on the exit to the north. The longest circulating link is 150
metres and the shortest just 40 metres.
Figure 30-13 Site diagram of the Walton Street roundabout, Aylesbury

Page 624
30.8.2 Modelling the junction

The diagram in Figure 30-14 and the TRANSYT input data (see Analysis Set 1 within
TRANSYT file “TRL4 - Walton Street.t15”) show how the roundabout has been modelled.
In all cases apart from one, each lane has been modelled as a separate traffic stream. The
exception is Arm 31, where two lanes have been modelled as one traffic stream. Here,
most of the traffic is exiting towards location 4 to the west, where there are in fact two
lanes, so both lanes on Arm 31 are equally used. As with all the exits, there is no need to
model separate lanes (unless they are internal to a larger network) as long as they are
modelled without any exit restrictions.
Figure 30-14 Link diagram for the Walton Street roundabout
30.8.2.1 Saturation flows

All the saturation flows were estimated originally using TRRL Report RR67 (Kimber et al
1986), and then reduced to account for factors such as road curvature, lane lengths.
Many were measured on street. Three approaches are flared with one lane flaring into
two in all cases. The flares on Stoke Road and Walton Road have room to accommodate
up to 7 extra PCUs; the flare on Wendover Road is longer with room to accommodate up
to 10 extra PCUs. Initially the discharge rate of each flare is at two-lane saturation flow;
after the flare has emptied, the discharge rate reduces to one-lane saturation flow. The
lane structure of the flares has been modelled directly as permitted by the CTM: The

method is to use a bottleneck lane and node which represents the single-lane part of the
approach; then to model the two lane portion with a standard (signal controlled) lanes.
The method is more appropriate for situations where the lanes at the stop line do not
share a common movement; hence the use of the two lanes is likely to be uneven. The
CTM will automatically deal with the uneven use, even when the lanes run in different
phases, (which is not the case here).
30.8.2.2 Choice of cycle-time

Finding the most appropriate cycle-time is an important factor in a roundabout type
network. The Cycle Time Optimiser (Section 28.11) can be used to predict the cycle-time
at which the best Performance Index would be achieved.
The main consideration is to keep the circulating links free from blocking-back. Achieving
the lowest Performance Index is of secondary importance. Therefore, the choice of cycle
time depends on the ease with which queues on the circulating traffic streams can be
kept under control, particularly on the critical lanes (Arm 21 stream 1, and to a lesser
extent Arm 31). In particular, this depends on the co-ordination between nodes 1 and 2
and 2 and 3. Fortunately, there is only one platoon of any importance between nodes 2
and 3 and it contains the traffic entering from link 25, most of which crosses the stop line
at node 3 on-route to node 4.
A compromise must be made when choosing the cycle time between presenting traffic
with short reds (by keeping the cycle time short) and keeping the proportion of lost-time
in the cycle low (by keeping the cycle time long). In this case (and for most signalised
roundabouts for that matter), the balance will be in favour of short reds (hence a short
cycle time). The cycle time of 70 seconds was used as this is short enough and the entries
were oversaturated where necessary. All the internal links are under-saturated with
queue lengths being within the space available
30.8.2.3 Weighting factors

One of the key points in modelling roundabouts with TRANSYT is the use of stop and
delay weighting to help ensure circulating links get any spare green time at a node
(section 30.5.7.2). In this example, the entry lanes have been weighted such that delay is
20% of its normal influence, and stops are set to 0%. The CTM optimises such that the
entry links are more highly saturated and any excess demand can be stored without
locking-up the system, rather than on circulating links. One reason why the weightings
may still be required, despite the modelling of blocking back, is that the queues will
always form somewhere if the junction is heavily loaded - without weighting they can still
form somewhere that is undesirable.
30.8.2.4 Limit queues and queue penalties

With CTM, the blocking back effects of the queuing are modelled and there should be
less need to use the limit queue facility, though they may be necessary and so it proved
in this case with arm 21, stream 1. The situation where it could be used is when the
queue is more than three-quarters along the link, or that the degree of saturation is still
approaching 100%. Remembering that TRANSYT is an average model; in real life (even

Page 626
assuming the model is as accurate as possible) queues will exceed the predicted value
approximately 50 percent of the time (even though it is not possible to say by how much
the lengths will be exceeded). Avoiding blocking back in real life may require the average
queue to be under 75 percent of the max queue storage capacity.
The queue length on arm 21, stream 1 is arguably the most important issue on this
roundabout under the modelled conditions. To explore possible ways of minimising any
problems, the X-Y graph plotting facility could be used. For example, the effects of
alternative cycle times could be tested by plotting cycle time versus queue length on
traffic stream 21.
Note that blanket application of limit-queues in not recommended. Simply applying

them to all circulating traffic streams (or links) would be expected to fail to work at some
traffic streams. It is better to find out where the problems exist and apply limit-queues
sparingly until queues form where they cause minimal problems.
30.8.3 TRANSYT output

The output from a TRANSYT run with a cycle time of 70 seconds is given in the TRANSYT
file “TRL4 - Walton Street.t15”. Studying the degree-of-saturation on each traffic stream
shows that the aim of giving spare green to circulating traffic streams has been achieved
– only Arm 31 is marginally over the 90% DoS threshold. If any internal traffic streams
had been over-saturated by any more, it would have been necessary to put this
oversaturation onto the entries so that the amount of traffic entering the roundabout is
restricted, thus reducing the possibility of blocking back.
For these predictions to depict accurately on-street behaviour, the simulation time
should equal the length of time over which the flow conditions have been averaged. In
this case, the flows are averaged over one hour, so the simulation time is 60 minutes.
The circulating lanes for node 3 (arm 31) also need to be well coordinated if queues are
to remain under control. The graphs for traffic stream 31 show the large platoon made
up of traffic entering the roundabout from arm 20. With just the one platoon, good co-
ordination between node 3 and the upstream node (node 2) is easily achieved. Hence,
queue lengths are comparatively short. However, a small error in, say, cruise speed,
could result in some of the on-street platoon being stopped and it would not take much
of an error to give rise to large on-street queues. This highlights the importance of
correct information for critical nodes.
For the remainder of the roundabout, the graphical output shows that it has been
possible to co-ordinate well for all the platoons around the roundabout. On Arm 31,
good co-ordination plays a major role in keeping the queues on circulating links short.
30.8.4 Excess demand flows

To check that the gyratory continued to function without locking up under conditions of
higher than average flow, the final signal plan was tested with flows increased by 10 per

cent of their modelled values. Under these circumstances, the increase in circulating
traffic was small, but, as would be expected, the queues predicted for entry traffic stream
20f and 27 were large. This was tolerable at this roundabout since no significant hazard
was caused by large queues on these two approaches, and this is preferable to the
roundabout blocking up, possibly reducing capacity to a fraction of that expected.
30.8.4.1 Predictability of traffic flows

One problem with the site is the unpredictability of the flows. Aylesbury town centre is
served by 5 major radial routes, many of which join on the outskirts of the town. Hence
drivers have a number of choices of route into the town centre. For the roundabout to
cope with changes in traffic flow, it is important that the signal timings limit the amount
of traffic that entered the roundabout. This is where it is important to arrange TRANSYT
to give any spare green-time to the circulating traffic streams, and then testing the
timings under conditions of excess demand. On the day observed, only the A413 coming
out of the town remained under-saturated; the other three entry arms all had long
queues during at least some part of the peak period. On the oversaturated links, the flow
into the roundabout was controlled by the green-time. If the green-time had been too
long, too much traffic would have entered the roundabout, probably leading to locking-
up.
If using a traffic stream structure:
 Use the network Diagram’s “Flow Overlays” to assist in the design of your
roundabout (in terms of lane provision and lane movements)
 Only separate lanes into separate traffic streams when necessary, e.g. when the
queueing behaviour on each lane is expected to be significantly different, or if a
‘less than significant’ proportion of traffic is able to choose between the lanes.
Otherwise, use a single, multi-lane traffic stream.
If using a link structure:
 use shared links for accurate representation of origin-destination movements, in

addition to using separate links to model individual traffic streams.
Link and Traffic Stream structures:
 Disable any unrealistic paths through the roundabout, such as ‘more-than-360O’

rotations (if they not expected to be used). The OD Matrix path filtering options
can help with this.

Page 628
 Use zero stop weightings and reduced delay weightings on entry traffic streams
so that TRANSYT considers them as more unimportant relative to circulating
traffic streams. This is to help ensure that spare green is given to the circulating
carriageway and excess demand is kept on the entry links.
 Keep the cycle time as short as possible to avoid long queues on the circulating
carriageway and to make the best use of flared entries.
 Apply limit-queues to circulating traffic streams only to address specific queue-

length problems (i.e. do not apply them to all circulating traffic streams right from
the start). When shared links exist, the queue penalty is given to the major shared
link and applies whenever the queue on the major AND minor links taken
together exceeds the queue limit.
 Use the “Flare” traffic model to model flared approaches, but watch out for
modelling inaccuracies.
 Use the “Flare” traffic model on traffic streams to model lane-gains that occur
well back from the stop line, i.e. extra-long flared sections.
 Make use of the TRANSYT cyclic flow pattern (CFP) graphs, traffic graphs, time
distance diagrams, and the queue analysis features of the network diagram to
check co-ordination and queueing behaviour.
 Compare flow patterns, degrees of saturation and cyclic flow patterns with the
on-street behaviour (and re-model the junction if necessary).

Definitions / Glossary Page 629
Data Item
Every TRANSYT data file is made up of Data Items, most of which are shown as entries in
the Data Outline screen. Data Item is a generic term meaning any of the various 'objects'
used in TRANSYT. Total Flow is an example of a data item, as is Node 1. Most data items
belong to a 'parent' data item – for example, Sources may contain several data items such
as Source 1 and Source 2. Data items also include general areas such as Traffic and File
Description.
Active Data Item

Most data items can be selected in order to make them the Active Data Item. Clicking in
the network diagram on Link 1, for example, will make Link 1 the Active Data Item in
TRANSYT. The link will be highlighted in the network diagram, in the Data Outline and on
any other relevant screens, such as traffic flows and results screens. If the Data Editor is
visible, any data item fields for Link 1 will be shown. Any operations such as adding and
deleting apply to the Active Data Item.
Data Editor
A screen that shows and allows editing of all data item fields for the Active Data Item.
See section 8.5 for more details.
Data Grid
A Data grid is powerful and flexible screen which allows views of input data and output
results in a grid style, which can be sorted and filtered. Input data can also be edited.
Data Item Field

Most data items have a set of data item fields which are displayed in the Data Editor and
describe the data item. For example, each Link has an ID, Saturation Flow, Link Control
Type, and so on, each of which is a data item field.
Data Outline
A screen that shows the current data file in outline form, with an entry for each data
item, and allows the adding/deleting of data items. See Data Outline for details.

Page 630
Library File
A TRANSYT file which has been saved for future use as some form of template. Library
files have the same file extension as ordinary TRANSYT 16 files, but are stored in a special
folder to differentiate/filter them from ordinary TRANSYT files. Library files can be
selected and merged into an existing network from within the network diagram. Several
Library ‘building block’ files are supplied with TRANSYT. See Library Files for more details.
LTS
An abbreviation for the phrase “Link and/or Traffic Stream”. Occasionally used as short-
hand in both TRANSYT and the User Guide.
Padlock
This is a mechanism that allows specific screens to be ‘locked’ to specific types of data
and/or specific items of data while navigating around the network.
Stage Library
This is a mechanism that allows multiple stage definitions to be stored within the one
TRANSYT file for convenience. It allows you to quickly swap between different possible
solutions. Multiple stage sequences can also be stored for convenience.
Task List
A screen that shows any warnings and/or errors detected in the current data file. See
TS
An abbreviation for “Traffic Stream”. Occasionally used as short-hand in both TRANSYT
and the User Guide.
Please also see section 31.1.
(Network) Arbitrary zero

The network arbitrary zero is the time from which all stage timings are relative to, e.g. if
stage 1 starts on 12 it therefore starts 12 seconds into the cycle time (the cycle starting at
zero – i.e. the arbitrary zero). Also see OFFSET.
A1 and A2 coefficients
No longer used in TRANSYT. See “Slope coefficient” instead.

Absolute minimum possible cycle time

This is minimum possible cycle time for the network, if controllers can use any of the
available stage sequences defined for each controller stream.
Achieved flow
This is what flow is ultimately in the modelled network, i.e. all effects are taken account
of, such as vehicle scaling effects, upstream oversaturation and blocking effects.
It is also referred to as “Calculated flow”, when referring to ‘entering’ or ‘out’ flows.
Actual green time

This is the time for which the signal head for traffic on a link actually shows green.
Amber (times)
In many countries amber times are displayed along with a red signal to warn drivers that
the green is about to be displayed. TRANSYT refers to this period as “red-with-amber
time” or “starting amber”. The amber period displayed at the end of green which is used
to warn drivers of the immanent change to red, is referred to in TRANSYT as end-of-green
amber. When clearance times are specified, vehicular end-of-green amber times are
added to the entered clearance times to produce intergreens.
Analysis Set
An analysis set is data within a single TRANSYT file which contains signal plan (+ other
relevant signal related data) for a single network. Several analysis sets can be stored in a
TRANSYT file. Analysis sets also allow different signal information to be associated with
the different demand sets, e.g. different signal timings for am and pm peak periods.
Arm
A TRANSYT Arm is a one-way section of the network. An Arm consists of one or more
traffic streams and one or more lanes. An arm usually stretches from one junction (or
modelling feature) to the next. The grouping of traffic steams and lanes within an Arm
allows easy identification of these components of the network as well as easy
manipulation of them within the network diagram.
Assignment (of traffic flows)

See Journey Time equilibrium
Average excess queue

If a limit queue is specified this is the average amount by which the mean maximum
queue for a link exceeds the limit queue specified for that link, averaged over the whole
of the cycle.

Page 632
Blackout Time
This is the blackout period used at some signalled pedestrian crossings (e.g. Pelicans).
This value is used to calculate the effective green time for pedestrians for use by the
pedestrian behaviour model. It extends the end of the effective green period. The
blackout time is also deemed to be part of the clearance time.
Bottleneck
A bottleneck is a LTS with 100% green. It is modelled as an unsignalled link with a
“Saturation Flow”. The facility can be used to model links which have reduced saturation
flow along their length or at a particular point. They can be used to represent the
controlling flows at a priority junction since they have no signals and hence have 100%
green, but often a fully unrestricted link or traffic stream will be more appropriate.
Bus TRANSYT
This is a method of optimising the signals in a network to favour buses.
Bus link
This is a special type of link used to model buses. For buses on such links you must
specify the average free-running speed and the average time stationary at bus stops. The
performance of buses is given separate consideration in the output.
Capacity (of a link)

This is the maximum amount of traffic that a link can cope with. It is equal to the
saturation flow multiplied by the proportion of the signal cycle that is effectively green
for the link. The junction capacity is the sum of all link capacities. If a link is over-
capacity, queues will build up uniformly over time. Queues may be a problem even when
the stream is not over capacity, due to the random nature of traffic arrivals. See Practical
Capacity.
Card type
A term continued in TRANSYT that dates back to the use of computer punch cards.
Junction data values have traditionally been split into logical groupings (card types) to
facilitate the reading and saving of data as well as the program coding of TRANSYT.
References to such cards is now limited to sections of this User Guide covering TRANSYT
12 (or earlier) file formats, such as details on import to/export from TRANSYT 12.
Common (Network Default) cycle time

This value is the default cycle time for the network. In general most junctions in a
network will operate on this cycle time, although some junctions may operate two cycles
within this period (i.e. they will be double cycled). Furthermore, individual traffic stream
controllers can be set to use their own cycle time. Other controllers can then reference
these other cycle times instead of the “Network Default”.

(Give-way) Conflict
A give-way conflict is any movement of traffic which has a direct effect on another.
Therefore, a give-way conflict between one movement of traffic and another does not
necessarily involve paths that cross, e.g. traffic turning left from a major to a minor road
still affects the capacity of traffic out of the minor road even though their paths do not
cross – This is regarded as a give-way conflict. The more effects like this the user chooses
to model the more accurate the model will be. ‘Conflicts’ within the context of traffic
signals, do involve paths that cross.
Conflict Shift
This is the delay between the controlling flow departing and the controlling flow starting to
influence the give-way. This has the effect of delaying both the increase in opposed flow
once traffic passes (e.g. clearance time), and also the drop in opposed flow when a platoon
of opposing traffic enters the junction (i.e. reaches the stop line). The influence of the
opposing traffic is essentially shifted (delayed) in time.
Conflict Duration
The duration over which the give-way traffic is being controlled. This prevents the flow
rising sooner. It represents the delay in drivers taking advantage of a drop in opposing
traffic. N.B. it has no influence during times when the opposing traffic flow is rising.
Congested Platoon Dispersion Model

The CPDM model is an adaptation of the standard PDM model developed by TRL which
replaces the flare model used in previous versions of TRANSYT.
Controller Stream
The TRANSYT controller stream contains all the signal control data associated with the
junction (or part thereof) it is controlling. The controller stream is a replacement for the
TRANSYT 13 signal node” which no longer exists in TRANSYT 16. It is equivalent to a
single stage stream, within a traffic controller.
Controlling link/link share

These links (or Link Shares) form part of the give-way model in TRANSYT. They are the
links (or Link Shares) containing traffic streams to which traffic on side roads must give
way.
Controlling traffic stream / traffic stream movement

These traffic streams (or movements) form part of the give-way model in TRANSYT. They
are the traffic streams (or movements) to which traffic on side roads (or other
‘controlled’ traffic) must give way.
Cruise time

Page 634
This is the average time it takes for a vehicle to progress down a link.
Cyclic flow profile

The cycle time for a junction is divided into a number of time intervals known as steps.
For each link the cyclic flow profile is a histogram giving the flow along the link for each
step of the cycle, as defined by the TRANSYT traffic model.
Cycle Time Optimiser

This is a TRANSYT tool to aid in the selection of a suitable cycle time. It can also be used
to assist in the selection of the available multiple-cycling options for each controller
stream within the network being modelled. Please note that the functionality provided
by the older CYOP tool has been discontinued.
Degree of saturation (DoS)

This is the ratio of flow to capacity on a link or traffic stream. Account is taken of the
green time given to the link per cycle when calculating this value, as well blocking effects
and oversaturation effects. Also known as RFC (Ratio of flow to capacity). If this value is
over 100%, the traffic stream (or link) is over-capacity.
Degree of Saturation weighting (link)

This is a weighting given to DoS on a link. It can be used to either deter the optimiser
from producing signal timings which give unduly high DoS or too low DoS on the link. A
combination of weights in both directions will encourage the optimiser to producing
signal timings that achieves the target DoS.
Demand Set
Several sets of traffic flows can be stored in TRANSYT, and then combined as needed
when the file is run. Each set of flows is a demand set. A typical use is to store flows for
morning and evening peak periods separately and then select the desired set to run.
Demand sets can be combined to model e.g. base flows plus development flows, which
are stored separately.
(Queueing) Delay
This is delay incurred by vehicles on a traffic stream (or link) as a result of them having to
queue up and stop because of the signals at the junction at the downstream end of the
traffic stream (or link), or because of having to give-way at a priority junction.
Delay weighting (link or traffic stream)

This is a weighting given to delays for a link. It is used to deter the optimiser from
producing signal timings which give unduly high delays for selected links. Conversely, it
may be used to encourage the optimiser to increase delays.

Displacement - Relative Start Displacement

This is a local (traffic stream or link) version of the global start displacement which is
added to the global start displacement value. It is used to modelling extra-long start
displacements on particular links where it is needed. In previous versions of TRANSYT
effective green displacements would have been specified as longer than usual start lags.
Displacement - Relative End Displacement

This is a local (traffic stream or link) version of the global end displacement which is
added to the global end displacement value. It is can be used to modelling any effective
green extensions not already explicitly modelled by TRANSYT.
In versions of prior to TRANSYT 14 it would have been used to model clearance of right-
turners during the intergreen and other bonus greens, which are now explicitly modelled
in TRANSYT. In versions prior to TRANSYT 13 effective green displacements would have
been specified as end lags instead.
Double Cycling
Traffic signals within a network are commonly operated on the same common cycle time.
Double cycled nodes are nodes set to operate on a cycle time which is half of the
common network cycle time. This is called double cycling.
Drive-on-the-left / Drive-on-the-right
‘Drive-on-the-left’ indicates that vehicles travel along the left-hand-side of the road, as in
the UK and Japan. ‘Drive-on-the-right’ indicates that the vehicles travel along the right-
hand-side of the road, as in mainland Europe and the USA.
Early cut-off
An early cut-off is a staging arrangement designed to benefit traffic having to turn right
(in drive-on-left countries) through an opposing traffic stream at a signalised junction.
The traffic opposing the right turners is stopped earlier than the right turners, in order
that the right turners can finally turn unopposed.
Effective green time

The effective green is the time used for modelling purposes to compensate for the time
taken to reach saturation flow at the start of green, and the time into the end-of-green
amber (and possibly red) treated as green by drivers. The relationship between the
actual green time for a stage (or phase) and effective green is defined by the start and
end displacements (both local and global). Effective greens can also be used to model
other effects.

Page 636
Effective green displacements

These are the displacements between the start and end of actual green on a link and the
start and end of effective green respectively. (Referred to as start-up and end lost-time
in RR67). These ‘global’ values work in conjunction with local (link) relative start and end
displacements.
EQUISAT (Discontinued)
EQUISAT has been replaced with the “Auto Redistribute” option. EQUISAT produced, for
each node, initial green splits which equalised saturation for the most saturated links
which determine the green needed by each stage.
(Traffic) Entry Profile Type

When analysing a junction over a time period that is broken into time segments,
TRANSYT can automatically assign traffic demand flows to each time segment that vary
over time in a predictable way (given a set of base flows), or they can be entered directly
by the user. The following demand profile types are defined: FLAT (traffic flow remains
constant over the time period); DIRECT (flows entered directly for each time segment by
the user); and GAUSSIAN, which are intended for modelling peak periods when flows
start off low, climb to a maximum and then decline towards the end of the time period.
Flared approach
This is an approach which flares out towards the stop line to provide an extra short bay
or bays (or ‘pockets’) - Now modelled in TRANSYT using the CPDM model.
(Cyclic) Flow pattern graphs

Graphs produced as part of TRANSYT’s output which represent, for each traffic stream (or
link), the arrival and departure flow at the stop line for each step of the cycle.
Give-way with satflow (give-way bottleneck)

A give-way traffic stream (or link) that operates under two different conditions – as a
standard give-way AND also operates during a period of the cycle where the opposed
traffic is only restricted by a (usually higher) saturation flow, such as when opposed
traffic technically gives way but it knows that the opposing traffic is not present, due, say,
to the presence of nearby upstream traffic signals which are on red.
Give-way link
A link that must give way to another link, link share, or links which have priority over it. It
can be at a priority intersection or a signalised intersection.

Give-way traffic stream

A traffic stream that must give-way to another traffic stream or traffic steam
‘movement’, or traffic steams which have priority over it. It can be at a priority
intersection or a signalised intersection.
GO-profile
The GO-profile is the cyclic pattern of traffic that would leave the stop line if there was
enough traffic to saturate the green.
Graph analyser
The part of the GUI program which plots a variety of pre-defined graphs, such as CFP,
Queue and P.I.-versus-offset graphs that can aid in visualising these aspects of link
performance.
HDV
Heavy-duty-vehicle. This term is used in the vehicle composition for the exhaust
emissions model.
Hill climb
One of TRANSYT’s signal optimisation processes.
(Phase) Intergreen
A phase intergreen is the length of time (in seconds) that is the minimum between the
end of one conflicting phase and the start of another, defined mainly for safety reasons.
The Intergreen Matrix specifies the intergreen between each conflicting pair of phases.
N.B. now that phases are specified directly in TRANSYT, the TRANSYT-specific term ‘Link
intergreen’ is no longer used.
Initial offset
The offset from the arbitrary starting time of the start of stage 1. Unlike previous
versions of TRANSYT, initial offsets are now only set by dragging the timings (using the
timings Diagram) to the required starting point. The ‘no longer necessary’ Initial Offset
data item has been removed.
Interstage
The interstage is defined as starting from the termination of the first green in a stage
(which also signals the end of the stage) to the commencement of the last green starting
in the next stage.

Page 638
IN-profile
The IN-profile is the cyclic pattern of traffic which would arrive at the stop line at the
downstream end of the link if the traffic were not impeded by signals at the stop line.
Journey Time Equilibrium (Flow Assignment)

Journey Time Equilibrium assignment (Beckmann, 1956) is a method of ‘assigning’ traffic
to a network in such a way that it reaches a Wardrop ‘user equilibrium’ (1952). The
assigned flows will result in a situation where each driver will have chosen the least
expensive route and any change in route of any one driver will result in higher costs for
that individual as well as higher costs for that particular route within the network.
Drivers are not assumed to cooperate in any way, but instead seek the lowest cost route
unilaterally. The overall effect is to achieve equalised costs across alternative routes
within the network (based on the particular cost term(s) used - in TRANSYT’s case this is
journey time).
Lag (start lag)

No longer used in TRANSYT. See Relative Start displacement.
Lag (end lag)

No longer used in TRANSYT. See Relative End displacement.
Lane
A lane is used to define in the model, the physical number of lanes that are on-street. As
a result generally, there will one TRANSYT lane for every ‘real’ lane. One or more lanes
are always part of a “traffic stream”. Most of the modelling data is associated with
traffic stream and not the lane. In a similar way that link shares are used, TRANSYT
“traffic streams” represent the modelling situation for lanes. See traffic streams for more
information on this. The use of lanes is not compulsory as TRANSYT allows a link
structure to be used instead, and TRANSYT will allow a mix of links and lanes to be used,
with defined restrictions only at the boundaries between the lane model parts and the
link model parts of the network.
Late Release
An arrangement of stages whereby the phase for opposing traffic starts after that for the
opposed traffic. In other words, opposed traffic initially gets a clear run, but later on has
to give way to oncoming traffic.
Level of Service
A subjective description of traffic performance measured at intersections. It indicates the
quality of the service afforded by any junction. TRANSYT uses the Level of Service
thresholds from the US Highway Capacity Manual 2000.

Link
A link is a one-way traffic stream between junctions. A separate link is used for each
distinct queueing situation. Thus, for example, two straight ahead lanes can form part of
the same link providing traffic queues equally in them. (This can only occur if a
movement is shared, and the exit(s) are largely unrestricted).
Link Share
This is a collection of links (one or more minor and one major) which have been defined
as ‘sharing’ a combined saturation flow. Although this particular term is new to TRANSYT
14, the concept of the shared link system is not. The term is used wherever reference to
a particular “link share” is required; such when defining the controlling type of a conflict.
(Local) Location
A traffic entry and exit point which acts as both the origin and destination for flows
defined in a Local OD Matrix. At least two locations will normally be required.
(WIDE-AREA) Location
A traffic entry point which acts as the origin for flows defined in a WIDE-AREA OD Matrix
using the WIDE-AREA Assignment Tool. At least two WIDE-AREA locations will normally
be required.
Lost Flow
This is an optional output of the flow overlay. It represents the amount of traffic that fails
to get onto each part of the network. It is calculated by comparing the difference
between the scaled demand (i.e. total (demand) flow scaled by the vehicle flow scaling
factor) and the achieved flow (what is ultimately in the modelled network)
(Link) Lost Time

This is the total lost time during a full cycle – the sum of stage-to-stage IG values, minus
the 1-second per traffic stage to allow for extra effective green. If the cycle includes a
fixed-time stage, such as a full pedestrian stage, the duration of the fixed length green is
added to the lost time. Links receiving green in consecutive stages green have the
relevant effective IG removed from the calculation. Links with non-consecutive greens
with red in-between are treated as multiple-cycled and the greatest part of the cycle
used to calculate the lost time.
Maximum Queue Storage

This is the maximum number of PCUs that can queue along the entire length of a link or
traffic stream. For links, it was previously known as “Link Capacity”. TRANSYT calculates
a rough estimate of this value itself, but it can also be overwritten by the user. For traffic
streams the assumed PCU length is user-definable. For a definition of maximum queue
storage see section 22.2.4.

Page 640
Mean maximum queue

The average position of the stationary vehicle furthest from the stop line each cycle,
measured in number of PCUs (or vehicles) rather than distance units.
If a ‘+’ symbol is present, this indicates the queue exceeds the user-defined maximum
queue storage value. If this value has not been specified by you, the ‘+’ symbol indicates
instead when the queue exceeds the internally calculated maximum queue storage value.
Mean modulus of error

This value relates to the degree of bunching, or platooning of an arrival flow. The more
closely platooned, the more an arrival flow would benefit from co-ordination of signals.
The value ranges from 0 to 2. A zero MME indicates a Uniform arrival, whereas a high
MME indicates a closely bunched platoon.
Minimum cycle time

This is the minimum possible cycle time of an individual controller stream, based on its
currently selected stage sequence.
(Network) Minimum possible cycle time

This is the minimum possible of cycle time for the network, based on the currently
selected stage sequences of each controller stream.
Network
A network is a collection of links, traffic streams, lanes and controller streams modelled
within TRANSYT.
(Traffic) Node
This is a TRANSYT graphical representation of an intersection. In modelling terms it less
relevant in TRANSYT 15 than in versions prior to TRANSYT 14. Its main use is to assist in
identifying and automatically disabling “paths” through the network. They are also
useful in identifying the physical junction that traffic passes through, allowing the
junction to be manipulated more easily in the network diagram, and more importantly,
it provides a mechanism to get TRANSYT to produce results for each junction.
NetCon (Network Construction Editor)

The name previously used to describe the Network Diagram in TRANSYT versions 12, 13
and 14.
‘Normal’-profile
This is the colour-coded combined representation of both the cyclic in-profile and out-
profiles of traffic.

(Local) OD Matrix
Defines the flows between Origins and Destinations of individual junctions or small
networks. Origins and Destinations are defined by Local Locations. Within a section of
the network Paths are defined and together with the turning flows, flows can be assigned
to Links or Traffic Streams (total flows) and the Connectors between links or Traffic
Streams (source flows). Flows are either entered directly into the OD matrix or derived
from the traffic assignment of wide-area OD-matrix flows.
(WIDE-AREA) OD Matrix
Defines the flows between Origins and Destinations of complete networks, or sections of
a network for which OD Matrix flows are known but full knowledge of traffic movements
within the area covered by the matrix data isn’t. Origins and Destinations are defined by
WIDE-AREA Locations. Within a section of the network WIDE-AREA Paths are defined to,
from and through local matrices. Together with the connections between local matrices,
local OD matrices are populated with traffic data from the WIDE-AREA matrix.
Subsequently, these local matrix flows are applied to individual links and traffic streams
using the chosen Allocation mode.
Offset
The offset for a junction is the time at which stage 1 starts relative to the arbitrary time
zero for the network and hence also relative to the other junctions in the network.
Additional user-defined offsets can also be defined, allowing offsets between particular
nodes to be displayed in the output.
Opposed Traffic
Traffic making an offside movement which must give way to oncoming vehicles. For
drive-on-the-left situations (as in the UK), this applies to right-turning traffic.
Opposing Traffic
The oncoming stream of traffic to which opposed traffic must give way.
OUT-profile
The OUT-profile is the cyclic pattern of traffic which leaves a link.
Passenger Car Unit (PCU)

A unit of measurement of traffic flow or capacity - equivalent to that of a single car.
Individual vehicle classes are given different PCU values (for the purpose of traffic capacity
calculations).
PCU values vary from country to country and also depend upon the number of vehicle
categories used. E.g. when using just two categories light vehicles and heavy vehicles (i.e.
‘lights and heavies’) PCU values used are typically 1 and 2 respectively. (See RR 67
section 3.2, page 4.) In the UK typical values for six categories are as follows:

Page 642
Vehicle type description PCU factor

Bicycles 0.2
Motorcycles 0.4
Cars/light goods (3/4 wheels) 1.0
Medium goods (two axles but > 4 tyres) 1.5
Buses, coaches 2.0
Heavy goods (more than two axles) 2.3
For the purposes of modelling pedestrians they too can be given a PCU value. (Pedestrians
never mix with any other type of traffic so there is no need to assign a value relative to
vehicle types etc.)
Path
This is a form of continuous route. A TRANSYT “Path” is a defined path, in terms of a
specific sequence of underlying links, between an OD pair (i.e. between one origin
Location and one destination Location) within a section of the network relating to a
particular OD Matrix. It therefore contains only underlying links which are consistent, i.e.
each link is downstream of the previous link.
(Wide Area) Path

Similar to a local “path”, a wide-area path is an underlying item in TRANSYT between a
wide-area OD pair (i.e. between one wide-area location and another). These paths are
used during the UE assignment process to represent the feasible routes taken by traffic.
Path Segment
Part of the underlying network structure created when there are traffic streams using in a
network. None of the path segment data is editable, or of any particular value to users of
TRANSYT. Path segment results can be useful at times and can be enabled via TRANSYT
Network > Options > Calculate results for path segments.
PCU length
This is the amount of space each PCU takes up on average in a single stationary queue,
i.e. front bumper to front bumper distance. It is a global user-defined value used by
TRANSYT to estimate the maximum number of PCUs that could fit within a traffic stream,
when this information is not provided by the user. It is not used for links.
Pedestrian Crossing Object

Pedestrians are modelled within their own network using pedestrian crossing objects.
Use of pedestrian crossings has a number of significant advantages over the now
obsolete pedestrian links. They are bi-directional – i.e. one crossing represents
pedestrian movement in both directions. They model walk-on-red behaviour and they
can be excluded from contributing to the Performance Index calculations. They have

their own specific representation within the TRANSYT data structure and in the network
diagram. Their results are reported in separate tables from vehicular results tables.
Pedestrian Link
Link Sources (upstream links) can be defined as pedestrian only links in TRANSYT. These
links are treated more-or-less the same as ‘normal’ traffic links except that they can be
excluded from contributing to the Performance Index calculations. They are now
obsolete in TRANSYT, but are recognised in imported older files - See Pedestrian Crossing
Object.
Ped Gap Accepting Penalty

This is the penalty cost (£ per hour) added to the P.I. as a result of the level of pedestrian
gap-accepting set by you, being exceeded. It is only applicable to pedestrian walk-on-red
situations.
Performance Index
This value represents the overall costs incurred by vehicles on traffic stream and links.
The costs are made up of queue and stop costs, plus any penalty costs, such as queue
limit or DoS penalties.
Phase (Australian terminology)

See “Stage” definition. This is the direct equivalent in TRANSYT. Used only when the
alternative “phase/stage display name” option is selected.
Phase (UK terminology)

A phase is a set of signal conditions given to one or more traffic streams or links
(vehicular or pedestrian) so that each stream (or link) allocated to the phase receives
identical signal indications. The phasing is closely related to the electrical cabling at a
junction and the arrangements for wiring individual signal heads to the controller. All
signal heads controlled by a particular phase will switch at the same time.
A phase can control more than one traffic stream providing it is acceptable that each
traffic stream always receives the same signal indications. Some traffic streams can be
controlled by two associated phases, such for right-turn indicative arrows.
Also see TRANSYT’s “Signal Phase” and “Signal Phase 2”.
*Platoon dispersion
TRANSYT data inputs a single cruise speed or cruise time for traffic travelling along a
traffic stream (or link). In reality, some traffic travels faster, some slower, than this
average. To take account of this, the TRANSYT model takes flow entering a traffic stream
(or link) and disperses the platoon as it travels down the traffic stream. This models the
variation in vehicle cruise speeds as they progress down the traffic stream.

Page 644
Platoon dispersal coefficient

This is the coefficient which determines how much a platoon is dispersed as it travels
down a link.
Practical Reserve Capacity (PRC)

This gives the percentage by which the arrival rate on a stream could increase before the
stream would be at practical capacity. It is given by 100(p-x)/x where x is the degree of
saturation and p is the maximum acceptable degree of saturation. (NB the calculation is
different for opposed streams). The Junction PRC is the lowest stream PRC. A junction
that has a PRC of 100% can cope with double the amount of traffic, and a junction with a
PRC of 0% is handling the maximum acceptable amount of traffic. Reserve capacity can
exceed 100%.
Priority Object
A priority object is a TRANSYT data item that stores the geometric properties of either a
priority T-junction, Crossroad or a Roundabout.
Queues
Queues are streams of stationary traffic at a stop line or other constriction, such as a give-
way line or bottleneck.
QUEPROB
A component of TRANSYT GUI (previously an independent supplementary program) that
estimates the average number of vehicles able to use a flare during each green. It is not
needed if using the TRANSYT Flare model instead of ‘quick’ flares.
Random + oversaturation delay

The component of the delay and stops model which takes account of delays and stops
due to random traffic arrivals and oversaturation.
Random Parameter
This is a modelling coefficient that relates to the calculation of vehicle delay. The term
defines the randomness of the queueing situation on a traffic stream (or link). In
TRANSYT this item is often set to 0.5 (partly random) for signalised networks and to 1.0
(fully random) for unsignalised junctions, although there is scope to set it directly.
Repeated greens
This is the situation where one (or more) stages receive more than one green during any
one cycle.
RFC
Ratio of demand flow to capacity (see also Degree of Saturation).

Route
A user-defined subset of the links within the network. Unlike Paths, Links within a route
can be duplicated and do not adhere to any ordering rules.
RTIA
Road traffic impact assessment
Saturation flow
This is the maximum rate of discharge from a queue when the traffic signal is green. It
can be obtained by measurement or calculation based on stop line width and other site
factors. (See RR 67)
(Cell) Saturation flow

The Cell Transmission Model interprets this value as a link saturation flow, i.e. traffic
entering and travelling along the link is constrained by this maximum. However, the
traffic crossing the downstream stop line is still constrained by the normal Saturation
Flow.
Saturation flow source

This defines the source of the saturation flow used. This can be the sum of the lanes
within the traffic stream or can be directly entered for the whole of the traffic stream.
Shared stop lines

This is a facility which allows you to model various streams of traffic or various classes of
vehicles sharing the same road space. When using the link structure to define your
network, it is used at signalised roundabouts to keep the various origin-destination
movements separate on the same link (this improves the accuracy of the model). It can
also be used to model buses and other traffic separately. Also see the TRANSYT term
“Link Share”.
Shotgun Hill climb

Shotgun hill climbing in TRANSYT is an optimisation technique where different initial
signal timings are selected more-or-less randomly and run one after the other, using the
standard hill-climbing process. Any run that improved the objective (P.I.) will
automatically replace the existing one. This is an effective way to improve the overall
optimisation process, as in many cases, the extra time required to carry out multiple runs
is repaid in significantly better results. It is essentially a trade-off between speed and
performance – the more runs you do, the better potentially are the results. The benefits
are largely file-specific as there is no guarantee that different starting points will produce
significantly better results.

Page 646
Signal Controller
TRANSYT uses (signal) “controller streams” rather than a signal controller object. A signal
controller is represented by a collection of one or more controller streams, i.e. a signal
controller with parallel stage streams would have multiple controller streams. Each
controller stream will control one junction (or part of a complex junction, such as a
signalised roundabout or a linked staggered junction).
Signal Group (Australian terminology)

See “Phase” definition. This is the direct equivalent in TRANSYT. Used only when the
alternative “phase/stage display name” option is selected.
Signal Phase
See “Phase” definition. This is the direct equivalent in TRANSYT. Also see TRANSYT’s
“Second Phase”.
Second Phase
A second signal phase can be defined. This allows a particular traffic stream to be
controlled by more than one phase, as in the case of a right-turn indicative arrow
situation. If either the “Phase” or “Second Phase” is green the traffic stream or link is
deemed to be green.
Simulation (Model)
The Simulation model is an adaptation of the original Queue Simulation model first
introduced into Junctions 8, and subsequently extended in Junctions 9.
The model has been considerably enhanced for use in TRANSYT - in particular by adding
the ability to model journey (cruise) time between junctions.
Simulated Annealing
Choosing this option changes the main part of the TRANSYT optimisation process to use
this alternative optimisation technique as part of its overall optimisation process. It is a
technique which can be effective at finding an acceptable set of good signal timings
within a reasonable time period, rather than necessarily finding the best timings. The
name comes from metallurgy, in which by heating up a material and letting it cool down
it allows more initial freedom (while hot) of changes within the structure.
Slope coefficient
A coefficient used in the TRANSYT give-way model. It is a measure of how much traffic
can cross a give-way link through another stream of traffic. This coefficient can be
calculated using ARCADY or PICADY or directly through the new TRANSYT “Priorities”
model.

Stage (UK terminology)

A stage is a part of the signal cycle during which a particular set of non-conflicting phases
receives green, and during which there are no phase changes. Each two successive
stages are usually separated in the signal cycle by an interstage period. The start of a
stage occurs when the last phase running in the stage turns to green, and the end of a
stage occurs when the first terminating phase reaches the end of its green period.
Consistent with this definition, individual phases may continue to run beyond the end of
the stage, or may start before the stage starts.
A TRANSYT 12 STAGE is defined as starting from termination of the first green in the
previous stage to the termination of the first green in that stage, hence includes the
preceding interstage.
Stop weighting (link)

This is a weighting given to stops on a link. It is used to deter the optimiser from
producing signal timings which give unduly high stops on the link.
Steps
The TRANSYT model divides the network cycle time into a number of steps (usually
representing 1 second each) for modelling purposes.
Stop penalty
This is a penalty which deters the optimiser from producing signal timings which will
give unduly high stops on a link.
Stream
Vehicle flows from one or more lanes which are considered together for calculation
purposes.
TDD
An abbreviation used in TRANSYT to refer to a ‘time-distance diagram’. Time-distance
diagrams are used to display the state of progression (good or bad) of traffic from stop
line to stop line by plotting traffic flow over time and distance.
Time-Dependent Queueing Theory

Theory for predicting average queue lengths (averaged over many occasions) taking
account both of the systematic variation of 'average' demand flow and capacity in time
and of random fluctuations in these quantities due to individual vehicles.

Page 648
(Modelled) Time Period

TRANSYT can be used to analyse the operation of a network over a set period of time,
which is typically 1 hour or 120 minutes, but can be longer if required. Over this time
period, the signal timings in the network are assumed to be constant and will either be
the optimised signal timings produced by TRANSYT or else a set of evaluation timings
provided by you. TRANSYT reports both the average delays and queues, etc. for the time
period and also those that would be expected on average at the end of the time period.
If the junction is over-capacity, then delays and queues will increase as the time period
increases. Also see time segment.
Traffic Flow
The quantity of vehicles (measured in PCUs) or pedestrians arriving at a particular point
on a link (e.g. a stop line) or passing a particular point, per unit time.
Timing Wheel
This is a network diagram item that displays stage timings for the controller stream it
belongs to. It allows offsets and stage times to be edited directly from within the
network diagram. Optionally, cycle split times can also be displayed.
Traffic Stream (TS)

This is the most fundamental object associated with a TRANSYT lane structure (as
opposed to a link structure). In general, one traffic stream is required to represent each
distinct queueing situation that occurs. One traffic stream may represent two or more
lanes, provided that traffic is equally likely to join the queue in any of the lanes and that
identical signal indications are shown to these lanes. For those familiar with TRANSYT
network link structures, it is the nearest equivalent to a major link and all its minor links
combined.
The traffic stream defines many fundamental aspects of the model, such as traffic flows,
give way data, traffic movement, conflicts, etc. Each traffic stream is made up one or
more lanes. Lanes themselves carry very limited information, i.e. saturation flows and
associated geometric data that goes into the saturation flow calculations.
The modelling of traffic streams, rather than simply using isolated lanes is fundamental in
ensuring that an accurate model is created. Modelling lanes in isolation to each other
would lead to, in many cases, a rather poor model, as it would be without consideration
of the real behaviour of traffic and the way that lane changes occur, queues form, and
delays occur.
N.B. for convenience references in the user guide will often be abbreviated to “TS”.
Occasionally, where space is at a premium, this abbreviation is used in TRANSYT itself.

Traffic Stream Movement

This is a term used to represent a particular movement of traffic from one traffic stream
into another. It is referred to when defining give–way conflicts, as TRANSYT now allows
any number of conflicts to be defined and for traffic movements to give-way to both
particular traffic movements as well as complete traffic streams, links and link shares.
Time Segment
When analysing a network over an extended time period, the time period can optionally
be split into several time segments of shorter length. This allows varying traffic
conditions to be modelled. Traffic flows are assumed to be constant within each time
segment, but may vary from one time segment to the next. Signal timings are assumed
to be constant over the entire time period. Output results are reported for both
averages over all time segments and for each segment giving a detailed breakdown of the
network performance over the modelled time period.
Triangular PDM (TRANSYT 8S)

This is a platoon dispersion model based on a symmetric triangular distribution of link
travel time, made available as an alternative to the standard (geometric) PDM. It
aims to replicate the model used in Chilean TRANSYT 8S.
Uniform delay
This is the delay incurred by the average number of vehicles queueing on a link during the
typical cycle.
User Equilibrium (UE) Flow Assignment

See Journey Time Equilibrium.
Utilised storage (%)

This is an estimate of how much road space on a traffic stream (or link) is filled with traffic
when the back of the queue is at its longest. It helps identify where blocking problems
might occur. Values close to or over 100% are likely to block the upstream junction.
Vehicle-In-Service
This is a modelling factor that relates to the calculation of queues and delay. It is
included if vehicles have to slow down or stop, as at priority junctions, or not included if
they can move freely across the stop line, as during the green phase at a traffic signal. It
can be set directly to cater for ‘ambiguous’ modelling situations.
Walk on red (pedestrian) model

This is the term used to describe the new pedestrian behaviour model in TRANSYT. It
extends the capability of TRANSYT such that it can predict the number of pedestrians that
will cross during the red man as well as during the green man, i.e. the level of non-

Page 650
compliance is predicted, as well as giving more accurate predictions of delays to

pedestrians.
Weighting factors
These factors allow you to modify all stop and delay weightings by a fixed percentage. In
this way you can check whether or not it would be beneficial changing these values.

References Page 651
BECKMANN, M, McGUIRE C and WINSTEN C (1956). Studies in the Economics of

Transportation, CT: Yale University Press.
BINNING J C, M R CRABTREE and G L BURTENSHAW (2010). TRANSYT 14 User Guide. TRL
Application Guide AG 65. Crowthorne: Transport Research Laboratory.
BINNING J C, G L BURTENSHAW and M R CRABTREE (2008). TRANSYT 13 User Guide. TRL

Application Guide AG 63. Crowthorne: Transport Research Laboratory.
BINNING J C (2006). PICADY 5 User Guide. TRL Application Guide AG 56. Crowthorne:
Transport Research Laboratory.
BURTENSHAW G L (2015). JUNCTIONS 9 User Guide. TRL Application Guide AG 72.

Crowthorne: Transport Research Laboratory. (Incorporates ARCADY 9 and PICADY 9)
BURTENSHAW G L and J C Binning (2009). ARCADY 7 User Guide. TRL Application Guide AG
64. Crowthorne: Transport Research Laboratory.
BURTENSHAW G L and X Zhang (2006). OSCADY PRO User Guide. TRL Application Guide AG
59. Crowthorne: Transport Research Laboratory.
DAVIES P and B JAMIESON (1980). Traffic signal control of roundabouts. Traffic

Engineering and Control, 19(7), July 1980, 354-357.
DEPARTMENT for TRANSPORT ET AL (2006). TD 35/06 All Purpose Trunk Roads MOVA
System of Traffic control at Signals, Design Manual for Roads and Bridges (DMRB)
Volume 8.
DEPARTMENT for TRANSPORT ET AL (2003). Environmental assessment, section 3 –

environmental assessment techniques – part 1 – air quality, Design Manual for Roads and
Bridges (DMRB) Volume 11.
DEPARTMENT for TRANSPORT ET AL (2006). Traffic Advisory Leaflet 1/06 Part 4 –

“General Principals of Traffic Control by Light Signals Part 4 of 4”
DEPARTMENT for TRANSPORT ET AL (2009). Local Transport Note 1/09 – “Signal

Controlled Roundabouts”
DEPARTMENT for TRANSPORT ET AL (2006). Traffic Advisory Leaflet 1/06 Part 4 –

“General Principals of Traffic Control by Light Signals Part 4 of 4”
FLANAGAN T B and R J SALTER (1983). Signal-controlled roundabouts. PTRS summer

annual meeting, University of Sussex.
GIBSON J and M WITYK (1988). Especificacion y comparacion de modelos de dispersion

del trafico para tecnicas de simulacion basadas en histogramas ciclicos de flujo. Actas del

Page 652
V Congreso Panamericano de Ingenieria de Transito y Transporte, Universidad de Puerto

Rico.
HILLIER J A (1965). Glasgow experiment in Area Traffic Control. Traffic Engineering and
Control, Vol.7, No 8 (Dec), pp 502-509, and Vol.7, No 9 (Jan 1966), pp 569-571.
HOLROYD J and J A HILLIER (1971). The Glasgow experiment: PLIDENT and after.
Department of the Environment, RRL Report LR384. Crowthorne: Road Research
Laboratory.
KIMBER, R M and ERICA M HOLLIS (1979). Traffic queues and delays at road junctions.
Department of the Environment Department of Transport, TRRL Report LR 909.
Crowthorne: Transport and Road Research Laboratory.
KIMBER R M (1980). The traffic capacity of roundabouts. Department of the Environment

Department of Transport, TRRL Report LR 942. Crowthorne: Transport and Road Research
Laboratory.
KIMBER R M and R D COOMBE (1980). The traffic capacity of major/minor priority

junctions. Department of the Environment Department of Transport, TRRL Report SR582.
Crowthorne: Transport and Road Research Laboratory.
KIMBER R M, M McDONALD and N B HOUNSELL (1986). The prediction of saturation

flows for road junctions controlled by traffic signals. Department of Transport, TRRL Report
RR67, Crowthorne: Transport and Road Research Laboratory.
PEIRCE J R and K WOOD (1977). BUS TRANSYT - a user’s guide. Department of the
Environment Department of Transport, TRRL Report SR 266. Crowthorne: Transport and
Road Research Laboratory.
ROBERTSON D I (1968). TRANSYT - a traffic network study tool. IVth International

Symposium on the Theory of Traffic Flow, Karlsruhe, Germany.
ROBERTSON D I (1969). TRANSYT: a traffic network study tool. Ministry of Transport,

RRL Report LR 253. Crowthorne: Road Research Laboratory.
ROBERTSON D I and R A VINCENT (1975). Bus priority in a network of fixed-time signals.

Department of the Environment, TRRL Report LR 666. Crowthorne: Transport and Road
Research Laboratory.
ROBERTSON D I, C F LUCAS and R T BAKER (1980). Co-ordinating traffic signals to reduce

fuel consumption. Department of the Environment Department of Transport, TRRL
Report LR 934. Crowthorne: Transport and Road Research Laboratory.
VINCENT R A (1972). Area traffic control in Bern. Traffic Engineering and Control, Vol 13,
No 10.

References Page 653
WEBSTER F V (1960). Greenford roundabout experiment. Traffic Engineering and Control,

2(5), September 1960, 266-271.
WRIGHT P T and M C Semmens (1984). An assessment of the Denham roundabout

conversion. Traffic Engineering and Control, 23(9), September 1984, 422-426.
WARDROP J (1952). Some theoretical aspects of road traffic research. Proceedings

of the Institution of Civil Engineers, Part 2, 1952, pp. 325–378.
References (CTM)
Crabtree M. (2002). Modelling opposed right-turn movements in TRANSYT – Part 1.
Traffic Software News, 20. TRL.


DEPARTMENT for TRANSPORT ET AL (1999). Assessment and preparation of road schemes

– Section 1 - Preparation and implementation – Part 3 – TA 79/99 Incorporating
Amendment No 1, Design Manual for Roads and Bridges (DMRB) Volume 5.
Daganzo C. (1994). The cell transmission model: a dynamic representation of highway

traffic consistent with the hydrodynamic theory. Transportation research-B, 28 (4) 269-
287.
Daganzo C. (1995). The cell transmission model, Part II: network traffic. Transportation
Research-B, 29 (2) 79-93.
Lighthill M J and Whitham J B (1955). On kinematic waves: I. flow movement in long

rivers; II. a theory of traffic flow on long crowded road. Proceedings of Royal Society,
A229, pp 281-345.
Richards P I (1956). Shockwaves on the highway. Operations Research 4, 42-51.
References (TRANSYT LINKS)

BINNING J C, G Burtenshaw (2014). TRANSYT-VISSIM LINK 2 User Guide.
Supplement to TRL Application Guide - AG70. Crowthorne: Transport Research
Laboratory.
BINNING J C (2013). TRANSYT-Aimsun LINK 2 User Guide. Supplement to TRL

Application Guide - AG70. Crowthorne: Transport Research Laboratory.

Page 654
The pedestrian behaviour at traffic signals modelling algorithm used within this program
is used under licence from Transport for London.
TRL’s UTC System is wholly owned by TRL Limited
SCOOT is co-owned by TRL Limited, Dynniq and Siemens Traffic Controls Ltd.
SCATS® is a registered trade mark of the Roads and Traffic Authority of New South Wales,
Australia and other countries
TRANSYT-7F (an adaptation of TRL’s original TRANSYT 7 software product) is developed

and maintained by McTrans (University of Florida).
Synchro is a registered trademark of Trafficware Ltd.
LinSig is owned by JCT Consultancy Ltd.
Windows, Windows 8, Windows 10 and Outlook are registered trademarks of Microsoft

Corporation.
TRANSYT uses an implementation of the ‘Mersenne Twister’ random number generator

which includes the following copyright notice:
A C-program for MT19937, with initialization improved 2002/1/26.
Coded by Takuji Nishimura and Makoto Matsumoto.
Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The names of its contributors may not be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Ownership and Copyright Page 655
TRANSYT uses a number of other open source libraries. For all other copyright and
licencing notices please see the relevant text file(s) in the main TRANSYT product folder
Other products and company names mentioned herein may be the trademarks of their
respective owners.

Page 656
TRANSYT 16 can import data from TRANSYT 15.0, TRANSYT 15.1 and TRANSYT 15.5 files
by using the standard File > Open menu or the Open icon.
TRANSYT 16 permits only one set of Fuel parameters to exist within the data file. If an
imported file contains multiple sets of parameters, only the one that is currently being
used in the file will be imported. If wish a particular set to be imported you will need to
set the “Use fuel Parameter” to refer to the one you wish imported using TRANSYT 15.0
or TRANSYT 15.1, then save the file, and only then open the file in TRANSYT 16.
TRANSYT 16 can import data from TRANSYT 14 files by using the standard File > Open
menu or the Open icon. If you want to see only TRANSYT 14 files when browsing you can
still use the Import facility by selecting File>Import>From TRANSYT14 and then browse
for your “.T14” file.
During the import process you may be shown one or more warning messages or given
options about how to import certain items.
 Given the difference in appearance between the network diagram in TRANSYT 14

and TRANSYT 16, the network may not appear exactly as it did in TRANSYT 15.
 Most data items that existed in TRANSYT 14 still exist in TRANSYT 15 and
therefore will be brought into TRANSYT 15. Their location within the data
structure may have changed. Please consult the TRANSYT 15 User Guide and use
the Data Filed Finder if you have difficulty finding a particular item.
 Where the TRANSYT 14 traffic model chosen is “CPDM” this will be translated into
the “Flare” Model” in TRANSYT 15
 Pedestrian links will not be converted into new TRANSYT 15 pedestrian crossings.
We however recommend that you do so, particularly if you are interested in
modelling pedestrian behaviour. Pedestrian links cannot now be created in
TRANSYT 15 other than through the import (or copying) of existing ones, as this
feature is now obsolete in TRANSYT 15.
 Report options will not be imported – Imported files will use your default settings
within TRANSYT 15.

Appendix A – Importing files Page 657
TRANSYT 16 can import data from TRANSYT 13 by simply using the standard File > Open
menu or the Open icon. If you want to see only TRANSYT 13 files when browsing you can
still use import by selecting File>Import>From TRANSYT13 and then browse for your
“.T13” file.
 Given the difference in appearance between the network diagram in TRANSYT 13

and TRANSYT 16, the network may not appear exactly as it did in TRANSYT 13.
 There is no longer a T12Mode in TRANSYT 16, so TRANSYT 13 files using this

‘signals mode’ will have their signal timings converted when imported.
 TRANSYT 13 files using T12mode do not contain intergreens, but use start lags to
define the interstages/intergreens instead. It is safest that TRANSYT 16 does not
derive intergreens from these values, so TRANSYT adds equivalent phase delays
instead, in order to ensure that the imported file retains the signal timings it is
importing. Without these, the interstages would be lost altogether.
Subsequently, you can choose to remove the phase delays and replace them with
intergreens as required.
 TRANSYT 13 did not allow the CTM cell saturation flow to differ from the stop line
saturation flow. Therefore, when importing a give-way link with control type
“None” the TRANSYT 16 “cell saturation flow” is set to the highest value of the
TRANSYT 16 default (for the cell saturation flow) and the imported maximum flow
value.
 Due to the extended options that TRANSYT 16 now offers you may wish to
review/examine your imported file to ensure that you making best use of
TRANSYT 16 and that you are modelling your network in the best way possible.
TRANSYT 16 can import data from TRANSYT 10, 11 and 12 by simply using the standard
File > Open menu or the Open icon. If you want to see only TRANSYT 10, 11 and 12 files
when browsing you can still use import by selecting File>Import>From TRANSYT 7-
SET/10/11/12…and then browse for your “.DAT” file.
To import Dutch “.IN” TRANSYT files you can use File>Import>From TRANSYT 7-
SET/10/11/12…, and changing the “Files of type:” from TRANSYT 12 (*.dat)” to
“TRANSYT 7-SET”.

Page 658
If the TRANSYT 12 file has an associated TRANSYT 12 network diagram (.nce) file, it will be
found and loaded automatically. Otherwise, you will be prompted to locate the .nce file;
simply Cancel this screen if you need to.
If a TRANSYT 12 network diagram (.nce) file was supplied, then TRANSYT 16 will load this
in and position nodes and links according to this file. Given the difference in appearance
between the network diagram in TRANSYT 12 and TRANSYT 16 however, the network
may not appear exactly as it did in TRANSYT 12.
If no network diagram file was supplied, then showing the network diagram window in
TRANSYT 16 will auto-arrange the network into a circular shape, making it easier to re-
position the diagram items.
Check the Task List after importing, as there may be warnings and errors that would not
have shown up in TRANSYT 16. In general, TRANSYT 16 checks for more problems than
does TRANSYT 12, therefore a file that ran in TRANSYT 12 may show errors or warnings in
TRANSYT 16.
N.B. Data items that are represented differently in TRANSYT 16 will be automatically
converted on import to the new representation, e.g. -9999 (‘zero’) delay weightings will
be converted to the equivalent 0% weightings.
TRANSYT 12 files do not contain intergreens, but uses start lags to define the
interstages/intergreens instead. It is safest that TRANSYT 16 does not try to derive
intergreens from these values, so TRANSYT adds equivalent phase delays instead, in
order to ensure that the imported file retains the signal timings it is importing. Without
these, the interstages would be lost altogether. Subsequently, you can choose to remove
the phase delays and replace them with intergreens as required. This is recommended if
you are planning to change the stage sequencing to prevent them from wrongly
restricting the optimiser from finding the best timings.
Importing a file from TRANSYT 10/11/12 will automatically set the random delay mode to
“Simplified (TRANSYT12)” mode.
Running an evaluation run of a TRANSYT 12 file in TRANSYT 16 should produce a similar

overall Performance Index but will not always be exactly the same. In many cases this
will be due to various modifications and bug fixes that have been included in TRANSYT
16. If in doubt, please send your data file(s) to TRL for comment.
Import files from TRANSYT-7F by selecting File>Import>From TRANSYT 7F and then

browse to your .TIN file. During the import process you may be shown one or more
information messages or given options about how to import certain items.
It is recommend that you check the Task List after importing, as there may be warnings
and errors that would not have shown up in TRANSYT-7F. In general, TRANSYT 16 checks

for more and different problems than does TRANSYT-7F. Furthermore, due to differences
in the two products, TRANSYT 16 ‘interprets’ rather than simply ‘reads’ many of the
TRANSYT-7F data items. Therefore, a file that ran in TRANSYT-7F may show errors or
warnings in TRANSYT 16.
A summary of, to what extent data is imported from each TRANSYT-7F Record Type is as
follows:
Imported? Record Type – Record Description
Fully
2 – Optimisation Node List
7 – Shared Lanes
1X – Controller Timing
18 – Controller Timing
2Y – Phasing Data*
2Z – Phasing Data Continuation
28 – Link Data
30 – Performance Index (PI) weighting
34 – Queueing Capacity Modifier
35 – Cruise speed multiplier
36 – Volume Multiplier
37 – Delay Weight Multiplier
38 – Stop Weight Multiplier
39 – Platoon Dispersion Factors
40 – Flow Profile Diagrams
42 – Arterial Routes
Route Title Card
61 – Route Link
70 – Node Coordinates
Intersection Name Record
Link Name Record
*Excluding the “actuated phase flag”
Partially
1 – Run Controls

Page 660
10 – Network Parameters
29 – Link Data Continuation
291 – Link Data Further Continuation
9X – Termination Instructions
Not at all
3 – Movement Numbering
4 – Hill-Climb Optimisation Step Sizes
5 – Associated Links
6 – Hill-Climb Sensitivity Parameters
8 – Model Coefficients
31 – Link-to-Link Flow Weighting
32 – Queueing Ratio Weighting
33 – Throughput Weighting
41 – Bandwidth Constraints
43 – Arterial Weighting
5X – Run Instructions
60 – Route Parameters
71 – Link Curvature
Anyone importing a TRANSYT-7F file should be aware of the following:
TRANSYT 16 will load in and position nodes and links according to this file.
TRANSYT 16 interprets both the TRANSYT-7F “standard” link numbering
scheme and the “NEMA” scheme in order to minimise any differences
between the layouts. However, it does not attempt to interpret custom
numbering schemes.
Given the differences in the data items and appearance between TRANSYT-7F
and TRANSYT 16, the network may not appear exactly as it did in TRANSYT-7F.
However, we believe you will benefit considerably from the obvious visual
superiority of TRANSYT 16.
Network-wide start-up lost time is rounded to the nearest second when

imported as the network-wide “Start Displacement”. Similarly, the default
extension of effective green is rounded when imported as the “end
displacement”
Sneakers are not imported. It is down to you to manually add back in the
capacity benefits of sneakers either by explicitly modelling the space in front

of the stop line or adding equivalent phase “relative end displacements” at a

suggested rate of 2 seconds per sneaker.
Imported files are brought into TRANSYT as a link structure rather than a
lane/traffic stream structure. However, where a link represents multiple lanes
it is relatively easy to identify this situation from the link’s high saturation
flows.
You may notice some visual disparities between the TRANSYT-7F Lane
Configuration screen and the network diagram. This can be due to the
following:
o the network diagram displays traffic movements of each individual link

(including all shared links) or traffic stream, rather than each lane. This
makes it easier to see how the network model has been defined. N.B.
“User Movements” are purely visual – they do not affect results.
o Some movements “defined as “Thru” in TRANSYT-7F which are actually

turning movements, as defined by “feeders” and link positions, will
show correctly as turning movements in the network diagram.
There are no “arterials” in TRANSYT 16 – both “arterials” and “routes” are

imported as TRANSYT 16 “collections”.
The direction of routes (forward/back) is not specifically recorded in TRANSYT

16 – Therefore, the direction of imported “reverse” routes are retained by
recording the direction in the TRANSYT 16 Route ID by appending it with the
letter “R”.
TRANSYT-7F “Queuing Capacity Modifiers” are imported as modified “Max

Queue Storage” values.
NEW: All permitted movements (i.e. up to three) are now imported (TRANSYT
13 was limited to importing only the first two).
TRANSYT-7F “phases” are interpreted as TRANSYT “stages”.
Yellow and Red intervals are converted into TRANSYT gaining delays on each
link to represent the interstages. You may wish to replace these and populate
the intergreen matrix instead. Also note that the Red and Yellow intervals
associated with a particular TRANSYT-7F “phase” is associated with the
following TRANSYT 16 “stage” due the difference in how TRANSYT-7F “phases”
and TRANSYT 16 “stages” are defined
Because the opposed right-turn model in TRANSYT 16 is different to that in

TRANSYT-7F, a careful examination of the give-way parameters after
importing is recommended, as well as reading the relevant sections of this
User Guide on this particular topic.

Page 662
All TRANSYT imports assume that traffic flows are in PCU. TRANSYT can be
changed to interpret values as vehicles, and a mix of traffic types can also be
added. This however, can be done AFTER importing the assumed PCU flows.
Finally, there are many modelling options that are in one product but not the other,
e.g. the Cell Transmission Model in TRANSYT 16 and the various permitted-movement
models in TRANSYT-7F. Therefore, consideration should be made of the impact these
differences will have when comparing results between the two products. Having said
that, there is considerable commonality in both the data specified and the modelling
features of these products, hence essentially they can be used to “do the same job”.
This import facility does not import network data directly from Synchro 7, but rather via a
CSV file. Therefore you must export your network from Synchro to a CSV formatted file
(This facility resides within Synchro) and then use the import facility to import the CSV
file data into TRANSYT.
File>Import>From Synchro 7 CSV (Beta) and then browse to your .CSV file. During the
import process you may be shown one or more information messages or given options
about how to import certain items. The import process brings in as much data from the
CSV file as it can, i.e. what is compatible with TRANSYT and also makes sense within the
context of a TRANSYT network.
Please note that this option is an ‘experimental’ beta feature of TRANSYT and
as such is not fully supported by our standard product maintenance contracts. However,
if you experience difficulty using it we would encourage you to still inform TRL Software.
We will offer assistance if possible.
TRANSYT imports heavy vehicle percentages as well as total traffic movement volumes.
The imported traffic data are converted into “Light” and “Heavy” traffic types.
This import facility does not import network data directly from LinSig 3, but rather via a
RTF file. Therefore you must export your network from LinSig to a RTF formatted report
file, and then use the import facility to import the RTF file data into TRANSYT. To help
with this, the first time you use the import facility, TRANSYT will allow you to save a
special report template which you can use. This should then be used to capture the data
in a form that TRANSYT will understand.
To import your report file (based on the supplied template), select File>Import>From
LinSig 3 RTF report… and then browse to your .RTF file. During the import process you
may be shown one or more information messages or given options about how to import
certain items.

It is recommend that you check the Task List after importing, as there may be warnings
and errors that would not have shown up in LinSig. In general, TRANSYT 16 checks for
different problems compared to LinSig. Furthermore, due to differences in the two
products, TRANSYT 16 ‘interprets’ rather than simply ‘reads’ some of the LinSig data
items. Therefore, a file that ran in LinSig may show errors or warnings in TRANSYT.
Currently the network layout is not imported.

Page 664
TRANSYT needs accurate average traffic flows in order to provide good predictions of
network performance. Often other systems, models or products exist, from which
suitable flow data can be extracted. Such a product is SCOOT (Split Cycle and Offset
Optimisation Technique) – a fully adaptive traffic control system for managing and
controlling networks of coordinated traffic signals.
SCOOT coordinates the operation of all the traffic signals in an area to give good
progression to vehicles through the network. Whilst coordinating all the signals, it
responds intelligently and continuously as traffic flow changes and fluctuates throughout
the day. It removes the dependence of less sophisticated systems on signal plans, which
have to be expensively updated.
TRANSYT 16 has a facility to assist in the transfer of flow data from SCOOT into TRANSYT.
This facility is accessed from Tools>SCOOT>Import SCOOT Link flows.
Figure 35-1 Importing SCOOT flow data

However, before importing any data, a TRANSYT network must be constructed which
contains links that can then be matched up with corresponding data imported from
SCOOT. Each link that you wish to import flow data to must be associated with a
particular SCOOT link ID (see screen-shots below). This is done either by setting each
TRANSYT link ID to reference the correct SCOOT Link ID or by setting the Link Name to
the SCOOT Link ID. Note that TRANSYT links must be used rather than TRANSYT traffic
streams.
TRANSYT obtains the flow data from SCOOT M02 messages (see Figure 35-2), therefore
within SCOOT, M02 messages must be set up to be produced. The rate at which these
are generated (usually every 5 minutes or every cycle length) is decided by the SCOOT
operator.

Appendix D – Import SCOOT data Page 665
The SCOOT flow data is reported in units that are most closely match those of
a PCU, rather than a vehicle. You can tell TRANSYT what traffic flow units you are using
(PCU or vehicles), and therefore we recommend that you indicate that the flows are in
PCU when you are importing SCOOT data, and that saturation flows are also specified in
PCU. Switching units does not change the data entered.
Figure 35-2 Example file containing SCOOT M02 messages

On selecting Tools>SCOOT>Import SCOOT Link flows the following dialog box is displayed
requiring the following to be set:
Number of SCOOT Messages to Average: Specify the number of SCOOT messages that
will be imported which contain the traffic flow data. The TRANSYT Link Total Flow will be
calculated from the average of the flow read from each message. M02 messages
containing error messages (which indicate the flows may be inaccurate) will trigger a
warning message to the user. If all of the messages read for a particular link contain no
flow data the TRANSYT Link Total Flow will not be changed
SCOOT Message File: The path and name of the SCOOT file containing the SCOOT
messages.
Match SCOOT ID’s with TRANSYT Link Names instead of IDs: This option should be set if
you wish to match the TRANSYT Link Names to the SCOOT Link IDs. This allows you to
retain the original Link IDs that you may have in an existing TRANSYT file.
Exclude messages with fault status: This option determines what TRANSYT does with
the flow data in messages with a fault status. When this option is set, TRANSYT ignores
the flow data and averages only the flow data of the remaining faultless messages.
When this option is not set, the flow data is always used.
TRANSYT is not tolerant of the “/” character in Link ID’s as it is a reserved

character used to identify traffic streams. Therefore, the Import Dialog is used to set a
replacement character if and when a “/” appears in a SCOOT data file.

Page 666
SCOOT character: This sets which character in the SCOOT file is to be replaced. It is most
commonly the “/” character that needs to be replaced (the default).
TRANSYT character: This sets which character is used to replace the SCOOT character
defined in the above “SCOOT character” data field.
Figure 35-3 Flow Import Dialog

On pressing the Import button, TRANSYT will import flow data from the chosen SCOOT
file and will report what Links it has imported flow data from (see screen shot).
Figure 35-4 Confirmation of imported flow data

The resultant flows (average over the M02 messages) are applied directly to the Link
Total Flow values.
No knowledge of turning proportions are imported, so source flows will still

need to be specified within the TRANSYT network before sensible results can be
produced. Zero source flows won’t naturally cause any errors or warnings to appear in
the task list, but the Link Flow Consistency Tool (and the network diagram Flow
consistency overlay) will clearly show where source flows (i.e. turning proportions) are
required.

Appendix E – Import SCATS data Page 667
TRANSYT needs accurate average traffic flows in order to provide good predictions of
network performance. Often other systems, models or products exist, from which
suitable flow data can be extracted. Such a product is SCATS (Sydney Co-ordinated
Adaptive Traffic System) - an advanced computer system that monitors and controls
traffic signals in real-time.
TRANSYT has a facility to assist in the transfer of flow data from SCATS into TRANSYT.
This facility is accessed from Tools>SCATS>Import SCATS Volume flows.
Figure 36-1 Importing SCATS flow data

However, before importing any data, a TRANSYT network must be constructed which
contains controller (streams) and links that can then be matched up with corresponding
data imported from SCATS. In the TRANSYT network the TRANSYT controller streams ID’s
must match the controllers within SCATS. Links must also be associated with a particular
SCATS detector (see screen-shot below). This is done by setting the link’s Detector data
item (Outline: Links>Link n>Link Flows) to reference the correct SCATS detector(s). If
multiple detectors are associated with one link the flow data for the link will be set to the
average of the imported detector flows.
Note that TRANSYT links must be used rather than traffic streams.

Page 668
Figure 36-2 Associating TRANSYT Links with SCATS Detectors

On selecting Tools>SCATS>Import SCATS Volume flows the following dialog box is
displayed, that allows the Peak Start time, Peak Length and which folder contains the
SCATS flow data (i.e. the File Directory) to be entered.
Additionally the format of the filenames of the files containing the required flow data
must also be entered. TRANSYT will search all files with a filename matching the defined
format in the specified folder, e.g. Using the format ”Set {0}.txt” will search for data
within “Set 057.txt”, “Set 164.txt”, etc.
Figure 36-3 Flow Import Dialog

The “Exclude error codes” option determines what TRANSYT does when an error code
instead of a flow value is present in the data file. If set, these are ignored; otherwise the
errors will be interpreted as a zero flow.
On pressing the Import button, TRANSYT will import flow data from all relevant files and
will report what files (Controllers) it has imported data from (see screen shot). Some
advice on how to create the required data files is given in section 36.2.

Figure 36-4 Confirmation of imported flow data

The resultant flows, average over the imported time period, are applied directly to the
Link Total Flow values.
No knowledge of turning proportions are imported, so source flows will still

need to be specified (or revised) within the TRANSYT network before sensible results can
be produced. Zero source flows won’t naturally cause any errors or warnings to appear
in the task list, but the Link Flow Consistency Tool (and the network diagram Flow
consistency overlay) will clearly show where source flows (i.e. turning proportions) are
required.
The ‘dump’ file includes all the detector information for a whole day for a configured Region
recorded by 5 min intervals, providing the default “read all records” tick box remains ticked.
Each period is tagged with a label – example “Friday 17 March 2017 23:55”. All intersections
are included.
TRANSYT now offers the ability to import flow data into a link network structure from a
SCATS ‘dump’ file. To use this facility please follow these steps:
1. Rename the controller IDs in TRANSYT file to match those in the Dump file. N.B.
any leading zeros will be automatically stripped from ‘dump’ file controller ID’s.
2. Specify the location of your SCATS ‘dump’ file
3. Press the IMPORT button
Notes:
 Handles multiple days

 The importer will only overwrite flow data associated with the controller’s
represented in each dump file, so can import all in one go or incrementally using a
series of ‘dump’ files.
 Where a link references multiple detectors, the flow on that link will be set to the
average for the flows imported for these detectors.

Page 670
 It is not currently possible to use multiple files to average data, as part of the import
process. (This is subject to review)
This is a description of how you can create the required data files:
 “Open SCATS® Traffic Reporter.
A Data Selection window will appear
 From the window choose a “REGION” from the drop down list.
 Select “Traffic Flow” using the radio button.
 From the “Period” fields use the drop down calendars to select the same Start
date and End date.
 Press the OK button.
A Region Traffic flow selection window will appear:
 Choose a site by ticking the box.
 In the Select Approaches field select all the detectors for the site (up to 24 or 48
detectors depending on the version of Traffic Reporter)
 You may select the detectors associated with one or more approaches. At least
one set of approach detectors needs to be selected.
 In the “output type” field, select “column” with the radio button.
 Press the OK button.
The report will be produced.
 Choose File>Save As from the menu and save the file to a folder containing the
traffic volumes for use with TRANSYT.
 Repeat this process for all the sites in the model.
The output file should look similar to this:


Page 672
To switch on the calculation of the ‘Halfstarre’ TxC values you need to set the “File >
Preferences… > 6. Signals” option “Show TxC values” to true.
Additionally, in a VA system (Netherlands), there may be one or more detectors on each

road link. These are referred to as the first detector, second detector, etc. and with the
last detector numbered from upstream to downstream of the road link. To cater for a
platoon, the TxC time (moment) needs to be calculated as equal to the time when the
front of the platoon arrives at the location of the upstream first detector. Then, when
operating online, at time TxC, VA starts to monitor the platoon in order to seek a time to
end the phase. Therefore, in order to calculate TxC, TRANSYT needs to know the “first
detector location” so that it can use the flow profile at this particular point in the
network. This is specified on each Traffic Stream (or link) via the Data Editor (see screen
shots below). N.B. this input value currently does not appear in the dedicated traffic
stream or links data screens.
TRANSYT will only a calculate TxC value on links and traffic streams where a request has
been made to calculate it – see screen shots below. For Traffic Streams multiple flow
sources can be selected on the one traffic stream - When this is done, the TxC value is
calculated from the combined profile of all the selected flow sources. This particular
facility is provided in recognition of the fact that the TxC value needs to be calculated
from flows that come from one or more specific upstreams, such as those associated
with the main arterial flow through the network.

Appendix G – Calculating TxC Page 673
The calculated TxC moment is reported within the “Advanced” Results for each Link and
Traffic Stream.
To allow TRANSYT to detect the front of a platoon, a threshold value (default of 1 PCU
per green period) needs to be used to represent near-zero flows. This threshold can be
adjusted within the file (Data Outline: Network Options > Signals Options > Advanced).
This feature is intended to allow you to calibrate this particular value directly. It is not
envisaged that a different threshold will be required for each file.

Transyt 16 User Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Transyt 16 User Guide

Загружено:

Авторское право:

Доступные форматы

by James C Binning

© Copyright TRL Limited 2019. All rights reserved.

DD: +44 (0)1344 379777 | E: software@trl.co.uk | http://www.trlsoftware.com

First Published 2019

TRANSYT 16 User Guide (Issue A)

TRANSYT 16 User Guide (Issue A)

TRANSYT 16 User Guide (Issue A)

For program advice, sales and distribution information please contact:

TRL Software Sales

Telephone lines: +44 (0)1344 379777

Useful product-related links:

Knowledge base: www.trlsoftware.com/support/knowledgebase

Latest downloads: Contact TRL Software Sales

Training courses: www.trlsoftware.com/support/training

Version history: version history

TRANSYT 16 User Guide (Issue A)

2 Installing the Software .......................................................................................... 27

3 Quick Start Guide................................................................................................... 31

4 Vehicle Modelling Basics ....................................................................................... 55

5 Optimisation Basics ............................................................................................... 77

6 Simulation Model .................................................................................................. 79

7 User Interface operation ....................................................................................... 81

8 Data Entry............................................................................................................ 111

9 Special data-entry screens .................................................................................. 121

10 Data Grids ...................................................................................................... 143

11 Network Diagram ........................................................................................... 153

12 Three dimensional mode (3D) ........................................................................ 201

14 Working with Traffic Flows ............................................................................ 237

15 Working with Pedestrians .............................................................................. 275

16 Working with Traffic Signals .......................................................................... 295

17 Working with Flared Approaches................................................................... 343

18 Working with Priority Junctions ..................................................................... 355

19 Working with Traffic Models ......................................................................... 401

20 Working with Results ..................................................................................... 407

21 Generating Reports ........................................................................................ 427

22 TRANSYT Outputs ........................................................................................... 441

23 Simulation Mode ............................................................................................ 465

24 Analyser (X-Y Graph) ...................................................................................... 487

TRANSYT 16 User Guide (Issue A)

26 Traffic Behaviour Models (Non-simulation) ................................................. 503

27 Traffic Model Features in Detail..................................................................... 521

28 Optimisation in detail..................................................................................... 553

29 Modelling Examples ....................................................................................... 583

30 Modelling Signalised Roundabouts ................................................................ 595

31 Definitions / Glossary ..................................................................................... 629

32 References ...................................................................................................... 651

33 Ownership and Copyright .............................................................................. 654

34 Appendix A – Importing files .......................................................................... 656

35 Appendix D – Import SCOOT data .................................................................. 664

36 Appendix E – Import SCATS data ................................................................... 667

37 Appendix G – Calculating TxC ........................................................................ 672

TRANSYT 16 User Guide (Issue A)

1.1 About TRANSYT ............................................................................................ 18

1.2 Summary of TRANSYT 16 improvements ..................................................... 20

1.3 About this manual........................................................................................ 21

1.4 Training ........................................................................................................ 22

1.5 Student Edition............................................................................................. 23

1.6 Languages .................................................................................................... 23

1.7 Related Software ......................................................................................... 23

1.8 Product Background and Versions ............................................................... 24

1.9 Help Improve TRANSYT ................................................................................ 25

1.10 Acknowledgements ...................................................................................... 25

2 Installing the Software .......................................................................................... 27

2.1 Installing/uninstalling the software............................................................. 27