Transyt 15 User Guide

TRL Limited
APPLICATION GUIDE AG70 (Issue F)
TRANSYT 15
USER GUIDE
by James C Binning
TRL Limited 2013, 2014, 2015. All rights reserved.
TRL Software
Crowthorne House
Nine Mile Ride
Wokingham Berkshire
RG40 3GA United Kingdom
Software manufactured
under an ISO 9001 Tel: +44 (0)1344 770758
registered quality Fax: +44 (0)1344 770356
management system E-mail: software@trl.co.uk
www.trlsoftware.co.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 2013
ISSN 1365-6929
The pedestrian behaviour at traffic signals modelling algorithm used within this program is used
under licence from Transport for London.
SCOOT is co-owned by TRL Limited, Imtech Traffic & Infra UK Ltd and Siemens Traffic Controls
Ltd.
SCATS is a registered trade mark of the Roads and Traffic Authority of New South Wales in
Australia and other countries
Aimsun is a trademark of TSS-Transport Simulation Systems, S.L.
Aimsun is a product of TSS-Transport Simulation Systems, S.L.
VISSIM is a product of PTV AG
TRANSYT-7F (an adaptation of TRLs original TRANSYT 7 software product) is developed and
maintained by McTrans (University of Florida).
Synchro is a registered trademark of Trafficware Ltd.
Windows, Windows XP, Windows Vista, Windows 7 and Outlook are registered trademarks
of Microsoft Corporation.
WinZip is a registered trademark of WinZip International LLC.
Other products and company names mentioned herein may be the trademarks of their respective
owners.
TRANSYT 15 User Guide (Issue F)

ABSTRACT OF APPLICATION GUIDE AG70 2013
TRANSYT is a macroscopic off-line computer program for studying everything from

isolated road junctions to large signal-coordinated networks. Traditionally
TRANSYTs 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 15 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 others 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 users guide to the latest version
of TRANSYT software (TRANSYT 15) 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

TRANSYT 15 user guide
January 2015, Issue F (to accompany TRANSYT 15.1.0)
For program advice, sales and distribution information please
contact either TRL Software Sales or your local distributor.
TRL Software Sales:
TRL Software Sales

TRL
Crowthorne House
Nine Mile Ride
WOKINGHAM
Berkshire
RG40 3GA
United Kingdom
--------------------------------------------------------------------
Telephone lines: +44 (0)1344 770758

+44 (0)1344 770558
Fax: +44 (0)1344 770356
E-mail: software@trl.co.uk
Web site: www.trlsoftware.co.uk
Knowledge base: www.trlsoftware.co.uk/knowledgebase
Latest downloads: www.trlsoftware.co.uk/downloads
--------------------------------------------------------------------
Training courses: www.trlsoftware.co.uk/training
Webinars: www.trlsoftware.co.uk/webinars
Videos : www.youtube.com/TRLSoftwareChannel
--------------------------------------------------------------------
For traffic modelling, traffic auditing and traffic consultancy services

please contact our consultancy team:
Telephone +44 (0)1344 770758
E-mail: traffic@trl.co.uk

Page 6

CHAPTER HEADINGS
1 Introduction ........................................................................................ 17
2 Installing the Software ......................................................................... 25
3 Vehicle Modelling Basics ....................................................................... 29
4 Optimisation Basics .............................................................................. 49
5 How to use TRANSYT 15 ....................................................................... 51
6 Graphical User Interface (GUI) operation ................................................ 71
7 TRANSYT 15 Input Data ....................................................................... 97
8 Custom data-entry screens ................................................................. 105
9 Data Grids ........................................................................................ 127
10 Network Diagram .......................................................................... 137
11 Three dimensional mode (3D) ......................................................... 169
12 Working with Analysis Sets, Demand Sets and Time Segments ........... 177
13 Working with Traffic Flows .............................................................. 183
14 Working with Pedestrians ............................................................... 215
15 Working with Traffic Signals ........................................................... 235
16 Working with Flared Approaches ..................................................... 279
17 Working with Priority Junctions ....................................................... 289
18 Working with Traffic Models ............................................................ 337
19 Working with Results ..................................................................... 341
20 Generating Reports ....................................................................... 359
21 TRANSYT 15 Outputs ..................................................................... 369
22 X-Y Graph Analyser ....................................................................... 391
23 Additional Tools and Features ......................................................... 399
24 Traffic Behaviour Models (PDM/CTM/CPDM) ...................................... 405
25 Traffic Model Features in Detail ....................................................... 419
26 Optimisation in detail ..................................................................... 445

Page 8
27 Modelling Examples ....................................................................... 471
28 Modelling Signalised Roundabouts ................................................... 481
29 Definitions / Glossary..................................................................... 509
30 References ................................................................................... 529
31 Appendix A Importing files ........................................................... 533
32 Appendix B Export to TRANSYT 14 ................................................ 539
33 Appendix E Importing SCOOT data ............................................... 540
34 Appendix F Importing SCATS data ................................................ 543

CONTENTS
1 Introduction ........................................................................................ 17
1.1 About TRANSYT ........................................................................... 17
1.2 Summary of TRANSYT 15 improvements ......................................... 19
1.3 About this manual ........................................................................ 21
1.4 Training ...................................................................................... 22
1.5 Student Edition ............................................................................ 22
1.6 Languages .................................................................................. 22
1.7 Related Software ......................................................................... 22
1.8 Product Background and Versions .................................................. 23
1.9 Acknowledgements ...................................................................... 24
2 Installing the Software ......................................................................... 25
2.1 Hardware/software requirements ................................................... 25
2.2 Installing/uninstalling the software................................................. 25
2.3 Copy-protection and software registration ....................................... 25
3 Vehicle Modelling Basics ....................................................................... 29
3.1 Traffic Model Basic Assumptions .................................................. 29
3.2 Network representation ................................................................ 29
3.3 Relationship between real lanes and traffic streams ......................... 30
3.4 Relationship between real lanes and TRANSYT links ......................... 32
3.5 Flow, speed and link/stream/lane data ........................................... 33
3.6 Signal settings ............................................................................. 39
3.7 Traffic behaviour within a traffic stream or link ................................ 44
3.8 Delays, Queues and Stops ............................................................ 45
3.9 Maximum queues ......................................................................... 45
3.10 Give-way situations ...................................................................... 47
3.11 Shared stop lines on Links ............................................................ 47
3.12 Flared Approaches ....................................................................... 48

Page 10
4 Optimisation Basics .............................................................................. 49
4.1 Network timings optimisation ........................................................ 49
4.2 Cycle Time optimisation ................................................................ 50
5 How to use TRANSYT 15 ....................................................................... 51
5.1 Essential GUI terms you need to know............................................ 51
5.2 Quick start for new TRANSYT users ................................................ 51
6 Graphical User Interface (GUI) operation ................................................ 71
6.1 General ...................................................................................... 71
6.2 Getting help ................................................................................ 71
6.3 Accessibility ................................................................................ 72
6.4 Demo (and Viewer) mode ............................................................. 72
6.5 Keeping it simple ......................................................................... 73
6.6 Speed of operation and large files .................................................. 74
6.7 Main toolbars .............................................................................. 74
6.8 Changing the Active Data Item ...................................................... 77
6.9 Padlock system ............................................................................ 78
6.10 The 'Edit in Window' System ......................................................... 80
6.11 Types of Data .............................................................................. 81
6.12 Running Files and using Auto-Run .................................................. 85
6.13 Managing files ............................................................................. 86
6.14 Undo/Redo .................................................................................. 88
6.15 Copying data to the clipboard ........................................................ 89
6.16 Printing ...................................................................................... 90
6.17 Managing Windows ...................................................................... 90
6.18 Preferences Screen ...................................................................... 92
7 TRANSYT 15 Input Data ....................................................................... 97
7.1 Data Files ................................................................................... 97
7.2 Library Files ................................................................................ 97

7.3 Data Outline ................................................................................ 98
7.4 Data Outline Screen ................................................................... 100
7.5 Data Editor Screen ..................................................................... 102
7.6 Network Diagram ....................................................................... 103
7.7 Task List ................................................................................... 103
7.8 Data Field Finder ....................................................................... 104
8 Custom data-entry screens ................................................................. 105
8.1 Main (Common) Data Screen ....................................................... 105
8.2 Signals Data (controller stream) Screen ........................................ 108
8.3 Links Data Screen ...................................................................... 115
8.4 (Traffic) Streams Data Screen ..................................................... 120
8.5 Pedestrian Data Screen .............................................................. 124
9 Data Grids ........................................................................................ 127
10 Network Diagram .......................................................................... 137
10.1 Speed of operation ..................................................................... 138
10.2 Moving around the network ......................................................... 138
10.3 Saving, using and managing Views ............................................ 139
10.4 Printing, copying and exporting ................................................... 140
10.5 Representation of Links, Lanes and Stop Lines ............................... 140
10.6 Representation of controller streams and signal timings .................. 143
10.7 Manipulating items ..................................................................... 143
10.8 Viewing and visualising data in the network diagram ...................... 148
10.9 Network Diagram Options screen ................................................. 164
11 Three dimensional mode (3D) ......................................................... 169
11.1 Navigation within a 3D network ................................................... 170
11.2 3D Results ................................................................................ 170
11.3 Referencing/Adding 3D Models .................................................... 174

Page 12
11.4 Recording and Playing a Fly Through ......................................... 175
12 Working with Analysis Sets, Demand Sets and Time Segments ........... 177
13 Working with Traffic Flows .............................................................. 183
13.2 Link Data Screen ....................................................................... 186
13.3 Flow Consistency ....................................................................... 186
13.4 Flow Allocation and Assignment (Using Matrices) ........................... 189
14 Working with Pedestrians ............................................................... 215
14.1 The Pedestrian Behaviour Model .................................................. 215
14.2 Pedestrian Network Structure ...................................................... 216
14.3 Pedestrian Flows ........................................................................ 220
14.4 Overview of Data requirements ................................................... 222
14.5 Optimisation.............................................................................. 227
14.6 Pedestrian results and network animations .................................... 229
15 Working with Traffic Signals ........................................................... 235
15.1 Introduction to traffic signals in TRANSYT 15 ................................. 235
15.2 Overview of Signal Timings ......................................................... 242
15.3 Timings Diagram ....................................................................... 252
15.4 Timing Wheels ........................................................................... 262
15.5 Intergreen Matrix Screen ............................................................ 264
15.6 Stage Sequence Screen .............................................................. 271
15.7 Phase Delays ............................................................................. 273
15.8 Start/end displacements ............................................................. 274
15.9 Multiple cycle times .................................................................... 275
16 Working with Flared Approaches ..................................................... 279
16.2 Flared approaches - quick flares ................................................. 284
17 Working with Priority Junctions ....................................................... 289
17.1 What is a Priority Object?............................................................ 290
17.2 Using a Priority Object library file ................................................. 291

17.3 Applying a Priority Object to an existing network ........................... 293
17.4 Using an Arm, Traffic Stream and Lane Structure ........................... 297
17.5 Steps required using arms, traffic streams and lanes ...................... 297
17.6 Movements and Conflicts ............................................................ 301
17.7 Visibility Adjustment .................................................................. 304
17.8 Using Links to define your priority junction .................................... 304
17.9 Modelling crossroads .................................................................. 307
17.10 Modelling roundabouts ............................................................ 308
17.11 Using Links to define your roundabout ...................................... 313
17.12 Mutual opposition ................................................................... 314
17.13 Modelling variations of give-way ............................................... 314
17.14 Give-ways within signalled junctions ......................................... 320
17.15 Give-way simplifications you can make...................................... 332
17.16 Indirect traffic control and give-way bottlenecks ......................... 332
18 Working with Traffic Models ............................................................ 337
18.1 Traffic Model selection ................................................................ 337
18.2 Vehicle-In-Service and the Random Parameter .............................. 338
18.3 Setting Cell Saturation flows ....................................................... 340
19 Working with Results ..................................................................... 341
19.1 Summary Results Screen ............................................................ 341
19.2 Detailed results ......................................................................... 342
19.3 Animation controls ..................................................................... 343
19.4 Graphs ..................................................................................... 344
19.5 Time Distance Diagram ............................................................... 352
20 Generating Reports ....................................................................... 359
20.1 Report Configurator ................................................................... 359
20.2 About Report Files ...................................................................... 362

Page 14
20.3 Report Viewer ........................................................................... 363
20.4 File Comparison Utility ................................................................ 365
21 TRANSYT 15 Outputs ..................................................................... 369
21.1 Traffic model predictions ............................................................. 369
21.2 TRANSYT individual link or traffic stream predictions ...................... 372
21.3 TRANSYT network-wide results .................................................... 387
22 X-Y Graph Analyser ....................................................................... 391
23 Additional Tools and Features ......................................................... 399
23.1 Audit Trail ................................................................................. 399
23.2 Adding a Junction (Merging Networks) .......................................... 401
23.3 Drive-on-the-left/Drive-on-the-right ............................................. 403
23.4 Find Shortest/Best Route ............................................................ 403
24 Traffic Behaviour Models (PDM/CTM/CPDM) ...................................... 405
24.1 Platoon dispersion model (PDM) ................................................... 405
24.2 Cell Transmission Model .............................................................. 411
24.3 Congested Platoon Dispersion Model............................................. 415
24.4 PDM versus CTM ........................................................................ 415
24.5 Differences between the Flare models (CPDM and CTM) ............... 416
24.6 Restrictions on use of the CTM ..................................................... 416
25 Traffic Model Features in Detail ....................................................... 419
25.1 Signal settings ........................................................................... 419
25.2 Queues and Delays .................................................................... 419
25.3 Stops ....................................................................................... 421
25.4 Wasted green time ..................................................................... 423
25.5 Fundamentals of the Give-way Models .......................................... 424
25.6 Shared link stop lines ................................................................. 428
25.7 Bus and Tram Links .................................................................... 430
25.9 Collections and Routes ............................................................... 437

25.10 Fuel consumption estimates ..................................................... 439
25.11 (Flow) Assignment Model ......................................................... 442
26 Optimisation in detail ..................................................................... 445
26.1 The performance index ............................................................... 445
26.2 Network Optimisation selection .................................................... 450
26.3 Controller-specific Optimisation Levels .......................................... 451
26.4 Locking of stages between different controllers .............................. 453
26.5 Optimisation Type (and other Advanced Settings) .......................... 456
26.6 Queue-length reductions ............................................................ 460
26.7 Degree of Saturation limits ......................................................... 462
26.8 Pedestrian gap-accepting penalty ................................................. 463
26.9 Controller Stream Grouping......................................................... 463
26.10 Cycle time selection ................................................................ 464
26.11 Cycle Time Optimiser .............................................................. 465
26.12 Multiple cycling and repeated greens ......................................... 467
26.13 Considering the effect of small changes ..................................... 469
27 Modelling Examples ....................................................................... 471
27.1 Supplied Data Files .................................................................... 471
27.2 A small network (Example 1)....................................................... 471
28 Modelling Signalised Roundabouts ................................................... 481
28.1 About this chapter ..................................................................... 481
28.2 Introduction .............................................................................. 481
28.3 The TRANSYT program ............................................................... 482
28.4 Modelling a roundabout (Example 2) ............................................ 482
28.5 Checking co-ordination ............................................................... 494
28.6 Example 3 a signalised motorway roundabout ............................ 495
28.7 Example 4 an urban signalised roundabout ................................. 504

Page 16
28.8 Recommendations ..................................................................... 508
29 Definitions / Glossary..................................................................... 509
29.1 TRANSYT GUI Terms .................................................................. 509
29.2 Modelling and Traffic Engineering Terms ....................................... 510
30 References ................................................................................... 529
31 Appendix A Importing files ........................................................... 533
31.1 Import TRANSYT 14 files ............................................................. 533
31.2 Import TRANSYT 13 files ............................................................. 533
31.3 Import from TRANSYT 7-SET/10/11/12 ........................................ 534
31.4 Import from TRANSYT-7F............................................................ 535
31.5 Import from Synchro .................................................................. 538
32 Appendix B Export to TRANSYT 14 ................................................ 539
33 Appendix E Importing SCOOT data ............................................... 540
34 Appendix F Importing SCATS data ................................................ 543
34.1 Creating data files from SCATS data ............................................. 545
35 Appendix G Calculating TxC ......................................................... 546

Introduction Page 17
1 Introduction
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.
1.1 About TRANSYT

TRANSYT is a macroscopic off-line computer program for studying everything from isolated road
junctions to large signal-coordinated networks. Traditionally TRANSYTs 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 14 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 others 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.
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.

Page 18
Figure 1-1 The basic structure of the TRANSYT program
Many of the principles behind TRANSYT 15 are essentially the same as those at the heart of
previous versions of the program. However, TRANSYT 15 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 of previous versions will identify many modelling changes, concessions
have also been made to those familiar with previous versions of TRANSYT, where we thought it is
useful to do so.

1.2 Summary of TRANSYT 15 improvements

This section allows existing users of TRANSYT 14 to quickly familiarise themselves with what has
changed and what new facilities have been added to TRANSYT 15 by summarising the changes
and improvements. Full descriptions of the changes are to be found in other chapters.
Traffic Behaviour Modelling: Traffic Signal and other model features

Pedestrian crossing at signals behavioural Phase type property of phases added
model allow the modelling of walk-on-red
Tool to auto-calculate conflicts from
pedestrians
Network Diagram
Significant speed improvements for network
Tool to auto-calculate intergreens from
models
scaled Network Diagram
Improved (CPDM) advanced flare model
Option to auto-calculate traffic stream
Caters for multiple cycle times within the lengths from network diagram
one network
Auto-calculation of turning proportions
Calibration factor for turn-on-red situations and turning radii from network diagram
Auto-calculation of RR67 Saturation Flows
for major links and traffic streams
Traffic Flows:
Queue Probability Tool (QueProb) now
Explicit specifying of pedestrian flows integrated into each link
Improved OD Matrix features, e.g. filter Display of amber times
paths by location
Turning on red facility
Time-varying traffic flow conditions available
for Traffic Stream network structure File Import from and Export back to
TRANSYT 14
RR67 saturation flow estimation per major
link
More control over OD path generation Graphical User Interface:
New wide-area assignment facilities. New easier-to-use dynamic graphical user
interface
Choice of input units - PCU or vehicles
Improved responsiveness (especially when
Ability to add new traffic types with
using larger files)
associated PCU factors
Clutter and complexity reduction, i.e. new
file options to hide unrequired features
Optimisation: Limit cycle times to SCOOT values
Significantly faster optimisation using out- ability to update multiple alphanumeric
profile accuracy option items at once with the same value using a
Locking of a stage on one controller to a Data Grid
stage on another Useful for modelling Improved and extended data-specific
linked controller streams data-entry screens
Cycle Time optimiser enhanced to take Various other graphical interface
account of multiple cycle times in a network improvements
Enhanced flow and spatial graphs
Auditing Tools
Automated and fully-featured Audit Trail
Saves file changes as you work (Date, time facility
and username stamped)
Save file status (with option to auto-prompt
you each time you save a file)

Page 20
Priority Junctions: Technical

Priority crossroad objects calculate PICADY
give-way coefficients (slope & intercept)* 64-bit and 32-bit versions available
Assigning of give-way coefficients for Works with Windows 8

priority crossroads to links/traffic streams*
Roundabout object caters for multiple Documentation:
circulating traffic streams
Fully revised User Guide
Comprehensive set of Library Files
Network Representation/Diagram:
Redesigned throughout to improve ease-of-
use Results and Reporting:
New combined flow/queue animation of SCATS Split stage time (as a percentage
traffic cells (CTM) of cycle) as both an input and a resultant
value
Redesigned representation of signalised
pedestrian crossings New Report Configuration screen offering:
Simplified and improved signalled Ability to select or deselect any table,
pedestrian crossing representation graph or diagram
Integrated editable stage timing wheels Saving of user-defined report
Configurations
Follow me option to synchronise diagram
viewpoint with current data item Combined results for complex flares
Text output sets easier to select, display New output result: Utilised (queue)
and can now be stored for use with other storage
files.
New output result: separate vehicle and
Clearer text pedestrian summaries
3-D representation of network New pedestrian crossing outputs: e.g.
pedestrian flows during gap-accepting
3-D display of flow animations
period.
3-D generic display of data or results
Enhanced Queue and Cyclic Flow Profile
3-D artefact import (buildings, trees, etc.) graphs
Saveable 3-D fly-through of network Choice of units: PCU or vehicles
Combined flow/stopped traffic animation.
*needs ARCADY 7 or later and/or PICADY 5 or later
For those wishing to evaluate the differences between TRANSYT 15 and earlier versions, such as
TRANSYT 12, we recommend you contact TRL who will be more than happy to explain whatever
features you are most interested in.
Many other features
Please browse through this User Guide for information about the
many new features in TRANSYT 15, looking for the following symbol:

1.3 About this manual

The coverage of this user guide is intended for anyone who is likely to be involved with the use
of TRANSYT 15. 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 15, 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 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 icons 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;
is used to highlight features in TRANSYT 15 that are new to TRANSYT
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 29).
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.

Page 22
1.4 Training
TRANSYT, by its very nature, is a complex software product. Although we try to make our
product as easy to use as possible, and also 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 also 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 experience
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: www.trlsoftware.co.uk/training
1.5 Student Edition

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.
1.6 Languages
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.
1.7 Related 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:
TRANSYT Online
TRANSYT Online extends TRANSYT's functionality and allows optimised Signal Plans to be sent
directly to on-street controllers to allow frequent retiming without the need to go out on the
street in response to events. TRANSYT Online hosts a range of features, including the import of
live flow data into your TRANSYT network, regular scheduled signal optimisation, plan
deployment (automatic, timetabled or manual), and a variety of powerful features to support
plan creation, selection, deployment and monitoring.
TRANSYT-Aimsun LINK is a software tool that imports an Aimsun network into

TRANSYT 15 and then uses the TRANSYT signal optimiser in conjunction with the Aimsun model
to produce an optimum set of signal timings. Furthermore, it can be used to visualise, validate

and edit signal plans for an Aimsun network. Versions are available for TRANSYT 14 (Version 1)
and TRANSYT 15 (Version 2).
TRANSYT-VISSIM LINK is a software tool that imports a VISSIM network into

TRANSYT 15 and then uses the TRANSYT signal optimiser in conjunction with the VISSIM model
to produce an optimum set of signal timings. Furthermore, it can be used to visualise, validate
and edit signal plans for a VISSIM network. Version 2 of the link works with TRANSYT 15.
JUNCTIONS which includes
PICADY 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.
and
ARCADY 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 PRO is designed to model isolated (uncoordinated) signalised junctions. It is used

to assess performance of junctions in terms of capacity, queue lengths and delays. One of its
key features is its phase-based optimisation of signal timings to minimise delay, or maximise
capacity by automatically selecting suitable stage orders and associated phase sequences. This
allows very quick assessments of both simple and complex cases to be made. A facility to export
data TRANSYT is provided.
For further details of all these programs, and for latest news, current pricelists and purchasing
information, please visit www.trlsoftware.co.uk.
1.8 Product Background and Versions

Investigations carried out in the UK into possible improvements in traffic control of urban
networks in the 1960s 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 TRANSYTs 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 15
represents another significant advancement of the product in terms of its traffic models, its
features, and its presentation.
TRANSYT 15.0 (released in September 2013) is the first release of TRANSYT 15.

Page 24
1.8.1 TRL Update Information Server
It is useful to the user of any product to know whether or not the particular release they are
using is the most up-to-date available. In order to provide this information automatically, on
launching TRANSYT, it will try to connect to the TRL Update Information Server. If this
connection is achieved and/or permitted by the user (permanently or as a once-off), the bottom
horizontal status bar will display news concerning TRANSYT such as NEW TRANSYT 15.0.0.99
Version Available (as shown below) or 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 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 users will benefit from.
If, as matter of course, you normally enter a username and/or password

to gain access to, say, the internet on your PC, it will be THIS password
and user name you will need to enter to initially gain access to our server.
This information is securely encrypted within the users local profile and
is NOT tracked, recorded, or used by TRL, and its only purpose is to allow
your own PC to easily access this one particular (TRL) server.
If having read about a new release you wish to download it, current maintenance holders can go
to the TRL download system at http://www.trlsoftware.co.uk/downloads and follow the
instructions on the web page.
1.9 Acknowledgements
The work described in this report was carried out in the Transportation Division of the Transport
Research Laboratory. 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 for Transport, Energy 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 15
is used under licence from Transport for London.

Installing the Software Page 25
2 Installing the Software

2.1 Hardware/software requirements
TRANSYT 15 will run on any modern PC under Windows 8, 7, Vista or XP and as such there are
no specific hardware or software requirements other than those of a modern PC capable of
running standard 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
32-bit version of TRANSYT - Windows Vista / XP (32-bit or 64-bit)
64-bit version of TRANSYT - Windows 8 / 7 / Vista (64-bit only)
6 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 15 may run on versions of Windows other than Windows 8/ 7/ Vista and XP but this is
not guaranteed and is not formally supported.
2.2 Installing/uninstalling the software

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 SETUP.EXE (or similarly named file) from this temporary folder.
Alternatively, if you have been supplied with a product CD, browse the product CD for
SETUP.EXE (or similarly named file), and run this file. This will launch the product installer.
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.
2.3 Copy-protection and software registration

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 the TRL SOFTWARE.

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

registered versions of this product.
There are currently three states of TRANSYTs copy protection system stand-alone copy-
protection, network copy-protection (concurrent licence version) and Demo/Viewer. Usually,
versions are licensed on a per-site basis. Licences may also be time-limited, i.e. a Leased or
Evaluation licence.
Both the stand-alone and network copy-protection states are contained within the same
installation package, 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 15 requires either an add-in module

such as the TRANSYT-Aimsun LINK, or another product to be registered, such
as ARCADY and PICADY. Details of the TRANSYT LINKS are documented in
separate supplementary User Guides provided with TRANSYT. Details of what
added functionality is accessible if you have either ARCADY or PICADY is
described in section 17.1.
ARCADY and PICADY and the TRANSYT LINKS 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.
2.3.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
2.3.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.

Installing the Software Page 27
2.3.3 Demo/Viewer version
This version is described in section 6.4.
It can be downloaded for free from here: www.trlsoftware.co.uk/downloads. No download is

required simply enter your contact information and then select the TRANSYT Demo to
download.
This demonstration version cannot be registered. If you subsequently purchase

TRANSYT you will need to obtain a new version which you can then register.

Page 28

Vehicle and Network Modelling Basics Page 29
3 Vehicle Modelling Basics

This chapter gives an overview of the TRANSYT vehicular traffic model. Existing users of
TRANSYT 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.
However, TRANSYT is a complex program, so there are many references to the other chapters
throughout this one. These chapters will still need to be read in order to be able to correctly
model specific network features.
Note: 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
section 29.
3.1 Traffic Model Basic Assumptions

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.
3.2 Network representation

TRANSYT offers the users a choice of how to represent the real network being modelled either
using a series of nodes interconnected by traffic streams; nodes interconnected by links; or a
mixture of both. Each distinct one-way stream of traffic is represented either by at least one link
or by at least one TRANSYT traffic stream.
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 properties Has Restricted
1
time varying traffic conditions can also be modelled in TRANSYT

Page 30
Flow and Is Signal Controlled set to true. Has Restricted Flow allows a saturation flow rate
to be specified (see section 3.5.5). Unsignalled restrictions within the network such as a
bottleneck can be modelled by setting Has Restricted Flow but set as unsignalled. A
description of how each of these types of traffic stream and links is represented graphically in
TRANSYT is in section 10.5.
When 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.
3.3 Relationship between real lanes and traffic streams

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 3-1 and Figure 3-2. Figure 3-1 shows a simple
triangular road network. Figure 3-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 3-1 Network lane structure with flows
Figure 3-2 Model lane and traffic stream structure

Page 32
3.4 Relationship between real lanes and TRANSYT links

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 3-3 and Figure 3-4. Figure 3-1 shows a simple triangular road network. Figure 3-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 3-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 3-4 Diagram of links and nodes
3.5 Flow, speed and link/stream/lane data

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 3.6.
3.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 come from an upstream node, e.g. entry traffic stream
(or link) on the perimeter of the network, it is normal to use a length such as 100m or 200m.
Although a zero 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 data screen (See Figure 3-5).

Page 34
Figure 3-5 Traffic Stream Length (m)
The Auto Length option allows you to let TRANSYT work out the length of any
traffic stream (or link) automatically for you from the distances between items in
the network diagram. If this useful feature is used, your network diagram should
be scaled to ensure that distances correctly reflect real on-street distances.
3.5.2 Traffic flows
Traffic flows are either specified directly using the method described below or are assigned via
OD Matrices. See Chapter 13 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 (traffic flows; allocation mode and allocation type
selections) is 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.
3.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 the user must specify the average
total flow along the link.

Figure 3-6 Link Total flows
Each link may have associated with it a uniform flow source (see Figure 3-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 3.5.4).
Figure 3-7 Link Uniform Flows

Page 36
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.
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.
3.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.
3.5.4 Compatibility of link and traffic stream 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 link 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.
3.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 flows 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 (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.
3.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 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. Used by traffic streams
only.
(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.
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.
Turning Radius (m): The radius of turn is the approximate radius of the circle
described by vehicles as they make a turn, and should be left blank for straight
ahead movements. 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 Use Connector Turning Radius option allows you to let TRANSYT work out for
you both the proportion that turn and the turning radius automatically for you from
the network diagram. This option 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 useful feature is used, your network diagram should be scaled to ensure that
distances correctly reflect real on-street distances.

Page 38
3.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.
3.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 3.6), or may be modelled more accurately using the give-way facility
(see section 17.14).
3.5.6 Entry and exit links and traffic streams
For entry traffic streams (and links) on the perimeter of the network, having no upstream links
(or streams) but merely a total flow it is recommended, in order to maintain a reasonable
estimate of time spent within the network, to input a cruise time (or speed) for travel over the
Length of link (or stream) 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 entry traffic streams (and
links) offers no advantages and will slow down runs of TRANSYT so it is best to use 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 either the signal
optimisation or on the queue and delay calculations the Link Data screen option Exclude from
Results Calculation can be set. This effectively ensures that the PI for the link is always zero
and that output results, such as the Network Totals, are not affected by it.
If you do not want any queues to appear on exit links (or streams), both the Has Restricted
Flow and Is Signal Controlled options 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 dont 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 be set to an appropriate value (see section
18.3).
3.5.7 Restricted Flow (Bottleneck) links and traffic streams
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 is usually associated with a traffic node for
display and reporting purposes (either as a true bottleneck or as part of a priority junction), but no
controller stream is specified as it is not controlled by traffic signals.

Shared links which are bottlenecks are specified in the Shared Stoplines tab of the Links Data
screen (Outline: Links > Link n), in a similar way to signalised links, but the main link still has
only a traffic node and no associated controller stream.
Delays and stops are calculated for bottleneck traffic streams (or links) exactly as for other traffic
streams (or links, except that the flow leaving the traffic stream (or link) is controlled only by the
saturation flow. Thus, uniform delay and stops will occur only if the flow during parts of the
IN-profile exceed the saturation flow. Random-plus-oversaturation delay and stops are calculated
in the normal way (see section 25.2).
3.6 Signal settings

NB for details of the actual implementation in TRANSYT 15, please see sections 15 and
17.14.
3.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. A TRANSYT stage change time is a time at which the green signal on
one stage is terminated and the change to the next stage green period is initiated; the next stage
green usually commences a few seconds later, following an interstage period. 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 3-8.
The offset of an intersection is defined here as the stage change time when the change to green
for stage number 1 is initiated. 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 change to stage 1 and continues
through the other stages in sequence.

Page 40
Distance
Change to Change to
stage 1 stage 2
Node 1 Stage 1 green Stage 2 green
offset for 1 cycle for node 1

node 1
Distance
in offset
between
node 1 and
node 2
1 cycle for node 2
Change to Change to
stage 1 stage 2
Node 2 Stage 1 green Stage 2 green

offset for node 2
Time
Arbitary zero for time
Figure 3-8 Illustration of terms offset and difference in offset
If the offset value at one node is subtracted from that at an adjacent node, the difference in
offset defines the start of the cycle at one node relative to that at the other and hence defines
the co-ordination along any links connecting the two nodes.
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 3.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:
3.6.2 Signal values for whole network
These values are specified in the Main (Common) Data Screen (Outline: Network Options).
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 3-9 illustrates this concept.
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 TRANSYTs
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 3-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 3.6.3.5.
3.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.

Page 42
The Stage change times, part of the calculated stages data, are always shown in seconds.
Traditionally TRANSYT stage change times have been defined as the times at which a change of
signal aspect is initiated, as opposed to the genuine start of stage which starts only when the
last phase running in that stage, starts. TRANSYT now uses the later genuine definition;
however, it can (optionally) report some resultant timings using the older definition. These are
always in addition to the genuine times and are prefixed with the word TRANSYT, e.g. TRANSYT
Stage minimum.
3.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 TRANSYTs 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.
3.6.3.2 Phase Constraints

Phase constraints (phase-to-phase Intergreens) are specified via the Intergreen matrix screen.
Additionally, banned stage-to-stage to transitions are also defined here. Other phase data is
specified in the Signals Traffic Stream Data screen (Outline: Arm n >Traffic Streams > Traffic
Stream n > Link Signal Data) and Links Data screen (Outline: Links > Link n > Link Signal
Data.
Minimum and maximum green times can also be specified on each individual phase in order to
constrain phase lengths to what is required.
3.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
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 the user by specifying which stages they run, 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.
Internally, various parameters are derived from the user specified information and used
internally by the TRANSYT model. A network option can be set that reveals some of these
parameters in the Resultant Stages Data. Generally, they are only of interest to those
previously familiar with these parameters. Details of these parameters are in the TRANSYT 15
Outputs section 21.2.9
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.
3.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 (see section 15.7 for more on this). 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 (section 8.2.4) or manipulated
graphically in the Timings Diagram (section 15.3). Stage change times are always needed by
TRANSYT, and initial ones can be provided by using the Signal Option Auto Redistribute
(Repair timings) from the Tools menu of the Timings Diagram. See Figure 3-10 to see how phase
delays are presented in TRANSYT.
Figure 3-10 Absolute phase gaining delay and phase losing delay
3.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.

Page 44
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 15.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 21.2) so that the traffic engineer can easily compare
TRANSYT values with observations of actual 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.
3.7 Traffic behaviour within a traffic stream or link

TRANSYT 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 advantages and disadvantages. 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
junctions capacity. The PDM model 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 24 and on
cyclic flow profiles in Section 19.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 TRANSYTs 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 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 can be modified for individual 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.
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 3.12.
The CPDM model is NOT directly user-selected 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 24.
3.8 Delays, Queues and Stops

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 25.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.
3.9 Maximum queues

As part of the calculation of traffic behaviour on a link (or stream), 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 TRANSYTs platoon dispersion model (PDM) which assumes that all
vehicles queue at the stop line. TRANSYT does however include a facility whereby the user 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 26.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.

Page 46
3.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 3.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 3-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.
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 3-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.

3.10 Give-way situations

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 17 and section 25.5.
3.11 Shared stop lines on Links

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 25.6.
The user of the program 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.

Page 48
When representing your network using traffic streams and lanes instead of links, you should use
the facility within the OD Matrices to specify buses or trams separate from normal traffic.
3.12 Flared Approaches

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 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 3-12. It contrasts with
the constant, single valued, saturation flow for non-flared links or traffic streams.
sat.
flow
0 green time
Figure 3-12 Stepped saturation flow of a simple flare / short lane
For further details on modelling flares see chapter 16. This includes examples of the various
cases where flares are used. The custom screens used for data-entry of flare data are shown in
section 8.3 and 8.4.

Optimisation Basics Page 49
4 Optimisation Basics
This is only a brief overview of the TRANSYT optimiser. 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. However, TRANSYT is a complex program, so there
are references to other chapters. These chapters will still need to be read in order to know how
to use all the optimisation facilities correctly.
4.1 Network timings optimisation

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 excess queues on each 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 that can be 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 (P.I.) and the hill-climbing process
are explained in chapter 26
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 (Outline: Network Options > Optimisation Options > Advanced > 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 26.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 run evaluation button is provided for this purpose in addition to the Run
TRANSYT (optimisation) button.

Page 50
4.2 Cycle Time optimisation

Cycle time is not automatically considered by the signal optimiser, but TRANSYTs 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
26.11 which also discusses issues related to the choice of cycle time.

How to use TRANSYT 15 Page 51
5 How to use TRANSYT 15

TRANSYT is a complex 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 simply Dont know where to start.
5.1 Essential GUI terms you need to know

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 15. Please spend a few moments reading the
introductory section of the Glossary. (TRANSYT GUI Terms)
5.2 Quick start for new TRANSYT users

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.
Note: the following is only a very brief overview. See chapter 6 for a general description of the
GUI and details of the menus and toolbar buttons. You are also likely to need to reference
various other chapters while working through this one, e.g. chapters 7 (TRANSYT 15 Input
Data),) 9 (Data Grids), and 10 (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
6.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 network 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.
If in doubt, the Task List (see Task List) 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.

Page 52
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: Custom 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 custom 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:
1. In the File Description Area (via the Data Outline and Data Editor), Enter the project title,
location etc. and set the driving side.

Page 54
Network Options
2. Use the View tab of the Main Data screen (or Outline: Network 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 diagrams Add a newJunction button to merge more
junctions into your network Thus saving you time (section 7.2).
4. Having merged all the files you wish to bring into your network, now connect the relevant
links and traffic streams.
5. For areas of the network that you wish to build without the help of the Library System, it
is suggested that you add all traffic nodes first (10.7.6), renumbering them and locating
them into their approximate position as required. Technically, traffic nodes are not always
required but do help when identifying junctions, can help when adjusting items within the
network diagram and can affect how many paths an OD Matrix generates. Traffic Nodes
have a visual representation dependent upon whether or not anything connected to it is
signalised.
N.B. you have a choice of constructing your network using arms, traffic streams and lanes,
using links, or a combination of both. Lanes are easier and more intuitive to use, require
the use of OD Matrices to assign flows to the network, and also hide the underlying
structure of the network.
If using traffic streams and lanes carry out steps 6 to 13 and if using links carry out steps
14 - 19.
When using Arms, Traffic Streams and Lanes:
6. Add all arms, locating them in the appropriate location between the relevant nodes 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.

7. 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 items. (If you are more familiar with
TRANSYT link structures, a Traffic Streams equivalent is a major link).
8. 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 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.
9. Attach each Arm to its traffic Node using the ManipulateConnect 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.
10. Create one controller stream for each genuine controller stream, and attach each
signalised traffic stream to the relevant controller stream using the ManipulateConnect
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 connected to the nearest controller stream (if one exists) and to nothing
otherwise. The connector tool can be used to redirect connection to the right controller
stream.

Page 56
11. Attach each traffic stream to its downstream traffic streams by using the connector tool in
the network diagram.
12. 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.) Alternatively, you can right-click on a lane (or traffic stream) and
select one of the Traffic Stream Properties. 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 10.8.1.1 on how to do this.
13. 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 59
When using Links:
14. 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 toolbox tool, or,
you can right-click on the link after adding it and then set the control type, etc.
15. 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.
16. 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.

Page 58
17. Attach each link to its downstream link(s) by using the connector tool in the network
diagram.
18. Set up any shared stop lines by using the shared stop line tool in the network diagram.
19. 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:
20. ALTERNATIVE: Use one or more Data Grid screens to rapidly enter data for all traffic
streams, links, etc. in one go (see chapter 9). 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 capture 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 down appreciably) and may then require route choice
decisions.
When using an OD-Matrix to define flows:
21. Use the network diagram to add an OD-Matrix (section 13.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.
22. Enter your flow data to the OD-Matrix and ensure that auto calculate is selected.
23. Check that the paths created by the OD Matrix are valid paths. If not, disable those that
are not, 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.

Page 60
24. 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:
25. 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.
26. 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.

27. ALTERNATIVE: Use one or more Data Grids to view and edit all flows for all links (and
similarly for all sources).
Signals
You have previously created your controller streams and associated each signalled traffic stream
and link with the right one. 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:
28. 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.

Page 62
29. 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.
30. On the same tab, set any minimum greens or maximum greens you wish to define.
31. For each traffic stream (or link) use the network diagram (Right-click on controller
stream), Link Data Screen, Traffic Stream 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. Note: the network diagram can only be used to set up
the first phase.
32. 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.
33. Optionally, 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.

34. Using the Signals Data screen, select the Stage Library Tab and click the Auto Generate
Library 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
phase B and D.
35. 1st ALTERNATIVE: Using the Signals Data screen, select the Stage Library Tab. You
can use the Create New Library 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.
36. 2nd ALTERNATIVE: 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, or use the Auto Generate Library Stages option.
37. 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.

Page 64
38. Select the Stage Sequences Tab. Either 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
first in the list is selected automatically as the current sequence (i.e. the one referenced in
the traffic stream data).
39. ALTERNATIVE: Select the Stage Sequences Tab. Manually create the stage sequences:
One sequence is created automatically. 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 Add a new Stage Sequence.
40. 2nd ALTERNATIVE: Select the Stage Sequences Tab. Click the Edit Stage Sequence
button. This launches 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.
41. 3rd ALTERNATIVE: Select the Stage Sequences Tab. Click the Edit Signal Timings
button. This launches 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.
42. Set initial stage and phase times by dragging stages and phases with the mouse within
the Timings Diagram. Select either Stage Mode (the default) or Phase Mode to do this.
In Stage mode, stages are NOT automatically created, destroyed or redefined within the
diagram.

43. 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)
44. Use the Main Data screen (or Outline: Network Options>Network Timings) to select the
traffic model to use (PDM, CTM, etc.). A description of each of these is explained in
chapter 24.
45. Use the Main Data screen (or Outline: Network Options>Optimisation Options) to choose
which optimisation level you would like to use. Also select whether to apply the auto-
distribute (stage timings) routine as part of the optimisation process This is essential if
existing timings are not already valid.
Running the file and inspecting results
46. Save the file and then press the 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 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 66
47. On completing the calculations the Summary Results screen will appear. This provides a
summary of the network operation, given the network flows, current options and
optimised signal timings (unless the Optimisation Level = None - evaluation mode in
effect). The Network PI (Performance Index) provides an index, in monetary terms, of
the entire network.
48. Inspect network results by locating Network Results in the Data Outline and then
expanding the relevant section.
49. Inspect individual results by expanding the Results section of each item in the Data
Outline.
50. Inspect collections of results with the Data Grid screen.
51. To analyse any subset of controller streams, traffic nodes, traffic streams or links, define a
collection (Outline: Collections).
52. 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.

53. Open the Report Configurator and select which top-level sections and what sub-items you
want in your report.
54. Press the Generate Report button to create your report.

Page 68
55. View the optimised signal timings via the Timings Diagram.
56. Compare files using the main menu tool Compare Files
57. 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.
58. Add a backdrop to your diagram and then switch to 3D Mode to more easily
find the best viewing angle and to present your findings in a more meaningful setting.

59. Add 3D (.DAE) models to your network to help make your network easily identifiable.
60. Generate Time Distance Diagrams using the Graphs button, in order to observe and check
coordination along links.

Page 70

General GUI operation Page 71
6 Graphical User Interface (GUI) operation

6.1 General
The TRANSYT GUI contains many screens, many of which can be displayed at the same time and
also interact with each other. Screens are also dynamic, in that altering a value on one screen
will update relevant values on other screens. If the file contains no errors, it can also be
automatically run, and the new results shown. With auto-run mode turned on, the results will
automatically update as input values are changed - Evaluation run only, i.e. not optimised. We
recommend that you run the program using a high resolution screen display or a dual monitor
display if possible.
There are a few exceptions to the above, where a screen must be explicitly 'exited from' before
changes are saved e.g. options > preferences screens. In addition some screens have an
optional mode where you can work with the data in the screen in isolation to the rest of the
program, for speed and convenience.
In general you can show a screen and then show another screen of the same type for example
you can show several Intergreen Matrix screens, each showing the data for a different controller
stream. See Padlock System (section 6.9). Pressing the mouse wheel to select items on a
particular screen will prevent the selected screen from being brought to the front useful when
screens are overlapping and you wish the screen front-to-back order to remain the same.
At any time there is one active item, such as a link, node or location. The current item is
highlighted in the data outline and other screens. If the data editor is visible, then the
properties for the current item will be displayed and should be editable. The data outline is used
to add/delete items.
Double clicking or right-clicking on an item will often show the item's properties, or bring up an
appropriate screen.
Some items are shown in dedicated screens: icons to access these are shown in the vertical
toolbar.
The undo/redo buttons allow any change made to the file to be undone at any time.
Note that TRANSYT does not save a separate output file; instead, basic results are saved within
the input file, and the date/time of the run also recorded. Optionally, you can also include
detailed animation and graphs data within the input file, although this will result in increased file
sizes. You can send such a file to a client or colleague who can view the file, including
animations and graphs, in the demo version of TRANSYT 15. When a HTML report is generated,
the report is saved to a default location and from there can be archived if needed. Optionally it
can be saved as a Word or PDF file. The generated PDF files are fully paginated.
6.2 Getting help

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.
If you cannot find an answer to your question, check the TRL software website first for
knowledge-base articles, latest news items, or contact us directly at TRL.

Page 72
6.3 Accessibility
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 some users 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.
6.4 Demo (and Viewer) mode

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 or optimise timings. To remove these restrictions, you must
upgrade to the full version of the software by purchasing an unlock key from TRL, which can
then be entered on the screen displayed when the program first starts. See Chapter 1 for more
details.
If you have obtained an evaluation version of the software, this will run in unrestricted mode for
a certain number of days, and then revert to demo mode. You must then purchase an unlock
key as above to unlock the full version of the software.
The current security status of the program is shown in the splash screen, which is available from
within the program by selecting Help>About.
Because TRANSYT 15 files include results from running the program, the demo
version of TRANSYT 15 can be used by anyone to view both the input and output
from TRANSYT 15 files. This includes animations and graphs, once an evaluation
run is carried out.

6.5 Keeping it simple

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 Mode6.5.1).
Furthermore, there are many features and data items that will not be required for some
networks, i.e. they are file-specific. Therefore a file-based solution under the sub-heading
Network Options is provided. See section 6.5.2.
6.5.1 Advanced Mode
In order to make it easier for those unfamiliar with this version of TRANSYT an Advanced Mode
mode of operation (Data>Show Advanced/Detailed data items) 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 to
Basic Mode Once a file is in Advanced Mode it will always remain so.
When merging either a user file or library file into your network, if it
contains advanced features (i.e. it is in advanced mode) 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.
6.5.2 Network Options
Network Options is a high level section of a data files outline - Use the Data Outline to
navigate to TRANSYT Network > Network Options.
Network Options consist of a substantial 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 7.8)

Page 74
Some items such as those relating to their display in Data Outline are only hidden while none
of that category of item exists within a file. Most of the remaining options are used to suppress
potentially unnecessary results outputs.
6.6 Speed of operation and large files

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:
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.
Some windows (e.g. Data Grids) have an Edit In Window 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.
If Auto-Run is turned on, 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.
Run times increase with the size and complexity of the network, the number of time-
steps and the number of time segments
The Cell Transmission (CTM) traffic model is significantly slower than the platoon
dispersion model (PDM). Use PDM to model links and traffic streams that cause no
blocking back problems. Only use CTM when blocking needs to be modelled.
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.
See also section 6.12.1.
6.7 Main toolbars

6.7.1 Main Menu
The options within the main menu (File, Edit, View, Go To, Data, Run, Tools, Options, Help)
mostly duplicate the buttons on the main horizontal and vertical toolbars, and are self-
explanatory. Some TRANSYT features however are only available from the menus, such as
importing/exporting options. The View and Go To menus, in particular, are useful as a short-cut
to the various items within the Data Outline. Please explore the options in the menus and refer
to this User Guide for full details.

6.7.2 The 'Go To' menu
This menu gives easy access to common data items and takes you to the first item of the
appropriate kind in the Data Outline and Data Editor. It does NOT open any other specific
screens use the View menu or the toolbar icons for this.
Use the Go To Controller Stream Go To Link and Go To Traffic Stream options to go straight
to a specific controller/link/traffic stream if you know the ID of the node/link.
6.7.3 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/redo
Redo
Show Data Outline Data outline
Show Data Editor Data editor
Show Data Grid Data grids
Show Task List Task list
Show Audi Trail Audit Trail
Show Windows Manager Windows Manager
Back
Forwards
Changing the active data item
Previous
Next
Toggle Auto-Run
Evaluation-only Run Running files
Run File
Configure Report Configure Reports
Generate Report Reports

Page 76
6.7.4 Vertical toolbar
From top to bottom, the buttons on the vertical toolbar are:
Icon
Show/hide Summary Results screen
Show a new Network Diagram (Schematic) window
Show/hide the animation controls
Show a new Timings Diagram
Show a new Stage Sequence screen
Show a new Intergreen Matrix screen
Show a screen for editing common (main) data
Show a screen for editing signal data
Show a screen for editing link data
Show a screen for editing traffic stream data
Show a screen for editing pedestrian crossing data
Show the Local OD Matrix screen
Show the X-Y Graph Analyser
Show the Cycle Time Optimiser screen
Shows a flow graph (includes cyclic flow profiles)
Shows a spatial graph (includes queue graphs)
The TDD button shows a new Time Distance Diagram

6.8 Changing the Active Data Item

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 29.1 for more details.
There in several ways to set the Active Data Item:
Click on the item in the Data Outline (7.3)
Click on an item in the Go To menu on the main toolbar
Click on a row header in a Data Grid (see section 9)
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 Link
Timings Diagram (you will learn with practise how this works)
Click on the hyperlink 'shortcuts' sometimes displayed in the Data Editor
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 very 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.

Page 78
6.9 Padlock system

Many screens automatically update themselves so that they always show data for the Active
Data Item, where appropriate. For example, the Timings Diagram always shows signal timings
for the currently selected signalised node and will thus change as you select different signalised
nodes via the Data Outline, or the network diagram, or any other screen. It will also try to show
timings for the appropriate link if the Active Data Item is a link, and so on.
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, as shown in the screenshots below.
In the lower screenshot, the screen is locked to Controller Stream 1. The data in the screen will
continue to update if the timings for Controller Stream 1 are changed, but the screen will only
show data for Controller Stream 1 (not Controller Stream 2 or 3 etc.), until you unlock it. Once
unlocked, the screen will show data for any controller stream clicked on in the Data Outline etc.
Continuing with the Timings Diagram example, you can show any number of Controller Stream
Timings diagrams at once (just press the button on the vertical toolbar several times), and lock
each one after selecting a different controller stream via the Data Outline. In this way you can
show data for several items simultaneously, as in the screenshot below. This applies to most
screens that have a padlock icon.

Some screens (in particular, the Data Editor and Data Grid) have a special padlock that cycle
through three 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 the 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
Link Modelling), but will update to show e.g. Modelling for Link 1, Link 2, Link 3, etc., as you
select different links. You dont need to click on Modelling for each link in the Data Outline:
clicking on any part of a link, or the link itself 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 links, choose the Filter to Bus Links Only filter and then use this locking
mode, then the data grid will only ever show bus links, whatever you click on in the Data Editor.
Changing a normal traffic link to be a bus link would then cause an extra row to appear in the
grid.
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 Modelling data for Link 1, and will not show data for
Link 2 or Link 3 until you unlock it.
With Data Grids, this mode locks the specific rows in the grid. For example, if you show a data
grid of links, choose the Filter to Bus Links Only filter and then use this locking mode, then the
data grid will only ever that particular set of bus links. Changing a normal traffic link to be a bus
link would have no effect on the grid until you unlock it.

Page 80
6.10 The 'Edit in Window' System

Some screens (in particular, Data Grids) have an Edit In Window 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 either the
Done/OK or Cancel buttons.
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 Edit in Window 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.

6.11 Types of Data

Data items in TRANSYT are shown in various screens, such as the Data Editor, Data Grids,
Signals, Link and (Traffic) Stream editing screens and so on. In general they all use the same
system, some features of which are summarised below.
Editable items are shown with a normal white background
Some normally editable items may be disabled and are shown with a grey background,
although, it is more common for such items to simply be hidden. There are several
reasons why items may be disabled/hidden:
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 directly inapplicable (e.g. give-way data for a non give-way link)
o It may be inapplicable because of data entered elsewhere (e.g. some data is

disabled for minor shared links)
o It may be inapplicable because of the current program mode
If a data item is a result, i.e., an output from TRANSYT, it is shown with a light green
background:
When looking at results, some items may appear as N/A. 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 link
and traffic stream, but not for the entire network; there is a calculated saturation flow for
each link for each time segment, but not for the summary time segment. You can check
this by showing the Help>Glossary screen.
Not all data can be edited directly. For example intermediate results such as Resultant
Stages data and green period data are not editable and are shown with a light green
background. Other data may be greyed out depending on the particular mode of
operation of the software.

Page 82
6.11.1 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
Options>Units>cost Units in the Data Outline.
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. (NB the monetary values in the screenshot are
illustrative only. The actual values used will depend on the country in question. No currency
conversion is carried out; the unit of cost is purely a symbol.)
TRANSYT also provides several options for the units for speed and distance items. Wherever
possible, data items in TRANSYT are always shown with their units, to avoid any potential
confusion. Changing 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 13.4.12 for details of how to add new traffic types, and how to define
PCU factors for each traffic type (section 13.4.13).
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.
Note that all unit options are saved as part of the file (as opposed to user Preferences).

6.11.2 Traffic Stream IDs and other unique IDs
TRANSYT works with controller streams, nodes, arms, lanes, traffic streams, links, pedestrian
crossings, collections, locations and paths, all of which have IDs. IDs can contain any mixture
of numbers and letters, although there is a maximum length of 10 characters. You cannot have
two traffic streams with the same ID, and similarly with the other items.
In TRANSYT you can use very flexible naming conventions, for example using your own set of
prefixes/suffixes when naming traffic nodes or links. E.g. you could name all priority nodes with
an initial P, entry links with an initial E, and so on.
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,
TRANSYT will automatically assign the ID as the next available number, but you can
subsequently change it using the Data Editor.
When you change an items ID (via the Data Editor) 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 file will remain self-consistent.
6.11.3 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 LinkShare.

Page 84
6.11.4 Sorting Network Items
As explained above, TRANSYT works with many network items, such as traffic streams, each of
which has an ID. Many screens show lists of such items, 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.
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 (Node 11 now comes before Node 2)
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.
6.12 Running Files and using Auto-Run

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.
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 results from any change to any part of the data. This ensures the
results always match the current signal timings.
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.
Select Run>Run All Analysis Sets and Generate Report

from the main Run menu

Page 86
6.12.1 Run Times
The time taken to run a file depends greatly on the size of the network, the chosen optimisation
options and the traffic models you are using. If using a PC with reasonable specifications, most
networks using a PDM model should run almost instantly and Auto-Run can be used without any
problems. If there are a large number of lanes, links or controller streams, run-times can
increase to noticeable levels, and it may be advisable to turn Auto-Run off. We also recommend
leaving Auto-Run switched off when using the CTM traffic model, since this is inherently slower
than PDM.
The status bar at the bottom of the main screen shows what TRANSYT is doing at any time.
6.13 Managing files

See chapter 1 for general information about files used by TRANSYT. Note that in TRANSYT,
there is no output file from the signal optimiser. All output is dealt with inside the GUI. You can
however generate reports that can be saved to disk.
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 opened at once. The names of any open files are shown in buttons in the
blue bar at the bottom of the screen: this is the file selector bar.
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 23.2 for
details on this.
To switch between files, click on the appropriate button in the file selector bar.

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 can be used.
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 menu option.
6.13.1 Importing from older versions and from different products
TRANSYT 15 can import data from 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, 14, and 13 respectively.
filename.DAT for TRANSYT 12 and earlier.
See Chapter 31 for full details.
TRANSYT will also import data from a number of third party products such as TRANED 2,
TRANSYT-7F, SCOOT and SCATS. See the following Appendices for more information.
Import from TRANSYT 7-SET (see section 31.3)
Import from TRANSYT-7F.
Appendix E Importing SCOOT data
Appendix F Importing SCATS data
6.13.2 Files generated with different releases of TRANSYT 15
If a TRANSYT 15 file that is opened has been generated with a different release of TRANSYT to
the one currently being used, a message may report this and provide an option to examine a
report detailing any differences made to the file as it is opened. This only happens when the
changes are substantial. This information may be of interest to some users if 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 88
6.13.3 Exporting data to TRANSYT 14
TRANSYT 15 data can be saved to a TRANSYT 14 file format by selecting File>Export>To

TRANSYT 14. See Appendix B Export to TRANSYT 14 for full details.
6.13.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 because it allows you to try out various 'what if?' scenarios that are
too complex for the undo/redo feature and without having to manually save the file under many
different names. It also makes comparing the effects of such changes very easily.
6.13.5 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.
6.13.6 Saving results from TRANSYT runs
When you save a file, you save all the input data. If the file has been run, then you also save
the results for each link and the whole network, i.e. the results are embedded in the data file. If
you subsequently load this file back into TRANSYT, you can jump straight to the results without
having to re-run TRANSYT. This is useful if it is a large network or is otherwise slow to run.
If a file contains multiple analysis sets, the results in the file will be those
associated with the last-run set if you change sets, you should press the
Run Evaluation button to repopulate the results with those for your newly
selected set. Running an evaluation run after switching sets will also
prevent the Report ever presenting the results of one analysis set alongside
the input data of another.
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
un-optimised run of TRANSYT to generate the required data. They will require either the
demonstration version of TRANSYT 15, 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 15 can be downloaded
from www.trlsoftware.co.uk.
6.14 Undo/Redo
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. However, due to anticipated memory constraints, the UNDO record is cleared when
switching to another file.
Use the drop-down menus on the Undo/Redo buttons to show a list of recent changes and jump
straight to a particular change.
Note: hovering over the Undo/Redo buttons, or using the Edit menu to access the options, will
show the action that will be undone/redone, e.g. "Undo Change Saturation Flow".
The Undo facility is useful for reversing accidental mistakes, or for 'rewinding' the file after
deciding that a series of changes is unwanted. 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 6.13.4).
The Undo/Redo buttons are also very useful for studying the effect of a change to a data item,
especially when the file is automatically re-run (i.e. the Auto-run option is switched on). For
example you can run a file, display the Summary Results screen, then adjust a data item field,
then flick back and forth between the before and after results via the Undo/Redo buttons.
Also see section 6.18 on user preferences regarding reducing the number of Undo points to
reduce the memory requirements of TRANSYT.
6.14.1 Save Diagram State
An extra item in the main Edit menu is Edit>Save Diagram State. This will add an extra item to
the Undo history which represents the current network diagram layout. Subsequently you can
revert back to the diagram layout as it was at this point by clicking on the Undo drop-down
menu and then selecting the Saved Layout entry. This saves you having to click the Undo
button multiple times to revert back to this point, and acts as a kind of network diagram save
option.
6.15 Copying data to the clipboard
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.) To copy the network diagram,
for example, click in the network diagram so that it is active and then click the Copy button on
the main TRANSYT toolbar.
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.
In many cases you can also use the CTRL+C shortcut, or, right-click and choose Copy, but note
than in some situations this will copy only the current line of text rather than the entire table.

Page 90
6.16 Printing
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.
6.17 Managing Windows

There are a large number of windows in TRANSYT, most of which can be open at the same time.
(For this reason we recommend using a large monitor. Please note however that having many
windows open at once can lead to a slowdown of program operation when working with complex
networks.) Windows can be moved and closed manually according to your own preferred way of
working, but there are some tools to help with the process:
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.
TRANSYT allows you to store custom window layouts. This allows you 'save' the layout of all the
TRANSYT 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.
Use the menu option Window Layouts>Window Manager option to display the
Window Manager. Alternatively, use the Windows Manager icon on the main toolbar
(see section 6.17.1).
6.17.1 Window Manager
The Window Manager is multi-purpose it allows new window layouts to be added, renamed or
deleted and also provides quick access to any of the saved layouts when left permanently open.
Double-click on one of the layouts listed at the top, to switch to a new layout. Saved layouts
also take account of any docked windows. Any one of the saved layouts can also be set as a
TRANSYT default layout.

Below the saved layouts, the Window Manager also displays a list of all open windows. A single
click on any of these will bring the selected one to the top. This offers the same functionality as
the windows list on the main Windows menu.
6.17.2 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.
6.17.2.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 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 the Summary Results 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.

Page 92
N.B. the best way to learn how the docking system works in practice is to experiment with it.
To un-dock a window, simply double-click on its Title Bar.
6.18 Preferences Screen

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
some items are also given below for reference.
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.

General:
Allow Window Minimise & Maximise: This option shows or hides the maximise and
minimise buttons on every screen.
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, custom screens or data
grid. Where a custom 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.
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.
Log everything in Audit Trail 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.
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
(e.g. unable to allocate sufficient storage messages) then reducing this number (all the
way to zero if necessary) is a very effective in reducing the memory requirements of
TRANSYT.

Page 94
Prompt to save Audit Trail status for new files: The equivalent of this option is saved
with the file, but this allows, for new files, the user to be prompted to save a status entry
each time a file is saved.
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, i.e. all data items and features will be
accessible. N.B. Library files will start off in Basic Mode only if they have been originally
saved as Basic Library files.
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.
Localisation:
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. 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.
Reports:
(Import Settings) From External 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
6.18.1 on how to transfer the preferences file, rather than share it.
Reports Location Mode. If the latter 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.
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.
Safe Mode: Turn this on if you experience any problems with text rendering in the
network diagram.

Start network diagram (Netcon) Inside Application Window: Turn this on if you
wish to have the network diagram opening in its own Window on a permanent basis. This
option is useful when using multiple monitors, and wishes consistently to 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.
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.

Page 96
Link Connector Arrow Type: controls how arrow directions are automatically calculated
in the network diagram and also in Stage Sequence diagrams
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.
Comparison Tool:
nth File Colour: Use each the colour options to set the specific colour you wish to use
when comparing multiple files.
Aimsun Plug-In: See TRANSYT-Aimsun User Guide for details on this option.
6.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:
1. Show the Preferences screen

2. Click on the Open Preferences folder link at the bottom of the screen
3. Windows Explorer will open a folder where you will find a .config file. Make a copy of this
file.
4. 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.

TRANSYT Input Data Page 97
7 TRANSYT 15 Input Data

7.1 Data Files
TRANSYT 15 saves data as files with a .T15 extension. These data files save everything that can
be viewed and edited in the Data Outline (see 7.3).
TRANSYT does not save a separate output file. Instead, results can be embedded in the data file
and saved along with input data. See saving results (section 6.13) for more details.
Please note that a number of input data items are only accessible when TRANSYTs Advanced
Mode is set. See section 6.5 for details. Furthermore, many items can be switch-off using the
Network options list. See section 6.5.26.5 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 6.13 for more details about file-handling.
7.2 Library Files

Rather than construct junctions from scratch, users 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 users wish to store as additional library files.
TRL supplied Library files are displayed in blue.

Page 98
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
facility. See section 23.2 (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 manipulated like any other file. Saving the
file will save it as an ordinary TRANSYT file, but it can also be saved as a new 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 a specific Library Folder.
If you open a Library File directly from this special Library Folder (<Install
Folder>TRANSYT 15/Library) 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.
7.3 Data Outline

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 7.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
Link 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 View and Go To menus to
access certain items.
You can also use the Main Data, Nodes 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 (7.5).
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 screenshot below shows the basic hierarchy expanded by one level, and shows that, for
example, TRANSYT Network contains Network Options, Controller Streams, Arms, and
Local (OD) Matrices. This list reflects the items that exist within the chosen file. Other
networks will display a number of other items.
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. To take this
screen shot TRANSYTs Advanced/Detailed data items option has been switched on, revealing
the Advanced items such as Analysis Sets and Demand Sets.

Page 100
7.4 Data Outline Screen

To show/hide the Data Outline, click the Data Outline button on the main toolbar, or
select a data item from the main Go To menu.
The Data Outline is used to access all data items within the TRANSYT file. Items in bold have
associated data fields that you can view and edit in the Data Editor (see 7.5). Items that are
not in bold do not have any associated data item fields. Double click on any item to show the

Data Editor (or chosen screen type see File>Preferences) which will show any data fields for
that item.
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 (Give Way Data for
Traffic Stream 1 in the screenshot) and also becomes the
TRANSYT Active Data Item. The Active Data Item
determines what is shown in many other TRANSYT screens,
especially the Data Editor screen. Similarly, the Active Data
Item can be set from many other screens. For example,
clicking on a link in the network diagram will cause that link
to become the Active Data Item, and it will be highlighted in
the Data Outline. The Active Data Item can be 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 6.8 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.
Notes:
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 (including its
control type and all signal timings) 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 button on the Data Editor. However, if you
select Links 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.

Page 102
7.5 Data Editor Screen

To show/hide the Data Editor, click the Data Editor button on the main toolbar, or double-
click on a data item, or right-click on a data item and select Properties.
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 2.
See section 6.8 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, e.g. the Cell Saturation Flow value is
hidden unless the chosen traffic model is CTM. 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. The Data Editor screen can be left open
all the time there is no need to close it down after having made changes.
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 button to set all fields to their defaults.
If Auto-Run is turned on (see section 6.12), then changing any field will cause TRANSYT to carry
out an evaluation run of TRANSYT and refresh the results screens.
Note: The Data Editor can be resized horizontally in order to make the text-boxes longer.
The icons shown to the right of some data fields are 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. In some cases the icon is shown at the top of the Data Editor and in this case
indicates that the entire data item itself exists separately for each Analysis Set e.g., each
Analysis Set can contain an entirely different set of stages.
See also: Padlock System (Section 6.9)

7.6 Network Diagram

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 nodes, links, traffic
streams, etc. It also shows output results, including signal states and animation of queues and
CTM data. See Network Diagram (chapter 10) for full details.
7.7 Task List

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.
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.
Checks are made for logic and self-consistency within the file.
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.
For each row in the grid, the Severity column will display 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.
You can choose whether to display errors, warnings or info items by toggling the three buttons
at the top of the screen. By default, all three types of item are shown, but you may wish to hide
the Info items.
Clicking in any column in the header row will sort the grid by that column. This allows you to
choose to sort the problems by Severity (so that errors appear first; this is the default) or by
Area.

Page 104
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.)
7.8 Data Field Finder

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.
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
happens to be in Basic Mode, or because none of that particular item is present in the current
data file, e.g. if there are no traffic signals in the file, there will be no saturation flow data
items present. The Description indicates why it is hidden.
Clicking Search help file will open the application User Guide and perform an automatic search.
You can thus search the User Guide for further information on any topic.
Note: 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.

Dedicated data-entry screens Page 105
8 Custom data-entry screens

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 or via the main View menu.
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

Signals (controller) Data
Links Data
Traffic Streams Data
(Pedestrian) Crossings Data
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.
8.1 Main (Common) Data Screen

This screen allows access to all main data, i.e. data that is common to the whole network. The
layout has been chosen to ensure that the commonly used data appears on the default visible
tab (Main Data) on the screen and the rest split between the remaining tabs.

Page 106
The monetary values of vehicular and pedestrian delay are now separated.
However, by default, the values are the same.
The Fuel tab will be hidden unless it is enabled via the Network Options.

There are buttons offering the option to create a completely new set of fuel parameters, or to
create an extrapolated set (from WebTag data). The Generate Extrapolated Fuel Parameters
button is used to populate the fuel parameters data grid with values appropriate for a specified
year - extrapolated from WebTag data stored within TRANSYT. Full details on how to use this is
available in section 25.10.

Page 108
Network Summary results are given for the complete network and also separated into vehicular
and pedestrian results.
8.2 Signals Data (controller stream) Screen

Via a series of tabs, the Signals Data Screen provides access to controller streams and its
phases, stage library, phase delays and stage sequences. Controller streams and other network
objects can be added, deleted and modified via this screen. The list of controller streams is
visible from all tabs. Select the controller stream to view using the 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, including the ability to
add/delete columns and rows.
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 8.2.7, while a full description of the contents of each tab is given here in the following
sections:
8.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 > Optimisation Options.) 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.

Page 110
8.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 row-header (the grey area on
the left of any row) 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 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. Some phase types
also allow extra phase data to be specified, however only the blackout period for
pedestrian phases affects the model. Amber times are for visual purposes only.
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.
8.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 row-header (the
grey area on the left of any row) 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 C
running) and a stage 2 (phase B and D running).
The fourth button, Interstages opens the interstage tab of the Intergreen Matrix screen, to
let you see the derived interstages.
8.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.

Page 112
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. See
chapter 15.
8.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 which the controller stream will be set to
run - 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 offers the
options to delete, copy and add a new 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.
An addition three 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 ). If none of these are what you wish to use, you can simply edit the one closest to your
requirements and reset the controller data to use that sequence.
The other two buttons Timings Diagram and Stage Sequence Diagram are simply short-
cuts to open the Timings Diagram and Stage Sequence Diagram respectively.
Multiple-cycling choices can also be set from this screen.

8.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 have specified such as intergreens and stage definitions.
Stage start, stage end and split times can be directly entered using this screen.
The TRANSYT Stage start times (as used in TRANSYT 12 and earlier to define
when the call for the next stage occurs) can also be edited here.

Page 114
The reporting of relative offsets (positive and negative) can be set up from the Offsets tab. See
section 21.1 on how these appear in the TRANSYT output.
8.2.7 How to use (Signals Data 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 15
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.
3. Open the Signals 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 at this point by using the Delays tab, but this tab is best
used in conjunction with the Timings Diagram, and you may often 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 the
Timings Diagram to see a graphical representation of each of them - Either click in the
boxes to the left of the Controller Stream column or use the data outline to select each
sequence.
10. Enter the sequence you wish to use in the Use Sequence box.
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.
8.3 Links Data Screen

Via a series of tabs, the Links 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 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. Links and quick flares can be added,
deleted and modified via this screen.
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 accessed via these tabs are not described here as this is already
covered in various other chapters.

Page 116
8.3.1 Link Data Tabs
The Links Data screen consists of up to 13 tabs as follows:
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 restricted flow (i.e. 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 tow 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 is also built into this tab to allow you to identify and investigate where any
flow discrepancies exist. How to use this feature is described in section 13.3.
The Upstream 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
haver/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 Downstream tab is only there for convenience i.e. it allows the source data for any
downstream links to be edited so that if any changes are made to the current link the required
knock-on changes can be easily carried out. Of course, the use of this tab is optional as the
same data can be edited in the upstream tab of each of the downstream links.
The Advanced tab allows the specialist flow detector data and link sensitively values to be set.

Page 118
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 Signals tab allows you to set what controller stream and phase controls a signalled link.

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

Page 120
8.4 (Traffic) Streams Data Screen

Via a series of tabs, 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. Arms, traffic streams and
lanes can be added, deleted and modified via this screen.
Some of the 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.
covered in various other chapters.
8.4.1 Traffic Stream Data Tabs
The Traffic Streams Data screen consists of up to 11 tabs as follows:
The Arm 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 restricted flow (i.e. a saturation flow) and whether or not it is signalled and/or a give
way. (see screen shot)

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: Due to the amount of modelling data required, this is split between
tow 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).

Page 122
The Signals tab allows the controlling phase and its controller stream to set. N.B. This
tab is only visible if the traffic stream is signalled, (see screen shot). 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 Flows tab allows the total flow to be checked. The Upstream tab is used to specify
the cruise speed/time of the sources of the selected controller stream. For convenience
access is given to downstream data. 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, 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).

Page 124
8.5 Pedestrian Data Screen

Via a series of tabs, the Pedestrian Crossings Data Screen provides access to signalled
pedestrian crossings and its connectors (between crossings), sides and conflicts (with traffic).
Crossings and other network objects can be added, deleted and modified via this screen. The
list of crossings is visible from all tabs. Select the crossing to view using the list on the left hand
side, or via the Data Outline, or network diagram.
Some of the tabs have additional buttons which carry out useful actions such as Add new
Conflict and View Signals.
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 14 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.
8.5.1 Crossing Data Tabs
The Custom 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 two Side 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.
covered in Chapter 14, 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 custom 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, side 1 of crossing 10 is connected to side 1 of crossing 11, and side 2 of
crossing 11 is connected to side 1 of crossing 12.
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.

Page 126
The Results tabs show the summary pedestrian data, with convenient links to the
remaining pedestrian results (using the data editor).

Data Grids Page 127
9 Data Grids
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 all other appropriate screens. 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 link 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, on 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 128
If you click on any Controller Stream (via any appropriate screen), then any Data Grid screens
will show all Controller Streams in the file.
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 6.9), 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.
9.1.1 Selecting items
If working with for example a Data Grid showing all Links, you can make any Link 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 works the other way round click on items in the network diagram to see
them highlighted in the Data Grid.

Data Grids Page 129
9.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.
9.1.3 Locking the grid
Please see section 6.9 for use of the padlock system.
9.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 (e.g. to set the Type of all nodes to be Bottleneck, simply press B and press
ENTER on each row). Use the spacebar to toggle checkboxes on/off.

Page 130
Some fields will be greyed out and disabled (and/or may show N/A). 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 Restricted 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 green to reflect the fact they are, in
effect results derived from other editable data, and cannot be changed directly, e.g. If Auto
Length is ticked, then the length of the traffic stream (or link) will be in green. 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 Edit in Window 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.
9.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. 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.
9.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.
9.1.7 Sorting and grouping rows
Each data grid show rows in the order specified by the Options>Sorting section of the Data
Outline, which allows 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.
9.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

Data Grids Page 131
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.
9.1.9 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 Column Layouts>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 Column Layouts/Remove All Columns
- In the Data Grid, right-click on a column header and use the drop-down menu to select the
fields to add:

Page 132
In this example Saturation Flow and Traffic Stream Length have been selected.
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.
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

Data Grids Page 133
this way you will not have to select it manually each time. Tick the UseInReports 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.
9.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.
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 Total Results>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 Columns
In the Data Grid, turn on Customise>Add Fields from Data Editor
Show the Data Editor if its 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.

Page 134
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 20.1.3)
9.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.

Data Grids Page 135
9.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
6.9.
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 136

Network Diagram Page 137
10 Network Diagram
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, lanes and traffic streams, indicates their types and various other parameters,
and can be overlaid with a wide variety of extra data, such as queue animations and CTM cell
occupancy 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 nodes, links 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 icons along the top horizontal toolbar control the view of the network and turn on and off
various overlay tools 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 14.6. The blue cones around traffic nodes
indicate which traffic streams (or links) are providing the traffic that travels through the traffic
node. The green cones around controller streams indicate which traffic stream (or link) it is
controlling. 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 the user, 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 backdrops and 3D Models.

Page 138
10.1 Speed of operation

The network diagram should be highly responsive even with reasonably large networks. If you
find that it is jerky, or 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 turns off certain features; 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.
10.2 Moving around the network

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.
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. Most of 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.
10.3 Saving, using and managing Views

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 diagrams 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.
The menu option Manage saved views brings up a screen which allows you to individually set
views to be included in TRANSYTs report.

Page 140
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.
10.4 Printing, copying and exporting

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 and Scalable Vector Graphics
(SVG).
See section 10.3 on how multiple views of your network can be stored, selected and also
included in a TRANSYT report.
10.5 Representation of Links, Lanes and Stop Lines

links:
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.

Arm, traffic streams and lanes:
Arms are represented by a thin line with bend-handles located at both ends. Arms act as
containers for traffic streams. Traffic streams are represented by a long rectangle running the
length of the arm one for each lane. Lanes belonging to the same traffic stream are identified
by the fact they are closer together than when they are part of different traffic streams, and
they share the same stop line. The stop lines are represented by black square brackets, located
at the downstream end of each traffic stream. 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 traffic stream 1 is 1800.
Different lane colours, bracket colours and bracket types are used to represent the other traffic
stream types as follows:
Give-way:
Restricted flow (e.g. bottleneck):
Give-way with restricted flow (e.g. give-way-bottleneck):
Signalled with give-way and with restricted flow (e.g. signalled give-way):

Page 142
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. Also note how the presence of
Restricted Flow is represented by the presence of side-bars on the stop line.
10.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.

10.5.2 Shaping traffic streams, links and connectors
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.
10.6 Representation of controller streams and signal timings

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 15.4
10.7 Manipulating items

10.7.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.

Page 144
To select a rectangular selection of items, use the top toolbar option Select > Rectangular
Selection and drag a rectangle on the diagram.
10.7.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.
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 dont 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 links 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 together with the Save the network
diagram state in the main application Edit menu or toolbar.
10.7.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.
10.7.4 Adjusting spacing
The spacing between all network items can be adjusted by right-clicking 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.
Similarly, the lateral spacing between links and arms can be adjusted - right-click in a blank area
and select Tools>Adjust link/arm spacing.

10.7.5 Changing properties of items
Right-clicking on any item will show a menu appropriate to that item, from where you can access
all its properties (this will show the Data Editor screen), and also certain commonly used items,
such as a links 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 traffic stream data.
Note that in some cases you will 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 Signals Data screens, will update
to show data for the currently selected item, as does the Data Editor.
10.7.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 arrow button in the main toolbar.
Click on the traffic node item and then click anywhere in the diagram to add the node to
the network.
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. Each mouse click 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, click once to

Page 146
set the start point, again to set the end point, and then right-click to finish. You can also
finish the arm/link using the middle mouse button, which has the effect of staying in
arm/link-adding mode, so that you can easily add further arms/links of the same type.
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.
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)
NB 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 give-way properties etc.
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. Data Grids and
some of the dedicated screens can also be used to add items.
Depending on options you select in the (User) Preferences screen, the network diagram
may prompt you to enter an item ID each time you add a new item.
10.7.7 Merging Library Files into your network
You can merge Library Files into your existing network via the Junction button on the bottom
toolbar. Library files can be added to the network as many times as you like and at any time.
The use of Library 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. Library Files
can be regarding as building-blocks for your network.
10.7.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 a 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 a
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.
10.7.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 bendhandles 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.
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.

Page 148
10.7.10 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.
10.8 Viewing and visualising data in the network diagram

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.
10.8.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.

10.8.1.1 Scale Ruler (and changing the scale of your network)

A scale ruler can 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.
When not using any background image the current scale is unimportant, but when an image IS
used, it may be desirable or necessary to change the scale of the diagram to match that of the
background image. In order to do this simply add your background image to the network
diagram, line the scale ruler up with an item on the background of a known length (e.g. image
scale, 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 background item. This changes the diagram scale
to that of the background.
If you have difficulty locating the Scale on the diagram then right-click on the network
background and use the option Tools>Go to Scale Ruler.
Once your network is adapted to fit your diagram, the Link Lengths view (section 10.8.8.1) can
be used to quickly check to see if youve forgotten to enter any of your traffic stream (or link)
lengths.
10.8.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.

Page 150
10.8.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 captures 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 in the
case of the traffic model type overlay, the colour scheme used.
10.8.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.
10.8.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.
10.8.3 Controller cones, flow cones 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). The controller stream cones, shown in a
different colour, indicate which controller stream (signals) is associated with that particular

traffic stream (or link). Each traffic stream (or link) traffic flow feeds into the traffic node, but
its signals are controlled (if relevant) by the associated controller stream.
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.
You can also show flow cones highlighting the connections between traffic streams (or links).
10.8.4 Backdrop show and hide
Use the top toolbar Backdrop 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 Manage backdrops option offers a shortcut to the relevant part of the Network Options
screen.
10.8.5 Fast Mode
Use Fast Mode to turn off certain textual items to increase the drawing speed.
10.8.6 Signals
Use this top toolbar set of options to display actual signal states for each traffic stream (or link),
on the complete item and/or just the stop line and/or connectors. Use the Animation Controls
screen to set the point in 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 network options Display Red-with Amber and Display End-of-
green Amber are enabled.

Page 152
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 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.

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 45/1 towards the bottom of the network is showing
actual red, but the yellow arrows indicate that traffic is still be crossing the stop line.
10.8.7 Highlighting bus/tram/pedestrian crossings (and links)
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 bus, tram and pedestrian items are, as in the screenshot below, where
Highlight Bus Network has been chosen. To restore normal appearance, select Reset.

Page 154
10.8.8 Showing link lengths, queues, traffic flows
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, 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.
Each of the available Data menu items are described in the following sections.

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 MMQ overlay does include the random component of queue.
10.8.8.1 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, all the streams on the left-hand side of the junction are all 100m long.
Link Cx-long has been stretched to be longer than its real length so the yellow bars stop short of
the ends of the streams, and finishes with a dotted extension line. Stream C-short 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
streams C-right.
For internal streams (and links) the discrepancies can also be seen along the source connectors.
Often, it will not be possible to have all of these lengths matching simultaneous since the lengths
of the connectors can (and probably will be different and the length of the link is represented in
TRANSYT by a single (average) length.
10.8.8.2 Link/Stream Total Flow

Either total flows or calculated flows can be displayed as an overlay. 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

Page 156
other). You may wish to adjust the Other Overlays width (see Options > Data overlay) to
adjust the width of the bars to suit your needs.
10.8.8.3 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 the user specifies their 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.

10.8.8.4 Traffic (Queues and Occupancy)

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 flowing traffic
appears green and queued traffic appears in red.

Page 158
10.8.8.5 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, then 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, which will
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.
The uniform queue animation exactly matches the data shown in the Spatial Queue Graphs.
10.8.8.6 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.
10.8.8.7 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.
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.
10.8.8.8 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.

Page 160
10.8.9 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.
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>Appearance>Data
Overlays.

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 the user has entered a high (or non-zero) stop weighting for 3 of
them.

Page 162
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
section 13.2 for more details.
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, the 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.
The colour coding used is as follows:
Aquamarine - Platoon dispersion model (PDM)
Pale Yellow Congested PDM (CPDM)
Blue Cell Transmission Model (CTM)
White Quick PDM

A number of overlays are also available covering the most used/important model
results. These are:
Degree of Saturation
Utilised Storage
Practical Reserve Capacity
Mean delay per PCU
Mean stops per PCU
Mean Journey Speed
Each of these overlays use colour coding on the traffic streams and links to indicate which parts
the network have the best and worst results.

Page 164
The colour coding and value thresholds are hard-wired within TRANSYT so they offer an
absolute evaluation of the Network, rather than a comparative/relative one. The colour
thresholds for each overlay are as follows:
GREEN YELLOW PINK/RED DARK RED
Degree of Saturation <=80% >80% and >90% and >100%
<=Sat. <=100%
Threshold*
*usually set to
90%
Utilised Storage <=75% >75% and >100% n/a
<=100%
Practical Reserve >10% <10% and <=0% n/a

Capacity
>0%
Mean delay per PCU <= 20s > 20s >55s >80s
<=55s <=80s
Mean stops per PCU <100% >100% and >200% n/a
<=200%
Mean Journey Speed >=30kph >30kph and <15kph and <5kph
>=15kph >=5kph
10.9 Network Diagram Options screen

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 11. 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

10.9.1 Adding and manipulating backdrop images
Add one or more background images via the Backdrops tab. Select Manage backdrops from
the backdrops 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
red handles, which you can use to move and resize it. Use the opacity slider to control how faint
the image is relative to the rest of the diagram.
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.
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.

Page 166
10.9.2 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.
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
capture).
Text Sets are now within the users preferences (.config file) rather than within
the file so that they act as your personal collection of sets.
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 capture).

Page 168
10.9.3 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.
It is sometime useful to set Lanes to be either transparent or opaque especially when

you are using backdrops as well.
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 can be switched on so that you can set up arrows on each traffic stream (or
link) showing which way traffic is allowed to turn. Right-click on the traffic stream (or
link) and select from a left, straight or right user movement. The movement will be
depicted using a blue arrow at the stop line.
10.9.4 Taking the Network Diagram out of TRANSYT
If you have dual monitor display, either right-click in a blank area of the network and un-
select Tools>Keep Inside Application Window each time you open the network diagram, or
set your preference via the User Preferences screen. The network diagram will then become
detached from the main TRANSYT window and you can position it on the secondary monitor.

11 Three dimensional mode (3D)

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.
more-easily fit the network on one screen
more-easily examine the results by changing your view point of the network
put the network into context by adding network artefacts, such as street furniture,
buildings, trees, etc.
display results in a more intuitive way
emphasise particular outputs using 3D, while using 2D for the rest
3D mode is enabled by selecting the network diagrams 3D menu option Display diagram in 3D
The screen captures below illustrate the effect of switching from 2d to 3D.

Page 170
11.1 Navigation within a 3D network

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.
11.2 3D Results
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 11.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 11.2.2.

11.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 capture 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 Options>Appearance>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.

Page 172
11.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 moving traffic (in green) and stopped traffic (in red) 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.
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.

Page 174
11.3 Referencing/Adding 3D Models

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 backdrops, 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
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 backdrops, 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.
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.
11.4 Recording and Playing a Fly Through

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

Page 176
playback. These are NO 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.

Working with Analysis Sets, Demand Sets and Time Segments Page 177
12 Working with Analysis Sets, Demand Sets

and Time Segments
NOTE: The system of Analysis Sets and Demand Sets used in TRANSYT 15, although looking
similar, differs from that used in ARCADY.
Analysis Sets allow you to store multiple sets of data within a single file, representing, for
example, different signal plans and flows for AM and PM peak periods.
Demand Sets allow you to store different sets of flow data, which can optionally be
combined together. Each Analysis Set uses a single Demand Set, but this Demand Set can
reference any number of other Demand Sets.
Time Segments are used when using TRANSYT with more than one time segment
specified. For example you can run the TRANSYT model over a 60 minute period using 4 time
segments of 15 min each. Flows can optionally be entered for each time segment, or you can
set up TRANSYT to produce flows automatically; in either case, 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.
NB 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.
The current Analysis Set, Demand Set and Time Segment are always shown at the top of the
main window in Advanced Mode. Click on the icon next to each one to jump to the appropriate
part of the Data Outline where you can edit the definitions. 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 appropriate drop-down list. Any screens that show
data for each set will then automatically update.
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 data 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, as an additional reminder of
which sets will be used when you run the file. For Demand Sets, this is not
necessarily the same set as you are editing/viewing at the time, as it is the
specific Demand Set referenced by the current analysis set that is run.
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 the
new Demand Set will be a copy of the flows for the last selected Demand Set.

Page 178
12.1.1 Analysis Sets
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 > Show
Advanced Mode Items). 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.
Although multiple Analysis Sets can be stored within one file, only one set of
results is stored at any one time, representing the results from the last-run set.
To run different Analysis Sets, you must select each in turn via the Analysis Set
drop-down menu and run each separately. You can however use the Run>Run All
Analysis Sets and Generate Report option to run all Analysis Sets that have their
Include In Report option set.
As an example, add a new Analysis Set (via the Data Outline), and note that the drop-down
menu at the top of the TRANSYT window now lets you choose between two Analysis Sets. Now
use the Data Editor or Main Data screen to view the network cycle time; note that the network
cycle time has an icon next to it to indicate that it can be set for each Analysis Set. Set the
network cycle time to 100s. Switch to the other Analysis Set via the drop-down and notice that
the network cycle time is now the value for the other Analysis Set.
For each Analysis Set, you must enter a Demand Set (e.g. enter D2 to use Demand Set 2).
This determines the flows that will be used for this Analysis Set. E.g. you may set up two
Analysis Sets with the same signal plan but different Demand Sets (representing two different
traffic forecasts, say), a third Analysis Set that uses a Demand Set which includes extra
development flows, and then a further two Analysis Sets using the same Demand Sets but
alternative signal plans or network cycle times. (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.
If a file contains multiple analysis sets, the results in the file will be those
of the last-run set. If you change sets, and wish to examine the results,
you will need to press the Run Evaluation button to repopulate the file with
the new sets results. This will also prevent the Report ever presenting the
results of one analysis set alongside the input data of another.

12.1.2 Demand Sets
When you start a new file, the file contains a single Demand Set. To rename demand sets or to
use multiple demand sets the file must be in Advanced Mode (Main Menu: > Data > Show
Advanced Mode Items). 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.
Each Demand Set defines a separate set of flows, but the flows themselves are entered using
the normal data entry screens. This applies to OD Matrices as well, i.e. an OD-Matrix provides
access to define the OD flows for several 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 link flows for
individual links will be greyed out and will show the calculated total flow, as in the screenshot
below.

Page 180
To run a particular Demand Set, you must select an Analysis Set

that uses that Demand Set. Changing the Demand Set on the main
drop-down menu at the top of the main window does NOT select
that Demand Set for running, it only selects it for data entry. E.g. if
you have three Demand Sets and wish to run each in turn, you must also
set up three Analysis Sets.
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. N.B. the Summary Time Segment
flows will always be zero as no data is specified for this drop-down selection.
If not using OD Matrices to allocate flows, the Total Flow and Uniform Flow for each link can also
then be entered separately for each Demand Set, using the Data Editor and/or Data Grids.

Time varying flows must be entered via an OD Matrix You can no longer specify them directly
via entry source flows.
12.1.3 Locking Analysis and Demand 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 to be
changed by carrying out an optimised run. Furthermore, locking an Analysis set does not lock
the data of the referenced demand set.
12.1.4 Time Segments
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 13.1.1).
After running such a file, the Time Segment drop-down menu at the top of the main window 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 segments. You cannot see all time segments within the Data Outline or on one screen
together, but generated reports can optionally show results for all time segments.

Page 182
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.
Please note that 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 Network Results screen will be either the AVERAGE P.I. of all the segments or the
value of a currently selected time segment.

Working with Traffic Flows Page 183
13 Working with Traffic Flows

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 13.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. (In TRANSYT 12 and earlier these were referred to as upstream links). 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 items default Entry (Source), such as the entry cruise
speed etc. (NB Entry cruise speed means the cruise speed along the whole traffic stream for
traffic using this traffic stream as an entry traffic stream into the network - NOT the speed at the
entrance.)

Page 184
13.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 > Number of Time Segments) - See section
12.1.4. 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:
13.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.
13.1.1.2 Time-segment Flows using OD Matrices
Each link and source has a new 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 a 90 minute modelling period.) 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.
13.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 186
13.2 Link Data Screen

Launch this screen via the Links button on the main vertical toolbar or via View>Link Data
Screen. Only one of these screens can be shown at any one time. 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. For convenience you can examine and edit both the upstream and downstream link data
using the next two tabs. A Flow Consistency Tool is also embedded into this screen This is
described in section 13.3.
13.3 Flow Consistency

The flow consistency tool in TRANSYT 13 and TRANSYT 14 no longer exists
separately in TRANSYT Use the one integrated into the Traffic Stream Data
and Link Data screens.
Accessed from Flows tab of both the Link 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, the 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).
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

Page 188
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. The 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.

13.4 Flow Allocation and Assignment (Using Matrices)

Using OD Matrices (Toolbar>OD Flows) allows OD flows to be specified and automatically
assigned to links or traffic streams within a TRANSYT network. This avoids having to manually
assign 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 13-1 A highlighted OD Matrix path
OD flow allocation requires the use of a number of network diagram items such as Local OD
Matrices, WIDE-AREA OD Matrices, Locations and Paths:
A Local OD Matrix 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 be
easily predicted.
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.
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

Page 190
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 is used.
A Wide-Area OD Matrix contains traffic flows between Origins and Destinations which
are defined as WIDE-AREA Locations in TRANSYT. 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 so easily predicted, usually
because of the size of the area in which it covers, resulting in delay becoming a far more
important factor in drivers 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 matrixs control. There can be any number of
WIDE-AREA locations (but with a minimum of two per WIDE-AREA matrix).
13.4.1 Local OD Matrices, locations and paths
OD matrices and locations are created in a similar way to creating links, arms and controller
streams. This is described in section 10.7.6. The OD matrix must be created first so that the
locations can then be associated with the OD Matrix. Note: 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. The links or streams
of a path are specified by creating a list of link or stream IDs, separated by commas. 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.
In the case of Paths, however, it will often be far easier to 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.

Figure 13-2 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 13.4.4 for an explanation of the allocation options that can affect the
generation of paths.
13.4.2 WIDE-AREA OD Matrices
WIDE-AREA OD matrices are created in a similar way to ordinary OD Matrices. See section
13.4.5 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. Note:
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.

Page 192
13.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: This is the same as that previously provided in TRANSYT 14.0 - then the
only option. 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 13.4.6 for details.
Lane Balancing: When selected, this mode assigns traffic to TRANSYT paths in such a way as
to balance flows across all traffic streams on each entry to the junction (i.e. those lanes whose
source of traffic comes directly from a TRANSYT location. 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 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
CPDM 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.
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 25.11.
The Journey Time 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
13.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 25.11 for more detail on the Assignment model.
The allocation modes provided simply aid the process of establishing suitable
traffic flows throughout the network. Inevitably there will be situations where the
allocation of flows by these methods will not be suitable and in such situations
users have the freedom to specify flows in a more direct manner.
13.4.4 Flow allocation and flow assignment options
The local OD matrix data screen and wide-are matrix screen both have a number of other user
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.

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.
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 13-3 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. 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.
Figure 13-3 Allow looped paths on traffic nodes
Figure 13-4 Locations (for links and traffic streams)

Page 194
Limit Paths By Length: Select this option to allow only paths that are a factor
longer than that of the shortest path to be created. This option allows you to
more easily remove unrealistic paths and hence improve your results and speed
up runs of TRANSYT.
Path Length Limit Multiplier: Paths longer than this number times the shortest
path (between two locations) will not be created.
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.
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. A Data Grid can also be used to
examine and filter data associated with OD Matrices, Locations and 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.
13.4.5 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, links, traffic nodes and controller
streams (e.g. using the network diagram) in the usual way, if it does not already exist
2) Specify the Traffic Type for each traffic stream and link.
3) Add a Local OD-Matrix by dragging it from the network diagrams 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 link or streams if the network does not already have them. Exit links or streams
can be set as unrestricted types as they are not being used to model any restriction to
traffic.
Please note that there is no need to create traffic nodes at the ends of these. Also note
that for links and traffic streams using CTM, the cell saturation flow will still restrict traffic
entering traffic streams and links, so should still be set appropriately (see section 18.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
Assigning the flows:
Before defining any traffic flows you should consider whether or not you wish to use TRANSYTs
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 11 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) 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.)
10) Set the required Allocation Types of each path (see section 13.4.6). 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.
11) 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).

Page 196
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 28.
A few extra steps required when using a Wide-Area matrix:
Please follow the additional steps 12, 13 and 14 below:
12) Add a Wide-Area OD-Matrix by dragging it from the network diagrams bottom toolbar.
Wide-Area matrices are shown in the network diagram as large lime-green squares.
13) 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.

14) 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
15) Specify your Wide-Area OD Flows (see the section 13.4.7)
16) 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 Tools Assign from Wide-Area Matrix button.
17) 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 13.4.8).
These allow you to influence any subsequent assignment that you carry out.

Page 198
13.4.6 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 13.4.7.
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 grey 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 grey boxes.
Once the flows have been entered, there are local OD options that allow flows to be allocated to
links and streams. 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 13-5 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 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 is automatically allocated
When multiple paths (from one Location to another) exist, the user must specify how the
OD Matrix is to split the flow.
The splitting of flows between multiple paths is based on the user-selected Allocation
Type. The 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. Note: 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.
With the Auto Calculate option switched off the Reset Flows button can be used to set all path
flows to zero. The Allocate Flows applies the flows to 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 13-6 Path Allocation Type

After allocating the flows to streams and links 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 ODs. The numbers in brackets
represent any discrepancy (resultant entry) between the entry flows and the resultant flows
(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 200
Figure 13-7 Resultant Flows (with one discrepancy shown)
13.4.6.1 Flow Allocation Types Example

This figures shown here display how Fixed Flow, Percentage Flow and Normal Allocation each
work in a simple case.
Figure 13-8 Simplest OD Matrix
A single flow of 500 is specified from location 1 to location 2.
Figure 13-9 Fixed, Percentage and Normal Allocation Types

Links 1, 2 and 3 each have a different Allocation Types. Links 4 and 5 are set to normal the
same as for Link 3. The selected Allocation Mode in this exam500ple is Path Equalisation
Figure 13-10 Network Diagram showing allocated flows
Link 1s total flow is 150 as it is has been assigned a fixed flow of 150.
Link 2s total flow is 125 as it has been assigned 25% of the 500 flow.
Link 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
28.
13.4.7 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. 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.

Page 202
Figure 13-11 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 Flow Balancing Tool, 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 13-12 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. However, disabled local OD matrix paths do NOT affect assignment These will show
up as local OD resultant flow discrepancies if it prevents traffic locally from getting to its local
destination. 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.
The assignment process will always replace any Local OD matrix flows that are
covered by the wide-area matrix and will leave untouched those that arent, i.e.
traffic defined as travelling within the wide-area but never entering or leaving it
for example.
Figure 13-13 Wide-Area Paths
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 13-13). 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.

Page 204
13.4.8 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 13-14).
Figure 13-14 Assignment cost weighting
Assignment Cost weighting (%): Adjusting the assignment cost weighting (Figure 13-14)
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.

13.4.9 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 and NOT overlapping multiple OD
matrices.
13.4.10 Connecting the network at Local OD Matrix boundaries
When using multiple OD Matrices within one network care needs to be

taken Links (which are referenced through the path definitions) or traffic
streams 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 link (or traffic stream) of one is an entry link (or traffic
stream) of the other. This will generate an error on the task list. Either
the doubly-referenced links (or traffic streams) 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.
13.4.10.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

13.4.10.2 should also be read, as an additional consideration applies in this case.
Figure 13-15 Adjoined matrices This is OK and recommended.

Page 206
Figure 13-16 Adjoined matrices OK too, but see wide-area OD considerations
Figure 13-17 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, for example, 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 13-18) 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 13-19.

Figure 13-18 Local OD boundary
Figure 13-19 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
13-20. 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 13-20 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.

Page 208
Figure 13-21 OD Matrices that are not adjacent
13.4.10.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 wont be assigned) and there
exists an inconsistency between the wide-area matrix and the flows within the network.
13.4.11 Normal, 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 13-22 Normal, 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 13-23). All combinations of Normal, Bus and Tram are allowed on
traffic streams. Links can carry only one traffic type.
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 13-22 four bus
paths have been generated, although the actual network may well contain many
more which carry normal traffic. For links, the paths are determined by the
Source Type.
Figure 13-23 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).

Page 210
13.4.12 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 13.4.11 (normal, 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 13-24 Additional (Normal) Traffic Types
13.4.12.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
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
read-only tab simply reports the sum of the different traffic types flows that make up the
total Normal traffic.
Figure 13-25 Adding extra traffic types -before and after
Figure 13-26 OD Matrix with Light and Heavy traffic types

Page 212
13.4.13 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 13-27 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 youve 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.

13.4.13.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 13.4.12, 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 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 PCU, in which case you can
simply leave all the PCU factors set to 1.0.
Figure 13-28 Specifying PCU factors for Links
13.4.14 Pedestrian Data
The specifying of pedestrian flow data is described in detail on section 14.3
13.4.15 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.

Page 214
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 13-29 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 options 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.
13.4.16 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 215
14 Working with Pedestrians

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 release of TRANSYT 14.2 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 the user 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 TRANSYTs 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.
14.1 The Pedestrian Behaviour Model

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 14.6.

Page 216
14.2 Pedestrian Network Structure

A pedestrian network is constructed exclusively of pedestrian crossing objects.
14.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 14-1.
Figure 14-1 Pedestrian Crossing object

The pedestrian crossing object (Figure 14-1) is drawn in the network diagram as a single line
with one of two different symbols at each side of the crossing The one with 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 14.4, while there is more information about the network
diagram crossing object in section 14.6.1.
14.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 crossings 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 diagrams
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 14-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 14.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
14.4. Each crossing side is used in TRANSYT as the source of pedestrians (fed from an
OD Location).
14.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:
Figure 14-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.

Page 218
Figure 14-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 14-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 14-4 Approach with staggered crossing (and separate phasing)

Modelling of a staggered crossing (Figure 14-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 14-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.
Figure 14-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 14-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.

Page 220
14.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.
14.3 Pedestrian Flows

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
14-6). This allows one OD matrix to be used for both vehicular traffic and pedestrians.
Although not necessary, it is also possible to use separate OD matrices for pedestrians and
vehicles.
Full details of how to allocate flows to TRANSYT generally is covered in other parts of the User
Guide, e.g. chapter 13.

Figure 14-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
14-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 14-7 A typical pedestrian network of four crossings

Page 222
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 14-7 note how there is no loop formed as
there are no connectors between the crossings. They are connected only
via the locations.
14.4 Overview of Data requirements
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 8.5), which is accessed from the main vertical toolbar.
Figure 14-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 factors 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 14-9 Pedestrian crossing Side data

Page 224
Additionally you need to specify data that is specific to each side of the crossing (see Figure
14-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 IntoJunction 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.
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 14.4.1.
Finally you need to set up what conflicts exists between pedestrians and vehicular traffic see
Section 14.4.2. In this particular model vehicles never yield to pedestrians.

14.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 14-11). Full details of working with signals can be found in Chapter 15. 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 14-10 Controlling Phase
Figure 14-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 14-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

Page 226
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 14-12 Blackout time and associated effective green

14.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 14-13):
Figure 14-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 TRANSYTs 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.
14.5 Optimisation
In TRANSYT you have the choice as to whether or not pedestrian delays contribute to the
calculation of the Network Performance Index. For pedestrian crossing objects, 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 then you are
then more likely to want to also INCLUDE pedestrian delay in the P.I. and hence influence the
optimiser to provide optimised timings that offer the best multi-modal performance.

Page 228
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.
A global setting to exclude all pedestrian crossings/links from the results calculation (no matter
what the above option is set to is also provided (Outline: Network Options > Traffic Options >
Advanced).
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 14-14.
Figure 14-14 Pedestrian Delay costs
Delay weighting (%): Adjusting the delay weighting (Figure 14-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 14-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.
14.6 Pedestrian results and network animations

14.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 14-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 14-16 Pedestrian Crossing object with pedestrian MMQs
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.

Page 230
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 14-17.
Figure 14-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 the user) 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 14-18.
Figure 14-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 14-19).
All summary items also appear in the other topic-based sub-sections. (see Figure 14-20).
Figure 14-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 relate to both vehicles and pedestrians, these should be
read as per pedestrian where it is appropriate to do so.

Page 232
Figure 14-20 Pedestrian Results: Flows and Signals
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 PI as a result of the level of pedestrian gap-accepting set by
the user being exceeded.
For full details of the TRANSYT results see section 21.2.

14.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:

Page 234

Working with traffic signals Page 235
15 Working with Traffic Signals

15.1 Introduction to traffic signals in TRANSYT 15
This section briefly describes some important points to be aware of when working with signals in
TRANSYT 15, 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 15.4) are a useful way to view and edit stage timings within the network diagram. Finally,
the signals data screen (see 8.2) is particularly useful for defining all aspects of your signal
timings quickly and easily.
15.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 12.1.4.

Page 236
15.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.
The two Signal Representation Modes of TRANSYT 13 no longer exist in TRANSYT 15. However,
the Timings Diagram offers two different manipulation modes stage mode or phase mode.
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. All illustrated uses of the timings
diagrams are when it is in its Stage Mode rather than Phase Mode - Details of these modes
are described in 15.3.
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.
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 6 ends as soon as the first phase (phase A) running
in that stage ends, and phase B has a phase-losing delay, as is consistent with standard stage
definitions. Similarly for Stage 7 and Phase F.

15.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 links effective green starts and ends a few seconds after its actual green.
15.1.4 Dummy Phases and Dummy Links
If you wish to explicitly model separate stages even if no new phase begins, TRANSYT will now
allow you to do this. Therefore, this particular use of dummy links in earlier 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 238
15.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.
15.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.
15.1.6 Amber times
The advanced network options 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 Network Options (or View Tab on the Main
Data screen) 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 capture)
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 15.5.6.

15.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.
15.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.
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

Page 240
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.
15.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. 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 15.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 15.6.
The nominal first stage in the current stage sequence is indicated by a + sign next to the
sequence.
15.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.
15.1.11 Base / non-base stages
If a node 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, as shown below.
The screenshot below also shows that, at this double cycled node, there are eight stages: 4 base
stages plus 4 non-base stages. You will notice how the stage sequence is repeated.

15.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 Common Data screen
(or use the Data Outline and browse to Network Options>Optimisation Options) and select
Enable Optimisation, and turn off Auto Redistribute.
To optimise timings, select Enable Optimisation, and chose the Optimisation Level you wish to
use. 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.

Page 242
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 TRLs isolated junction
design and evaluation tool - OSCADY PRO.
15.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.
2. Controller Stream n Stage m min 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 links start
lag. (This would mean that the link could start after the stage finishes.)
15.2 Overview of Signal Timings

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.
15.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 - which is shown on the
diagram) or specify a phase gaining delay (see section for more on phase delays), to model the
fact that a phase is to start later than would otherwise be the case - Phase B in this example.

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 the user 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.

Page 244
Furthermore, a full intergreen matrix is required if you are planning to use any of TRANSYTs
phase and stage order optimisation features.
The following example shows the timings for controller stream 1 after 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. This is in
order to make it more obvious what you are looking at.
Stage 1 runs from 92s to 19s; Stage 2 runs from 29-87s.
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.
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.

In the screen shot above phase B is now adjusted to start at 5s 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 relative to the end of active intergreen.
15.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 15 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.

Page 246
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.

15.2.3 Stage parameters
Most stage parameters 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 33 seconds and stage 2 at 73 seconds.
The stage start times are defined by the intergreens and phase delays.
For those familiar with using percentage split times (e.g. in Australia) that define what
percentage of the cycle is taken up by each stage, these can be displayed by switching
then on using a File>Preferences>2.Localisation option.
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.
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.

Page 248
TRANSYT has calculated that the Stage Minimum for Stage 1 is 10s, in this case
because Phase A has a minimum green of 10s (entered via Controller
Stream>Phases>Phase A). In some cases this calculation is more complex e.g. Stage 1
could be shorter, because phase A could satisfy its minimum green outside 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 this 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 a user value.
If you wish to see resultant Stage Data that uses TRANSYT 12 definitions
you must switch these on (see Data Outline>Network Options/Display
TRANSYT 12 Style Timings). These will appear in the data editor prefixed
with TRANSYT e.g. TRANSYT Stage Start.
Stage 1 has a TRANSYT Stage Minimum of 15s. This is calculated

automatically and is always equal to Stage Minimum + TRANSYT Minimum
Preceding Interstage i.e. 10+5 = 15s. This number represents the
minimum length of the stage + interstage and is the main constraint used
by the signals optimiser.
TRANSYT has calculated that Stage 1 has a minimum Preceding Interstage of 10s.
This is shown using the diagonal shading (switch on via Appearance>Show minimum
preceding interstages). This represents the smallest preceding interstage that is
allowed, given phase intergreen constraints. If stage 1 started any earlier, then at least
one intergreen constraint would be broken.
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:

15.2.4 Phase parameters
Phase green period parameters 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. 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.
Phase A has only one green period in this example. It runs from 87s - 35s. It cannot run
earlier since it is constrained by the intergreens from Phase B to Phase A, but could start
later if a phase gaining delay was to be added.
Optionally, TRANSYT Starting/Ending Stage, TRANSYT Start Lag and TRANSYT

Minimum Start Lag can be reported These are enabled via Outline: Network Options

Page 250
15.2.5 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
users 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).
At the moment 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.
15.2.6 Stage definitions using Phase Mode
The Timings Diagram has two manipulation modes Phase Mode and Stage Mode. Stage
Mode is the default and the recommend mode for most situations. At any time you can switch
modes.
When in Stage Mode 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.
When In Phase Mode the assumption is that you do not care initially about the stages and
stage order and are more concerned about what phases run where and when. This mode offers
the most freedom (and is not dissimilar to the Free Mode button in TRANSYT 13). As you drag
phases about you will see how the stages are redefined based on the phases.
In this mode you can also directly edit the phase green periods (Start Time and End Time) from
either the data editor or from the Resultant Tab of the Signals Data screen (see screen shot).

Page 252
15.3 Timings Diagram

The Timings Diagram illustrates 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 many other important points about the way phases and stages fit
together and is one of two main ways of visualising the signal timings at each controller stream.
It can be used in conjunction with the Intergreen Matrix, Stage Sequence screens and Network
Diagram Timing Wheels (see 15.4).
You can show several Timings Diagrams at once and can lock each screen to show data for a
particular node 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:
Phase/Stage Mode: The operation of the Timings Diagram is governed by two modes of
operation Two buttons at the top right of the screen allow you to toggle between Stage Mode
(the default) and Phase Mode. In Stage Mode stages cannot be created or deleted by
dragging, while in Phase Mode as you drag the phase green periods, new stages are
automatically formed and defined, (based on standard stage definitions). Phase Mode gives
the most freedom (and is not dissimilar to the Free Mode in TRANSYT 13). Phases are moved
simply by dragging the green area of the phase to the left or right. In both modes phase start
and end times can be directly edited.
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.

15.3.1 Menu Items
Appearance>show effective greens: this shows the effective greens as a lighter green above the
actual green. It is on by default. Notice how the blue pedestrian phases 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.
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 254
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 stage timing hints: this switches on a permanent display of the stage starts,
stage ends and stage durations at the top of the diagram. This option is on 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 shop below). If blank, it is controlling nothing. When
showing links and traffic streams it shows the controlled items ID.

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 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
15.5

Page 256
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.
---------------------------------------------------
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>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>redistribute all stages (repair timings): This option reduces the stages to arbitrary stage
lengths with arbitrary intergreens. For convenience, a button is also provided for this option.
---------------------------------------------------
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)
---------------------------------------------------
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 the user enters 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.
15.3.2 Manipulating items
In Stage mode:
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.
This mode is the default and recommend for most situations, particularly if you are not
already familiar with TRANSYT signal timings. Stages are moved simply by 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.
In Phase Mode:
as you drag the phase green periods, new stages are automatically formed and defined,
(based on standard stage definitions). Phase Mode gives the most freedom (and is not
dissimilar to the Free Mode button in TRANSYT 13. Phases are moved simply by
dragging the green area of the phase to the left or right using the mouse (even if this
breaks intergreens or other constraints).
Far less rules apply when in this mode as constraints imposed by the presence and order
of stages in stage mode, do not apply. This mode is most useful when you wish to
quickly set up which phases run together and let TRANSYT define the stages for you
based on this.
Drag the start/end or middle of a phase over other stages to redefine stages
In either mode:
Drag the middle of a phases green period to move it
Drag the middle of a stage to move it
Drag the start/end of a phases green period to extend or shorten it (i.e.

create/destroy phase delays)
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 the stage. (Trimming a stage
removes any phase delays so that all links run exactly from the stage start to the
stage end.)
Right-click on a stage while horizontally level with another phase to quickly

select Enable Phase ? in Library Stage ?.

Page 258
Right-click on a phase to show a context menu that allows you to remove it from the
stage, remove the green period
Remember that if you make a mistake, just use the Undo/Redo buttons.

15.3.3 Entering signals data
The various options listed above are available so that the user can manipulate the phases,
intergreens, and stage data as they 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 8.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.
3. Right-click on the Controller Stream and select the option to show the 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. 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.
7. 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).
Alternative 3: Create the number of stages you want by clicking on Stage Library of
your controller stream, and use the Add a new Library Stage. Then click on each 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.

Page 260
8. Next, you can add phase delays (if needed) by dragging the end points of the green
periods. 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.
9. 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, use the data outline to select each one in turn. In the data outline click on the
controller stream and set the Use Sequence to the sequence you wish to use.
10. 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.
15.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. Since TRANSYT 14, and the introduction of the controller stream object, 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.

15.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

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. NB 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

Page 262
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.
15.4 Timing Wheels

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

Page 264
15.5 Intergreen Matrix Screen

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.
15.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:

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 the user 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
TRANSYTs advanced phase and stage order optimisation features.
15.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:

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

15.5.3 Establishing conflicts & intergreens from network geometry
It is laborious job working out conflicts and intergreen values. TRANSYT 15 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. Both vehicular and pedestrian conflicts are derived. Intergreen values are
also estimated for vehicle-vehicle conflicts based on the distance and probable conflict points.
These calculations are based on the UK Traffic Advisory Leaflet 1/06 Part 4.
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 backdrop 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 files 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.

Page 268
This tool has a number of limitations as follows:
No attempt is made to estimate intergreen values for pedestrian-vehicle and

vehicle-pedestrian conflicts. Any identified conflicts will have their value set to
zero.
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.
15.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.

15.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.

Page 270
15.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.
Amber times are specified for each phase via the Data Editor (Outline: Controller Stream n >
Phases > Phase n).

15.6 Stage Sequence Screen

Launch the Stage Sequence screen from the main vertical toolbar or via View>Stage Sequence
Diagram. 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
streams 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. Traffic streams and links leaving the controller stream area are shown. Minor
shared links (by default) are also shown in grey, but can be set to Same as Major using
Options/Minor Links menu.
A right-click option allows new blank stages to be inserted into the sequence.
We recommend using this screen in conjunction with the Timings Diagram.
15.6.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 272
15.6.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. A red vertical bar indicates the location into which the sequence is
placed (see screenshot).
Furthermore, using a second stage sequence diagram, locked to the stage library, you can drag
new stages from the library into your sequence displayed your other stage sequence diagram.
This makes it very quick and easy to set up the staging arrangement you want. Your starting
sequence can be totally blank.
15.6.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
isnt. If the line is missing altogether, this indicates that this transition is banned in both
directions. 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.
15.6.4 Options and Tools
Use the Options menu to control the appearance of the diagram.
Using the Tools menu, you can set all links to be either red or green.
Note that only base stages are shown; non-base stages are considered to be copies of base
stages and so are not shown.
15.7 Phase Delays

Phase delays are shown in the Data Outline as part of the relevant controller streams data. The
diagram below illustrates losing and gaining delays.

Page 274
Intergreen A to B = 6 seconds
Phase A
Relative phase
gaining delay = 2 s
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:
using the Data outline and Data editor
graphically, using the Timings Diagram
via the Delays tab inside the Signals Data Screen
15.8 Start/end displacements

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.
15.9 Multiple cycle times

A TRANSYT network can be set up to have multiple cycle times 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 streams Cycle Time Source set to NetworkDefault
(see Figure 15-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.

Page 276
Figure 15-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 TRANSYT the flow
profiles are 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.
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
TRANSYTs 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.
With the introduction of multiple cycle times in TRANSYT 15 the data outline has also been
enhanced so that it 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 streams
cycle time.

Different cycle times and multi-cycling options for each sub-network can also be investigated
using TRANSYTs enhanced Cycle Time Optimiser (CYOP). See section 26.11.
15.9.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.

Page 278

Working with flared Approaches Page 279
16 Working with Flared Approaches

This chapter describes how to correctly model the extra capacity available from flared approaches
(due to short lanes at the stop line) using the available facilities.
Flares can be modelled using two different techniques. One way 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 introduced in the
following two sections.
16.1.1.1 Advanced 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.
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.

Page 280
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 16-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
couldnt, 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:
16.1.2 Simple Flare Example
The simplest example (Figure 16-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 dont 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 16-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 16-2 A simple flare on-street
To set up this flare correctly the following is required:
1. A traffic stream (with restricted flow) 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 one for the normal lane and one for the flared area. Optionally, you can also

specify an extra traffic node for Arm 1 this can make the items easier to manipulate in
2. The two stop line lanes that represent the flared area in this example are modelled as
separate signalled traffic streams in order to model the potentially different queueing
behaviour on each lane.
Figure 16-3 Flare model of a simple flare
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 (Main Lane) and 2/2 (Flare) have their
traffic model set as Flare so that they will block. 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 often 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 a user-defined maximum
queue storage value specified (Outline: Traffic Stream n>Modelling).
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.

Page 282
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 16-4 Cyclic Flow Profile of exiting traffic
Figure 16-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 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.
16.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 16-5 Example Network of a flare
Figure 16-6 Data Outline and Flare Results

Page 284
For the feeding (upstream) traffic stream (traffic stream 2Cf/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.
16.2 Flared approaches - quick flares

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 16-7 by defining one or more quick flares on a link.
main lane
flare
The non-linear saturation flow is of the stepped form shown in Figure 16-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. TRANSYT 14 will import existing flares, but will not attempt
to convert them.
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.
A summary of how quick flares work and how they are specified is retained in this section to allow
them to be understood by anyone who comes across them, and is not intended to give full details
of their use Full details are available In AG63 TRANSYT 13 User Guide. (Binning et al, 2008).
Figure 16-9 Data Outline 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, the user is
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)
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.

Page 286
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 Number of 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 Extra capacity due to 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 downstream links. 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.
16.2.1 Flare fully used
For a single-lane link 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.
16.2.2 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). The user can be assisted in specifying this value by
use of QueProb. 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:
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.

Page 288

Working with priority junctions Page 289
17 Working with Priority Junctions

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 25.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 25.5 as well. Section 17.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, users 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 users
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 7.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.
Figure 17-1 Example priority T-junction

Page 290
Figure 17-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.
17.1 What is a Priority Object?

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 25.5) needed to model the junctions priorities and optionally assigns
these coefficients to the link structure or lane 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 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.
Both ARCADY and PICADY can be registered from within TRANSYT using the main
menu option Help > Manage Licences.
Figure 17-2 T-junction using a Priority Object
17.2 Using a Priority Object library file

Figure 17-2 shows the lane and traffic stream network structure of the simple T-junction (Figure
17-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 diagrams vertical 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.

Page 292
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
17-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 17-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 13.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 .T15 file, but can also be
saved as a new library file if you wish.

17.3 Applying a Priority Object to an existing network

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 objects 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 17-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 17-4 and Figure 17-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 17-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 17-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 17.3.1.

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

Figure 17-6 Priority Object Link names (Drive-on-the-right)
Another important property 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 25.5 or read the
relevant sections of an ARCADY or PICADY User Guide.
17.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
stream(s) or Link(s) that do not exist and will try to set up unnecessary conflicting movements
of traffic (see Figure 17-7 and Figure 17-8).
Figure 17-7 Priority object - Exit only on Arm A

Page 296
Figure 17-8 Arm B to Arm C movement has no conflicts
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.
17.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 17-9).
Figure 17-9 T-junction with no right turn from Arm B
Where a priority (conflict) does not exist within the priority objects 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.
17.4 Using an Arm, Traffic Stream and Lane Structure

Figure 17-13 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 17.8 (Using Links to define your priority junction).
Figure 17-10 Network structure using arms, traffic streams and lanes
17.5 Steps required using arms, traffic streams and lanes

This section lists, in a suggested order only, 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 task
are described in the following sub-sections. Note that non-essential data items such as Name

Page 298
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 re-position them appropriately.
1. Using the network diagram, add a traffic node 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 Streams Data screen.
The Saturation Flow Source is defaulted to SumOfLanes. If the traffic stream has
only one lane (as for this example) the Saturation Flow Source can be left as the default.
This automatically assigns the sum of the individual lane saturation flows to the traffic
stream saturation flow. However, there is the option DirectlyEntered if you wish to set
the traffic streams saturation flow directly. Pure give-ways do not use the Saturation
Flow value, but give-ways with a restricted flow (give-way bottlenecks) do need it.
4. 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 C2 (Outline: Arm
B2>Traffic streams>Traffic Stream 1). The Is Signal controlled option should be de-
selected as the arm is not signalled. The exiting arms A2x and C2x 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 an unrestricted traffic stream (sandy-coloured in the network diagram).
The signal data such as Controller Stream will be disabled, as the junction is not
signal controlled.
5. Enter lane data using either the Data Editor or the Lanes Data screen. The only
information you need here is the Saturation Flow. This can be measured and entered
directly, or the RR67 option used to derive it from various geometric parameters. Full
details on using the RR67 option are described in section 3.5.5.
For Arm A2 the traffic stream option Has Restricted Flow should be disabled, or the
saturation flow set to a very high value to ensure that no queueing will occur on these
lanes. (Often the value 9999 is used, as it an established and recognisable value used for
this particular situation.) Arm B2 give-way will not use the saturation flow value so can
be left as the default. Arm C2 does not use the saturation flow value either but a give-
way max flow for the straight ahead movement (Movement A2x/1) is required, and is set
automatically to 1800 This ensures that results match PICADYs as closely as possible.
6. 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, remembering to follow the order as described. 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 13.4.
7. Either add a T-junction Priority Object or add your Give Way Data manually. See
section 17.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 C2/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 17-20. 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.
Figure 17-11 Give Way Data (using Data Editor)
Figure 17-12 Give Way Data (using Traffic Stream Screen)

Page 300
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 17.7 for an explanation of what this option does.
8. Specify your movements and conflicts (or add a T-junction Priority Object). See section
17.6 on how to set up movements and conflicts. See section 17.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.
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 17.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.
9. Check the Task List for errors and if error-free, run the file.
10. 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 17-13 Movements, conflicts and example conflict data

17.6 Movements and Conflicts

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 17.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.
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 C2/1 needs two movements specified to traffic stream B2x/1
and to A2x/1 (see Figure 17-14). 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 17-14 Movements for Arm C2 (major left arm)

Page 302
B2/1 requires movements to C2/1 and A2x/1 as again the give-way properties for each
movement are different, e.g. different conflicts and give-way coefficients.
Figure 17-15 Movements for Arm B2 (minor arm)
However, A2/1 does not require ANY movements defined as both traffic movements (to B2x/1
and C2x/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 separate movements
should be defined.) They CAN be specified for consistency and will not affect the model, but are
not required in this example.
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 Stream Screen.
Figure 17-16 Conflicts for Arm C2 (right-turn movement)

Figure 17-17 All four conflicts for Arm B2 (right-turn movement)
Figure 17-18 Conflicts for Arm B2 (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 TrafficStreamMovement
or TrafficStream. 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

Page 304
to specify that the different movements conflict in different ways even when all the traffic
conflicts. We therefore chose TrafficStreamMovement (see Figure 17-16, Figure 17-17 and
Figure 17-18 and Figure 17-19). 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 TrafficStreamMovement as is the case
here. TRANSYT allows users 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 25.5 if you wish to know more.
The Upstream Signals Visible defines how give-way traffic reacts to upstream signals See
17.16 for fully details.
Give-way conflicts do NOT have to involve traffic crossing each others 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 (A2 to B2x in the example) affects the capacity
of the minor arm B2.
17.7 Visibility Adjustment

At priority junctions, drivers 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 (TRLs 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.
17.8 Using Links to define your priority junction

This section briefly describes how to model priority junctions using a link network structure.
Alternative methods are described in earlier sections 17.2, 17.3 and 17.4. We recommend that
you read these sections too, as they contain information relevant to this method too.
Figure 17-13 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 section 13.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 17-19 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 which uses arms, lanes and 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.

Page 306
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 17-20 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 17.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 17.7 for an explanation of what this option does.

17.9 Modelling crossroads

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 17.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 17-21 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 17-21 for an example.

Page 308
Figure 17-22 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.
17.10 Modelling roundabouts

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 17.4 , first to learn
about how to define give-ways generally and optionally section 25.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 17.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 17-23) The model requires four Entries to be added
to 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 - unlike
TRANSYT 14 which required a minimum of two.
The steps described in section 17.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 7 (from section 17.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 17-23 Traffic Stream and Lane Structure of a roundabout

Page 310
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 17-24 Roundabout Conflicts
For each approach you are required to specify how many Conflicts you need 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.
The ability to specify multiple circulating traffic streams within the Roundabout
Priority Object is new to TRANSYT 15.
Figure 17-24 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 8 Add your Roundabout Priority Object data:

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.
Arm 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 arms (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 17-25 Roundabout Priority Object data

The Type value should be set depending on whether you are referencing traffic streams or
links.

Page 312
The geometric data associated with each entry to a standard roundabout is shown in Figure
17-26. 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 17-26 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 now tolerates
different cycle times within a file, storing 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.
17.11 Using Links to define your roundabout

This section briefly describes how to model roundabouts using a link network structure. An
alternative method is described in the previous section 17.10. We recommend that you read
this section too, as it contains information relevant to this method.
Figure 17-27 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 13.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 17-27 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

Page 314
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 28 modelling signalled roundabouts in order to
ensure you fully understand the link structures required.
17.12 Mutual opposition

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.
17.13 Modelling variations of give-way

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.

17.13.1 T-junction with Two lanes on the minor road and no blocking of
straight ahead traffic by right-turners
Figure 17-28 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.

Page 316
17.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 17-29 T-junction with one lane on minor road (using links)
17.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 effect of the turning traffic blocking or not blocking traffic travelling straight ahead is
modelled using either shared or non-shared links, or one or two traffic streams.
However, between full blocking and no blocking (as it is known in PICADY) traffic may block
after filling up the turning bay For technical reasons it has not been possible to re-use the
PICADY partial-blocking model inside TRANSYT, but another technique can be used instead
which should give similar results:
The Congested PDM model (CPDM) can be used to model the blocking effect.
The diagrams below show an example of partial blocking in operation. In the first diagram link
28 is about to block The red line indicates the queue and the cyan cells show the flow rates
In the second diagram the queue has reached the end of the link and a queue is now forming on
upstream Link 30. Link 27 is now also being starved of traffic now that it is blocked.
The model also takes into account the random effects on the likelihood of blocking.
A lane equivalent of this model can also be set up in a similar way. (See supplied Library File.)

Figure 17-30 Partial blocking using Flare model About to block
Figure 17-31 Partial blocking using Flare Model - Blocked
17.13.4 New Zealand-style nearside turn give-way
In New Zealand traffic turning left into a minor road gives way to traffic turning right from the
main carriageway, as shown in Figure 17-32. This is easy to set up in TRANSYT, but may
require calibration and/or validation in order to obtain suitable give-way parameters. The give-
way values suggested here are simply starting values which should be adjusted in light of local
data.

Page 318
Figure 17-32 New Zealand give-way
The right turn lane can be set as simply a restricted traffic stream (or link), while the opposite
main road approach is modelled as a give-way. The left turn movement into the minor road (A1
into B1) has a single conflict with the right turning traffic opposite (C2). Therefore the
controlling traffic stream is C2/1. It is suggested that the give-way coefficients can be obtained
by applying those associated with the right-turn movement in the UK (which is usually giving
way). These can be obtained by making the required geometric measurements and using them
either in PICADY or in the Priority Object in TRANSYT to calculate the coefficients.
The Priority Object Auto-Assign Priority should not be used as it assumes specific conflicts exist
between specific movements (as would be encountered in the UK) which dont match those of
New Zealand.
17.13.5 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 17-33 T-junction with slip-road
Figure 17-34 Model of T-junction with slip-road

Page 320
17.14 Give-ways within signalled junctions

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 17.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.
17.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 17.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 17-35 Simple signalised T-junction with opposed offside-turn movement
Shown in Figure 17-35 is a fully signalled T-junction where the offside turners from Arm 1 have
been modelled as wholly opposed.
The way to set this up is:
1. Start off with each approach traffic stream defined as signalled controlled (e.g. Arm 1 >
Traffic Streams > Traffic Stream 1 > Is Signal Controlled) and with a restricted flow (i.e. a
saturation flow), e.g. Traffic Stream 1 > Has Restricted Flow
2. You also need to specify Arm 1 (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 17.14.8.
3. Now specify the give-way data (Arm 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 322
Figure 17-36 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 17.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 1 > Give Way Data > General Tab)
7. Now switch to the Conflicts data (See Figure 17-36)Figure 17-39. 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 1 > Give Way Data > Conflicts Tab).
N.B. The Max Flow (opposed) is simply the Saturation Flow which youve 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 2/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 17.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.
17.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 17-37 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 17-37). This additional lane has the right turn give way parameters. An
alternative method is described in section 17.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 324
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 restricted give-way (i.e. give-
way bottleneck). Give-way, because it is giving way to opposing traffic, and has
restricted flow (saturation flow) as this value is needed by the RR67 step-wise opposed
turn model.
3. Traffic Stream 1B/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 traffic node between Arms 1 and 1B Although this is Node is not
essential, its presence avoids the need to additionally set the OD Matrix property Allow Looped
Paths on Traffic Nodes see section 13.4.4 for the reason for this.
17.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 TRANSYTs phase and stage
optimisation), you should use the recommended method in which the
storage area is explicitly modelled using its own traffic stream.

17.14.3 Opposed offside turn with a turn bay
Figure 17-38 T-junction with offside turn bay
Where a right turn bay exists, as shown in Figure 17-38, 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 17.14.1

Page 326
17.14.4 Opposed offside turn with a turn bay and storage area
Figure 17-39 T-junction with offside turn bay and modelled storage
Where a right turn bay exists, as shown in Figure 17-39, 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
17.14.2.

17.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 TRANSYTs 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-heads 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 15 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 328
17.14.6 Two-lane situation with a turn bay
Figure 17-40 Two-lane approach with additional opposed-turn bay
Sometimes, a multi-lane approach may include a right-turn bay. Since the development of
TRANSYT 14 this situation, which previously required considerable care and consideration, is now
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 restricted
(bottleneck) traffic stream.
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 17-41 Diagram overlay shows where the Flare (CPDM) model is used.
17.14.6.1 Alternative method using quick flares.
Despite the ease in which this situation can now be modelled in TRANSYT, it is possible that
TRANSYT users will still come across the former way of modelling this situation and hence the
details of how to do this have been retained here for reference:
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 link 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

Page 330
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 lane. In this situation (seen in Figure 17-40) 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.
17.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 (N/A) and two RR67-related pieces of
information 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 17-42 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 which are for use when applying the step-wise opposed turn model are
also required:
The first of these additional parameters 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 additional parameters 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.
17.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 junctions performance. Below 50%, the figures can
become somewhat pessimistic.

Page 332
17.15 Give-way simplifications you can make

1. Only specify give-way movements that you need if never opposed you dont 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 dont 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 25.5.2.
17.16 Indirect traffic control and give-way bottlenecks

Using a give-way with a restricted 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 separate restricted flow is one that is controlled by the
restricted flow parameters (i.e. 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 17-43 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 restricted flow and enter both the give-way and restricted 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,
introduced in TRANSYT 14, is the additional conflict option Upstream Signals Visible (see
Figure 17-43). This allows, say, a controlling link to be a restricted or unrestricted traffic stream
(or link) and it still takes 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 streams (or
links) OUT-profile.

Page 334
Figure 17-44 Example of near-side slip lane
Figure 17-45 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 17-46 OUT-profile from the give-way
The OUT-profile in Figure 17-46 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).

Page 336

Working with Traffic Models Page 337
18 Working with Traffic Models

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.
18.1 Traffic Model selection

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 24 (Traffic Behaviour
Models (PDM/CTM/CPDM)) 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 18-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).
PDM: Select this if you wish to use the platoon dispersion model for this particular traffic
stream (or link).

Page 338
CTM: Select this if you wish to use the cell transmission model for 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 link 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.
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.
The network diagram overlay Traffic Model Type can be used to inspect what links and TS are
modelled using which model.
18.2 Vehicle-In-Service and the Random Parameter

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.

Working with Traffic Models Page 339
Figure 18-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.
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:

Page 340
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.
18.3 Setting Cell Saturation flows

If unsure what value to set for the Cell Sat Flow, a good starting point would be to 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. You may find TA 79/99 "Traffic Capacity of Urban Roads" a
useful reference.

Working with Results Page 341
19 Working with Results

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 items 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 streams (or link) results
Basic results for parts of the network, such as collection/routes, 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 TRLs 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.
Basic results are saved in the file when you save it - To generate animation and graph data the
file needs to be re-run. What animation and graph data exists depends on what traffic model
are used to model the traffic streams and links in the network.
If you are displaying results, including graphs and animations, remember that
these represent results from the last successful run of TRANSYT. If you
subsequently change, say, the cycle time, but dont re-run TRANSYT, then the
results may be inconsistent with the current data file.
Remember also that results are available for only one Analysis Set at a time.
19.1 Summary Results Screen

The Summary Results screen serves as a summary of the file status and results from the last
run of the file. It is automatically shown as soon as you run a file and it is recommended that
you leave it visible all the time - The window docking facility can help with this.

Page 342
Note that only one set of results is stored at any one time, for one Analysis Set.
The Summary Result screen shows the name of the Analysis Set that was used for
the last run (Analysis Set Used); if you select a different Analysis Set, the name
will be highlighted in yellow to indicate that the results are from a different
Analysis Set. To see results for the new Analysis Set, you must press the
Run button.
The Last run item shows the date and time of the last time the file was run. If you have
changed any data item since the last run, then this will be highlighted in yellow to indicate that
the results are potentially out of date, as in the example below. This will also be the case if you
load in a file that you have run previously. If in doubt, run the file again.
The Run Data Present status is only indicative of the presence of the extra, detailed results
data for graphs and animations - General results such as Performance Index is always available
(assuming the file has been run at least once prior to saving it originally).
The other items shown in the screen are mostly a repeat of data that can be viewed in the Data
Editor in the Network Results section.
Two buttons are provided at the bottom of the window to provide easy access to the resultant
stages (including stage timings) and green periods (including phase timings).
19.2 Detailed results

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 21 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:

When looking at results, some items may appear as N/A. 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. You can check this by showing the Help>Glossary
screen. In many cases inapplicable data items will simply be hidden from you.
Data Grids (see below) can also be used to display results, either as they are, or in a
customised format (see section 9.1.11 for how to use data grids to show results.)
19.3 Animation controls

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 may be visible in the Timings Diagram and other screens.

Page 344
When multiple cycle times exist within the network there will be multiple time-lines displayed.
See the network diagram (Chapter 10) for details of the items that can be animated.
19.4 Graphs
After running a file, you can view various graphs for each traffic stream or link. All but one of
these are accessed via the Flow Graphs and Spatial Graphs buttons on the main vertical toolbar,
or via Main Menu > View. PI-Offset graphs are access from Main Menu > Tools.
You can display any number of graphs; each graph will update to show data for
the current item unless you use its padlock (see section 6.9). 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 which data is available.
All graphs can be copied to the clipboard (via right-clicking) and you can also
include Cyclic Flow Profile graphs in reports by adding entries to the
Options>Reporting>CFP Graphs section of the Data Outline. These are arranged
in 2x2 blocks when you generate a report.
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.

19.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
24.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.
Details of where the traffic comes from is 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 graphs 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).

Page 346
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 as follows:
1. The time-axis can be rotated in order to align different graphs to the same time at the
origin (such as the networks 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 how many PCUs are currently on the traffic stream (or link)
at any point in the cycle.
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 observers 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 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.
19.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 and are as follows - Flows, Occupancy, Queue and 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).

Page 348
19.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.

19.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 capture 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.

Page 350
In the screen capture 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.
19.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 capture that there is an obvious void where the
typical saw-tooth shaped queue will be.
19.4.2.4 Traffic:
This plot is a combination of both the queue and flow graphs. It is similar to the occupancy
graph but 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 red is
used indicate values in between. This graph corresponds to the network diagram Traffic
overlay (in 2D and 3D). It is particularly useful because it that combines the effects of two
graphs such that you can see both the total volume of traffic and what that traffic is doing.

19.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.

Page 352
19.5 Time Distance Diagram

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.
Figure 19-1 A typical (non-cumulative) time distance diagram

19.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 19.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 19-2).

Figure 19-2 CTM Flow Mode showing three cycles

19.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, or via View>Time Distance Diagram.
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 Route, Path, Link or Traffic Stream selection. 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 6.9). 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.
19.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

Page 354
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.
19.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.
19.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 TDDs 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.
Figure 19-3 Time Distance Diagram showing dispersion

19.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 19-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 19-4 Non-cumulative reset

Page 356
Figure 19-5 Cumulative Progression
Figure 19-6 PDM Flow Mode
Figure 19-7 CTM Flow Mode

19.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 networks 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
19-7 with Figure 19-8.
Figure 19-8 The effect of a 200 PCU/hr Flow Threshold

Page 358

Generating Reports Page 359
20 Generating Reports
After running a file in TRANSYT, you can choose to generate a report that summarises all input
data and results. The report is in the form of a HTML file that is automatically saved to disk.
(You can also generate reports before running the file, in which case the report will contain only
input data.)
Click this button to configure a report.
Click this button on the main toolbar to generate a report.
20.1 Report Configurator

The contents of TRANSYT reports are configurable. The Report configurator allows you to decide
exactly what you want or dont 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.
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 youve 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 20.3).

Page 360
Generated reports are useful both a) as final reports summarising a TRANSYT file and b) a
convenient way to quickly view all data in a tabular format.
To generate a quick report, show the Report Configurator then turn off all options other than the
Final Prediction Table option. See chapter 20 for a detailed description of each of the individual
results.
Turn on Final Prediction Table and TRANSYT 12 Tables to include a set of summary tables that
resemble the main tables shown in TRANSYT 12 PRT files.
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 6.18)
Note that the order of links, traffic streams and nodes in reports uses the sorting and grouping
selected via the Options>Sorting section of the Data Outline and you therefore 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.
Some report content will not appear if it is unselected in the files Network Options.
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.
20.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.
20.1.2 Report Options
There are various options affecting the contents and appearance of reports, available via the
Options tab.

Page 362
20.1.2.1 Spreadsheet Export Mode

If this is selected, the formatting of the report will be altered slightly in order to give more
reliable results when copying and pasting into a word processor or spreadsheet.
20.1.2.2 Use Metafiles

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.
Some web browsers or word processors, however, may not recognise the vector images. In
such cases, turn off this option to use standard bitmaps for all diagrams.
20.1.2.3 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.
20.1.2.4 Show Time Segments

When selected, results are shown for each time segment. Has no effect if only one time
segment exists.
20.1.2.5 Show summary time Segments

When selected, results are shown for the special summary item. Has no effect if only one time
segment exists.
20.1.3 Using custom grid layouts in reports
If you use the Data Grid screen (chapter 9) 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).
20.2 About Report Files

Each generated report is an HTML document, whose filename is based on the filename of the
current data file. It will be saved to the same location as the data file or to a specified folder. 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. These options are set via the
user Preferences Screen (not the Report Config screen) see section 6.18.
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.
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.
20.3 Report Viewer

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.
Reports are saved in the location specified on the user Preferences Screen (section 6.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. In either case, the filenames of the report

Page 364
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.
20.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 20.1.2).
The Refresh button does NOT re-run TRANSYT for you. Therefore, if the TRANSYT
data has changed (or a different Analysis Set selected) 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 dont 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.
20.3.2 Report Viewer Tools
Note: 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. (Experiment with the configuration option Spreadsheet Export
Mode) 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. As
long as you printing to standard A4 size paper in portrait orientation, no tables should be broken
across pages. If you wish to print on other size paper, or remove the page breaks, we
recommend pasting the report into a word processor and formatting from there, or using the
report viewer Convert options to create a Word or PDF version of the report. Converting to a
PDF offers the best way to obtain good pagination within the report.
The Report Viewers Tools drop-down menu will show a menu containing a few utility functions:
Open this reports 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.
20.4 File Comparison Utility

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 option.
This will show the screen below, which lists each file currently loaded in TRANSYT (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.
Tick the Compare box for each file that you wish to compare. Note that there is no limit to how
many files can be compared at once. Choose a colour for each file (by double clicking in the
Colour column) to be used when differences are found.
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 first ticked file) are always printed, and values for the other files printed
where they differ.

Page 366
The master file is also used during the comparison as the file that is assumed to have the
correct number of controller streams, lanes and links 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 on the Report Viewer screen. 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 first
example shows all the results from the selected files irrespective of whether or not they are
different.
With Only show differences turned on, the report extract appears as below. This time, the rows
and columns that are the same are not printed at all. This makes it 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.
If you try to compare files that have different numbers of traffic streams, lanes or links, or do
not match up at all, then you will either receive a warning message or else the report will appear

but show question marks, as shown below. Link 14 exists in the first (red) file but does not exist
at all in the second (blue) file, so its results appear as question marks.
20.4.1 Comparing Analysis and Demand Sets
The Compare Files option in TRANSYT compares only the currently selected Analysis set, so
works automatically when working with only single analysis and demand sets.
For files with multiple analysis sets you need to select the first set you wish to compare at the
top of the main window and then run the Compare Files option. Then select each analysis set in
turn, running the Compare Files option each time.
If you wish to compare analysis sets within one file with each other, you can use the File>Copy
Into New File option to save the file and then swap the analysis set data over so that A1 data is
A2 and vice-versa. If the only difference between analysis sets is the referenced demand set
this is relatively easy as all you need to do is swap these references and then run a comparison
between the original file and the new one. If the differences between the analysis sets extend
beyond different demand sets then the easiest way is to right-click on the set you wish to
compare and make a copy of the set. Do the same in both files ensuring that the analysis set
you now wish to compare is the same one in each file. Simply select this set at the top of the
main window and run a comparison as usual.
Dont forget that file comparisons can be easily carried out outside of TRANSYT
using the standard cut and paste facilities (out of AND into TRANSYT), if the
specific comparison facilities provided dont meet your needs.

Page 368

X-Y Graph Analyser Page 369
21 TRANSYT 15 Outputs
This chapter provides a description of the TRANSYT table-based output and a description of the
main output values provided within the 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.
21.1 Traffic model predictions

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: Describing what version of TRANSYT produced the results
File Info: Includes filename used; date and time the file was run; which
analysis set was run; location of file, etc.
Network Diagram > Main Diagram: A the network diagram image of the
complete network.
Network Diagram > Custom views: Any saved views of the network that
have been selected to appear in the report (see the network diagrams
Manage Views screen).
For each Analysis Set:
Contents: A hierarchical set of links to each section of the report
Summary: This section lists data errors, data warnings and data Information
statements. It also provides File Information such as the Run Title, file status
and units used. N.B. 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 as part of the summary.
When requesting Input (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 various input data

items which are common to the complete network, such as network cycle
time. Includes optimisation data which includes the order in which controller
streams are optimised, whether they are grouped, and whether or not the
enhanced optimisation option has been used, and locked green splits.
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
Priority Objects: Details of the data for each roundabout, T-junction or

crossroad object, including ARCADY and PICADY geometry data.

Page 370
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 Giveway 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.
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.
When requesting Signals (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 Input:
Controller Stream Data
Phase Data
Library Stage Data
Stage Sequences Data
Intergreen Matrix
Banned Stage changes Matrix
Sub-heading Output:
Resultant Interstage Matrix
Resultant Clearance Times
Resultant Stages
Resultant (Phase) Green Periods:

Resultant Offsets: When requesting this 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:
Timings Diagrams and Stage Sequence Diagrams
When requesting TRANSYT 12 Tables: (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, it must not be hidden
by the Network Option that hides all TRANSYT 12 timings in the GUI.
This group of tables includes details of Resultant Stages, Resultant Phase Green
Periods, TRANSYT 12 style Stage Timings, Traffic Stream (and link) green times
When requesting Output (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.
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 above): Same as

the above, but results for all links combined, within the network.
Point to Point Journey Times: A point-to-point journey time tables for each
user-defined OD Matrix.

Page 372
Final Prediction Table: This is a summary table of Link and Traffic Stream
results. It includes results for every individual traffic stream, link and
pedestrian crossing as well as network totals and totals for each collection.
Collections: When requesting Collections in the report a full list of the

available collections is reported. A set of results for each collection marked
with Include In Report will as be included. Each set of results is calculated
for each individual collection which has been defined by the user. Results for
any Collections are also presented within the data Outline, in the same way
they are presented for individual links, traffic streams and the complete
network.
Cyclic Flow Profile Graphs: Full collection of user-specified CFP graphs.
When requesting Custom Grids (This is a collection of user-defined tables which have
been created using a Data Grid, and then selected by the user to appear in the report):
User-defined tables
You can double-click on this item to gain access to which custom grids should
appear in the report.
21.2 TRANSYT individual link or traffic stream predictions

This section provides a description of the main output values provided within the TRANSYT
results relating to each individual traffic stream and link. The results presented as those
presented in 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 data following network-wide results are part of the Report Final Prediction Table AND part of
the Report 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.
21.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 21.2.2

Stops and Delays results See 21.2.3
Queue and Blocking results See 21.2.4
Advanced results See 21.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.
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 LTS (link or traffic stream) (PCU/hour)
Calculated Saturation flow (PCU/hour (of green)).
Actual Green Time (seconds per cycle)
Mean delay per PCU (seconds)
Mean maximum queue (PCU)
Utilised storage (%) This value (new to TRANSYT 15) 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 be 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

Page 374
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 - 26.6.1).
Excess degree of saturation penalty (section 26.7)
Low degree of saturation penalty
Pedestrian gap-accepting penalty (see section 26.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.
21.2.2 Results: Flows and Signals
Link number, Arm number and Traffic Stream Number
In the Final Prediction Table normal (traffic) links are indicated by N, bus links by B, tram
links by T and imported pedestrian links by P in the Link ID column. Similarly, the Traffic
Stream column is also used to indicate which traffic types use each traffic stream.
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 Final Prediction Table>Traffic Stream (or Link) Results. 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, in the event that the traffic stream (or link) is
over-saturated, this results in less traffic leaving than arriving, as TRANSYT will not allow more
traffic to leave than it is physically possible to do so.
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 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 14.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.

Page 376
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)
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.
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.
21.2.3 Results: Stops and Delays
All results, other than those indicated, exclude walk-on-red pedestrian crossings.
Mean cruise time per PCU (or Veh) (seconds) including walk-on-red 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 PCU (or Veh) (seconds) including walk-on-red 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

Page 378
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 under Network
Options has been enabled.
Mean delay per PCU (or Veh) (seconds)
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)
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)
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)
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 Network
Options).
Unweighted Cost of delay (/hour) including walk-on-red 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 walk-on-red 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/PCU (per cent)
This is the average percentage of stops per PCU entering the traffic stream (or link), i.e. 100
means that, on average, each PCU stops fully once. The estimate takes account of both uniform
and random stops and allows for fractional (partial) stops as described in section 25.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.

Page 380
Weighted Cost of stops ( per hour)
The total number of stops per hour is first obtained as the product of mean stops/PCU 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).
21.2.4 Results: Queues and Blocking
All results are relevant to all links, including walk-on-red pedestrian crossings.
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 the user, or if using multiple time segments, the calculated
initial queue at the start of the displayed time segment period.
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 a user-defined
value 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 the user is 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)

Page 382
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.
Excess Queue Penalty ( per hour)
This the calculated cost on the traffic stream (or link) associated with excess queue.
Max 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
Max 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.
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.
21.2.5 Results: Fuel consumption
As described in section 25.10, 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)
21.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 21.3.3). Results are shown for all links and
traffic streams.
21.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.
Degree of Saturation Penalty ( per hour)
This is the penalty cost added to the PI as a result of the degree of saturation being outwith
the boundary limits set by the user.
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 always be zero.
Intergreen Broken Penalty ( per hour)
This is an internally used penalty (i.e. not reported in final PI). This value, in normal
operational circumstances, will always be zero.
Ped Gap Accepting Penalty ( per hour) shown for pedestrian walk-on-red links only
This is the penalty cost added to the PI as a result of the level of pedestrian gap accepting
set by the user being exceeded.

Page 384
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 Penalties (/hour)
This is a summation of all the penalty costs associated with Excess Queue Limits and DoS
limits, which are added to the PI calculation.
Unweighted Performance Index (/hour)
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)
This output is repeated in the Summary results See section 21.2.1
21.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.
Stage Index
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.
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.

TRANSYT Stage Start
This is the time of the start of the TRANSYT stage, i.e. it assumes the stage includes the
preceding interstage, unlike the more common definition of a stage. This corresponds with results
reported in TRANSYT 12 or earlier.
TRANSYT Preceding Interstage
This is interstage associated with the green time that together makes up the TRANSYT stage.
TRANSYT Stage Minimum
The TRANSYT stage minimum acts as a constraint on the optimiser. It includes the preceding
interstage and the minimum green time for that stage.
21.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 user-
specified 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 21-1. TRANSYT
adds the displacement of start of effective green (see Figure 3-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 user-specified intergreens

Page 386
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 21-1 Lag between change demand and start of green signal
21.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 following results are presented:
Number of Stages
Stage n
TRANSYT Stage start times (including preceding interstage).
21.2.11 TRANSYT 12 tables: Link Green Times
This set of results are part of the TRANSYT 12 tables output.
For each phase on each link, the following is presented:
Traffic Node
This is the ID of the intersection (node) at the link exit as specified in Link n>Traffic Node, or the
Arm exit as specified in Arm n>Traffic Node. This is the node which traffic from this link feeds
through. Strictly speaking it is no longer required by the TRANSYT model, but has value in

allowing links or lanes to be associated with one another as part of a particular junction, allowing
the associated items to be easily manipulated within the network diagram. Most importantly, it
also allows results to be aggregated for a traffic node, by defining the traffic node as part of a
TRANSYT collection.
The Start (time); End (time) and Duration of up to four green periods (in seconds) shown to
the traffic stream (or link) is presented. The times are the actual green times: to obtain effective
green times, add the displacements specified in Main (common) Data
21.2.12 TRANSYT 12 tables: Traffic Stream Green Times
The green period information as presented for each link, is also presented for each phase of each
controller stream. The arm, traffic stream and traffic node to which each phase is associated with
is also listed.
21.3 TRANSYT network-wide results

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.
21.3.1 Summary report section:
The following network-wide results are part of the Report Summary AND part of the Report
Output:
Network within capacity (Yes/No)
Either YES or Blank. YES indicates that no links 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 Links/traffic streams (%)
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.

Page 388
Number of Oversaturated Links/traffic streams
An indication of how much of the network is oversaturated. A value of 0 equates to the network
being within capacity.
Link or traffic stream with highest DoS
This is simply the link or traffic stream ID with the highest DoS within the complete network.
Link or traffic stream with worst overall PRC
This is simply the link or traffic stream ID with the lowest practical reserve capacity (PRC) within
the complete network.
21.3.2 Output report section:
The following network-wide results are part of the Report Output:
(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.
21.3.3 Final Prediction Table output:
The Network Totals Table consists of up to four rows of results as follows:
1st line: TOTAL For all traffic streams, links and pedestrian crossings.
2nd line: BUSES For bus traffic streams and links only.
3rd line: TRAMS For tram traffic streams and links only.
4th line: PEDESTRIAN For pedestrian crossings only.
5th line: OTHER (NORMAL) For Normal traffic streams and links only.
Certain lines only appear when these traffic types exist within the network
Extra lines... For each user-defined 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 period in Main (Common) Data, 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.
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 LoS
This result is only available if the LoS option under TRANSYT Network/Network 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 390
21.3.4 Path Segment results:
When traffic streams are used in a network, they generate an underlying network structure far
more complex than the user ever sees. This structure is made up of path segments most of
which are similar to links. Some of these form a chain that carries traffic flows from one specific
location to another. None of the path segment data is editable simply a consequence of
using traffic streams - 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.

22 X-Y Graph Analyser

Click this button on the vertical toolbar to show the Graph analyser.
The Graph 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. 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.
It is not possible to embed 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.
22.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.
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 both inputs and output, 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.

Page 392
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.
The Analyser screen never stores any changes permanently unless you specifically
request this by using, for example, the Use Optimised Values button.
22.1.2 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 graphs 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, which
in this case is 30-500. 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:

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

Page 394
NOTE: 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.
Right-click on the graph to access a menu for copying the graph to the clipboard.
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 (red line) while that attributed to stops
(green) and cruise time (blue) 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.)
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.

Page 396
22.1.3 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. If 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. 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. Sometimes, however, larger effects are noticeable, which 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 full set of results and link timings 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.
22.1.4 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.

After using adding collections and assigning colours, the graph now shows the highest DoS for
each 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.

Page 398
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 399
23 Additional Tools and Features
23.1 Audit Trail

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). Deterioration
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 23.1.1. How to record
File status/comments is explained in section 23.1.2.
23.1.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.

Page 400
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.
23.1.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 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.
23.1.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.
23.1.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.
23.2 Adding a Junction (Merging Networks)

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.

Page 402
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.
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.

23.3 Drive-on-the-left/Drive-on-the-right
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.
23.4 Find Shortest/Best Route

(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.

Page 404

Traffic Behaviour Models (PDM/CTM) Page 405
24 Traffic Behaviour Models (PDM/CTM/CPDM)

For modelling of traffic behaviour within the network, you have three choices You can use either
- the platoon dispersion model (PDM), the cell- transmission model (CTM), and additionally for
flared approaches you can set TRANSYT to use a Flare model. This last option 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.
The model previous known in TRANSYT 14 as Quick PDM no longer exists in

TRANSYT because the computational speed benefits are now incorporated into
the standard PDM model. Any imported files that were using it will now use the
standard PDM model.
The following sections give details of the three options.
24.1 Platoon dispersion model (PDM)

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.
TRANSYTs 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.
24.1.1 Cyclic flow profiles
An example cyclic flow profile is Figure 24-1. Such profiles are useful in validating the model;
after running any file, you can see the cyclic flow profile for any link via the Graphs button on the
main vertical toolbar.
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

Page 406
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 24-1 A traffic flow histogram
24.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 24-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
(c) GO PROFILE
Figure 24-2 Definition of IN, OUT and GO flow profiles

Page 408
The traffic flowing into a link is obtained by taking the appropriate fraction of the OUT-profiles
from the upstream links. 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 can be modified for individual traffic streams
(or links) (see section 24.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 24-3
illustrates the smoothing (dispersion) process.
The user specifies in the Main (Common) Data screen (Outline: Network Options>Traffic
Options) whether they wish to use cruise times or cruise speeds. The data which is then
specified in the Links Data screen (Outline: Links>Link n>Sources>Source n) must be
consistent with this.
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 24-3 Example of measured and predicted dispersion on a link
24.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 24-4 by the trajectory in time and distance of vehicle 1.

Page 410
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 24-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.
24.1.4 The platoon dispersal coefficient
The platoon dispersal coefficient is a number, K, which modifies the platoon dispersion factor F
as follows:

1
F=
Kt
1+
100
where t = 0.8 times the average cruise time in steps.
A negative value of K gives zero dispersion, but K = 0 gives the default value.
Default: K = 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 in error.
For details of how TRANSYT deals with dispersion associated with different source types, e.g.
buses and trams see section 25.7.
24.2 Cell Transmission Model

The 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 has been implemented in TRANSYT since Version 13 as an
alternative traffic flow model to the PDM.
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 the provision to set
different cell saturation flow values to the stop line saturation flow will often be sufficient and in
many situations the two values will be similar. For more help deciding what cell saturation flows
to use see section 18.3.

Page 412
24.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 24-5 Spatial representation of traffic on the road in the CTM

24.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.
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 in item (3) in the above list to the network mean that some of the network
modelling techniques in TRANSYT cannot be used for the CTM. In the existing TRANSYT, there
are some special network coding techniques for handling special practical situations, such as
opposed turn bays, flared links, staggered junctions, and so on. These coding methods may
generate what may be referred to as non-standard network components. One example is that
link n is upstream of link m but both links n and m are controlled by the same signals node.
When the CTM is selected, TRANSYT will perform a check on the network; any non-standard
network components will be reported and it is 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.
24.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 -

Page 414
CPDM. How to model flares (short bays) is fully described in chapter 16 - Working with flared
approaches
24.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 original 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 24-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 24-6 Give-way capacity relationship

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 by the user. 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-entered maximum congested give-way capacity will be
ignored and the minimum uncongested give-way capacity taken as the maximum congested
give-way capacity instead.
24.3 Congested Platoon Dispersion Model

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. It 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 3.12 and chapter 16.
24.4 PDM versus CTM

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:

Page 416
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 18.
24.5 Differences between the Flare models (CPDM and CTM)

These two models differ in the same way as PDM and CTM differ (see section 24.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.
24.6 Restrictions on use of the CTM

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

24.6.2 TRANSYT 15 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 to the user.
4) Time segment analysis with time-varying entry link flows is now supported by the CTM

Page 418

TRANSYT Model Features in Detail Page 419
25 Traffic Model Features in Detail

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.
25.1 Signal settings

Full details are given in section 3.6
25.2 Queues and Delays

25.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 3.7. The queue and delay model used in TRANSYT consists of
three components.
25.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.
25.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.
25.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 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 25-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.

Page 420
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 25-1 Traffic delay on a link
25.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:

4f
1/ 2

Random oversaturation f F f F pcu hours / hour
2 T
4

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 25-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.
25.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.
25.3 Stops
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.

Page 422
25.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 25-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 25-2 Valuation of full and fractional stops

from various cruise speeds
As discussed in section 25.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 PCUs stop each time the signals become red, then the average number of stops per PCU
can be estimated by dividing the average start-of-red queue by the average number of PCUs
which discharge from the link during each green. This quotient is the average number of red
periods which each PCU must wait before crossing the stop line and thus equals the average
number of random-plus-oversaturation stops per PCU.

On links where traffic arrivals exceed or are near to capacity, long queues will form and the
average number of stops per PCU 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 PCU 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 PCU 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 (PCU/hour) and the discounted average stops per
PCU.
25.3.2 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.
25.4 Wasted green time

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 TRANSYTs 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.

Page 424
25.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 26.6.2). If the optional
maximum queue storage is provided by the user it is used, otherwise a TRANSYT estimate of
this value (previously known as Link Capacity) is used instead. The accuracy of the wasted
green times will be improved wherever the user-defined value is present.
25.5 Fundamentals of the Give-way Models

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 TRLs 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 PICADYs 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 17.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 17.16 on Indirect traffic
control.

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 25-3 Give-way capacity relationships for a typical junction
Figure 25-3 shows two examples of typical linear relationships between major (controlling) and
minor (give-way) traffic flows. Figure 25-4 gives the most basic TRANSYT representation of a
T-junction that is controlled by a priority rule. The junction is represented as a either 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 24.2.4 for full details.
25.5.1 Parameters controlling the give-way model
Give-way traffic streams (or links) are specified in the same general way as signal-controlled links
within TRANSYT, but with the addition of those parameters which determine their GO-profile.

Page 426
'Bottleneck' for major-road links.
Signalled Signalled
node node
'Give-way' links for minor-road traffic,

controlled by major-road flow emerging
from the 'bottleneck'.
Figure 25-4 Basic representation of a give-way junction in TRANSYT
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 links; e.g. a lane of right turners across
a two way road,
(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 17.6.

When a give-way is controlled by more than one controlling link, these links can be either
signalised or unsignalised - The TRANSYT model allows mixed types of opposing links as well as
allowing many more conflicts to be defined.
25.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 25-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 25-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

Page 428
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 25-3. The user 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.
25.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 18.2.
25.6 Shared link stop lines

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 25.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. The user of the
program 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.
25.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 25-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 25-5 Specifying a Link as a minor shared link
25.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.

Page 430
25.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.
25.7 Bus and Tram Links

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 25-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. 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 25-6, the green period is offset to reduce the delay to the bus even though
the platoon of other traffic then suffers some delay.
25.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 the shared stop
line facility, together with a special bus dispersion formula. This is used for both link and traffic
stream/lane network representations the difference being that the underlying structure is largely
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
dispersion coefficient is given by:
1
F
1 0.7b 0.15t
where t = mean cruise time (measured in steps)
b= mean stationary time at a bus stop (steps)

Time
Bus
Distance
SIGNAL 1
Green Red
One-way Bus stop

progression
SIGNAL 2
Red Green
Bus
A platoon
of traffic
Figure 25-6 A time-distance diagram showing the different typical movements of a

platoon of traffic and a bus
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 26.1.3) or
special traffic stream weighting factors which are applied to either all traffic or to individual OD
Paths on each traffic stream (see section 26.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

Page 432
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.
25.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.
25.7.3 Bus/Tram model coefficients
Although initially the same by default, 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). These coefficients are as follows:
Dispersion coefficient1 (which is the dispersion factor parameters for stops)
Dispersion coefficient2 (which is the dispersion factor parameters for running time)
Acceleration (ms-2) (which is the assumed acceleration of the vehicle moving off from
rest)
Travel time coefficient1 (which is the dispersion factor parameters for stops)
Travel time coefficient2 (which is the dispersion factor parameters for running time)
Although individual traffic streams and links can use their own individual
dispersion settings, these are only available for Normal traffic. Only network-
wide settings are available for buses and trams.
To specify zero dispersion for buses or trams, the two user-definable dispersion coefficients
should be set to zero (Outline: Network Options > Traffic Options > Bus Parameters or >
Tram Parameters).
Full details of the equations used are given in TRL Laboratory Report LR666.
25.7.4 Specifying bus parameters
While shared stop lines 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
25-7)

Figure 25-7 Traffic Types
There are currently three traffic types Normal, 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 25.7.4.2 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 25.7.4.1 and 25.7.4.3.
25.7.4.1 Specifying bus parameters 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)
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.

Page 434
Figure 25-8 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.
25.7.4.2 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 25-9). 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 25-9 Link Traffic Type By Source
If the sources of a link are of different types, then the GUI will show a warning to check
that the user is aware of this mixed traffic.
25.7.4.3 Specifying bus parameters 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 25-10 Traffic Stream Source Data

Page 436
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, resultant traffic flows for each traffic type is 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 normal, bus and tram traffic flows.
The separate modelling of buses that stop and those that dont 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 dont 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.

25.9 Collections and Routes

TRANSYT allows the specification of Collections. A collection is simply a defined subset of the
links or controller streams within a network, so can also be regarded and used as a tagging
system that allows user-defined disaggregation of 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.
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):
If using this method, various options have provided to make it easy to select all the traffic
streams or links associated with a particular controller stream or the controller stream
associated with a particular link.
2. Using a combination of multiple-selection (e.g. via the network diagram) and the menu
item Tools>Collections>Store New Collection from currently selected Items
3. The menu item Tools>Collections>Calculate all routes in network, which will replace all
existing routes. The term route is used here as the collections generated are in fact
routes through the network. For example, collections that are also routes are a good way
to store Time Distance Diagrams.

Page 438
Collections have the following benefits:
1. Allow specific parts of a network to be individually identified.
2. Allow specific parts of a network to be categorised.
3. Groups of traffic streams or links can be identified graphically within the network diagram
or filtered using the data grids.
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. The TRANSYT output calculates, for each collection, the same metrics as calculated for
the whole network, such as distance travelled, time spent, mean journey speed.
6. To provide aggregated results for each individual traffic node, controller stream, or
junction.
As many collections as required can be specified and a name assigned to each collection. 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 Include In Report option can be used to present the collections results in the Collections
section of the TRANSYT Report (see below).
The collections do not have to make any logical sense as they can be any
combination of resultant links and controller streams, e.g. links and traffic streams
do not have to be contiguous, i.e. they dont have to be routes.
Items can also appear in more than one route and can also appear in a route more
than once.
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 23.4.
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.
25.10 Fuel consumption estimates

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 Fuel3
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
25-13 shows these relationships for the average UK car (as of March 2010). Details of the
revised fuel consumption equations and coefficients are in section 25.10.1
25.10.1 Fuel consumption parameters
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 parameters 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 parameters defined for each vehicle category.
3
WebTag is the Transport Analysis Guidance Website, provided by the UKs Department for Transport (2010) to provide
detailed guidance on the appraisal of transport projects and wider advice on scoping and carrying out transport studies.

Page 440
TRANSYT, not only provides parameters for each of the vehicle categories (Outline: Network
Options > Fuel consumptions) for the base year (currently 2010), but also includes the
parameters for future years too. To use the internally stored parameters the Generate
Extrapolated Fuel Parameters button on the Common Data Screen must be used. Having
pressed the button, the year for which you wish the fuel parameters for, is requested. A new set
of Fuel Parameters will be added to the data file marked as having been Extracted (read-only),
with the Year set as the ID, and a Description (read-only) describing what base data the
extrapolation process made use of, and the WebTag publication of that data e.g. Base Year
2010, (WebTag, October 2013).
Figure 25-11 Fuel Parameters
New files automatically start off with using the extrapolated fuel parameters for 2010. This set
of parameters can be replaced or added to, i.e. you can store more than one set of parameters
in the one file. The Use Fuel Parameter (Outline: Network Options > Fuel Consumption)
references the ID of the parameter set that will be used by TRANSYT to produce the results (see
Figure 25-12). Reference to a non-existent set of parameters 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 parameters can be entered directly (rather than extrapolated from the specified
year), therefore allowing updated or alternative values to be used if necessary. To use your own
values, simply add a new set of parameters via the Data Outline. The Extrapolated option will
be de-selected and read-only.
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 25-12). Again, TRANSYT
provides default vehicle composition appropriate for the UK, but this can be easily replaced if
necessary.
25.10.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.
25.10.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 25-12). 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:
2
L = E.V
Where: L = consumption, expressed in litres per stop
Figure 25-12 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 442
Average Car Consumption (litre/100 miles)
cruise speed (litre / 100 miles)

Fuel consumption at constant
Link cruise speed, V (km/h)
Figure 25-13 UK Fuel consumption relationships
Users outside of the UK, or with specific knowledge relating to their particular locality can modify
the parameters in the formulae as they wish. However, pleased note that the simple traffic
behaviour assumed in TRANSYT sets limits on the accuracy of prediction that can be achieved.
25.11 (Flow) Assignment Model

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
TRANSYTs 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 444

TRANSYT Optimisation in detail Page 445
26 Optimisation in detail
As explained in section 3.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 3-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 TRANSYTs 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
26.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 by setting the modelling option Exclude from Results Calculation
(Outline: Links > Link n > Modelling or Outline: Traffic Stream > Traffic Stream n > Modelling or
Outline: Pedestrian Crossings > 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).
26.1 The performance index

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 pedestrian crossing sides in a network. It represents the cost of traffic congestion, where
traffic is not limited to vehicular traffic. The Performance Index (PI) is defined as follows:
Nv Np
PI = (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

Page 446
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 overall average P.I. value is the one
to use.
26.1.1 Choosing the monetary value of vehicular stops and delay
TRANSYT evaluates the P.I. in monetary terms ( sterling - by default) and the user is 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 26-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 users to update their own values using the UK Governments
web-based Transport Analysis Guidance known as WebTag. As a consequence of the revised
method users will notice how little the cost of stops has become in relation to delay. This
reflects the far larger increases in the cost of peoples 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 the user 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 signal optimiser is likely to be affected by the relative values chosen for W v
and K (Robertson et al, 1980, also describes how Wv and K may be chosen to minimise the overall
fuel consumption).
26.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 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.

Page 448
Please note that there are also facilities 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.
26.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 26.1.3.1.
The link stop weighting is a number representing the percentage of the stop valuation used when
calculating a links contribution to the Performance Index The stop valuation is set in 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 links 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 the user 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 15.
26.1.3.1 Specifying traffic stream weightings
Figure 26-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.
Figure 26-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, 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 26-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

Page 450
particular vehicle types using a particular traffic stream or those using a particular path on a
particular traffic stream.
26.2 Network Optimisation selection

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 26-5 Network Optimisation Options

26.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 the user 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 > Optimisation Order for inclusion in the optimisation
process. The user specifies 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.

26.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)
Extended Offsets and green splits
Custom.
Of course, optimisation can also be switched off entirely, for when you simply wish to evaluate
an existing set of timings by switching off Enable Optimisation.
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.
Extended - Offsets And Green Splits is provided specifically for use when using out links to
micro-simulation models (e.g. Aimsun, VISSIM). This option can however be used for any
situation. Runs take longer than usual, but may be slightly better as a result of using it. More
details available in section 26.5.2.
Custom allows advanced optimisation parameters to be set see section 26.5.2.
26.3 Controller-specific Optimisation Levels

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.

Page 452
Figure 26-6 Controller Optimisation Options
26.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.
26.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 streams green times are locked to an invalid set of timings, e.g. broken
intergreens, TRANSYT will fail to run.

26.4 Locking of stages between different controllers

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.
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. Stage constraints are specified from within the controllers optimisation data
(Outline: Controller Streams > Controller Stream n > Optimisation) by selecting Enable Stage
Constraint.
Figure 26-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

Page 454
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
wont satisfy the constraint that you have just set. If the optimisers 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 TRANSYTs 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 optimisers
ability to find a good solution.
Stage constraints are not taken account of by the phase optimiser.
26.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, i
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 26-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 26-9 using the network diagrams Traffic (Queues and Occupancy) overlay.

Figure 26-8 Displaced Pedestrian Facility with stage constraint
Figure 26-9 Traffic overlay showing coordination of signal timings

Page 456
26.5 Optimisation Type (and other Advanced Settings)

TRANSYT offers a choice of optimisation processes Hill-climb, Shotgun Hillclimb, Simulated
Annealing (Outline: Network Options > Optimisation Options > Advanced).
Figure 26-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. The actual speed
and performance of shotgun hill-climb and Simulated Annealing is 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 optimisers in terms of speed and performance for a
particular network file.
The following sections describe each of the processes in turn.
26.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 the user or generated using either the auto-redistribute
calculation.
Any set of timings that do not violate any of the constraints, such as 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.
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).
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 26.5.2 if you wish to know more about these.

26.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 26-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:

Page 458
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 26-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 involving multiple runs, such as the plotting of the Cycle Time
Graph, or running a particularly large network.
26.5.2.1 Accuracy parameters

On traffic streams (and links) that are remote from the controller being optimised, the
recalculation of stops and delas 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 the user 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%

26.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. The user selects 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 26-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 26.5.1 on the
Hillclimb Optimisation Process.
26.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 minimum green requirements and are capable of handling the traffic are
suitable.

Page 460
Figure 26-13 Simulated annealing optimisation
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 the
user 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.
26.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.
26.6 Queue-length reductions 4
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
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 19.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, the user is recommended to 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 26.5.1.

modelled when using the traditional platoon dispersion model in TRANSYT which assumes that all
vehicles queue at the stop line. (See section 24.2 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 Stream 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) for
links 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 the link. 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
the user as Excess Queue Penalty, and are added to the Performance Index.
26.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.
The user 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 accommodates only a small number of vehicles, as variation from cycle to cycle is then
relatively more extreme.
26.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 the user is 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.

Page 462
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).
TRANSYT automatically uses this user-defined value if it exists, instead of the

internally estimated one.
26.7 Degree of Saturation limits

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 26-14 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.

26.8 Pedestrian gap-accepting penalty

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 a user-defined limit. 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 14.5.
26.9 Controller Stream Grouping

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
26-15 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 26-15 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.

Page 464
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.
26.10 Cycle time selection

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 26.11) provides information for a wide range of cycle times; it shows a graph of the
Performance Index 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 25.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.

26.11 Cycle Time Optimiser

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
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:
Dont 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.
The Cycle Time Optimiser is opened by clicking the CYOP button located on the vertical toolbar.
The screen can be resized to whatever size you wish.
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, and graph options bottom right.
The contents of the list of 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 gird below.
The cycle time source list is populated with any controller stream that has its own manual cycle
time. Any controllers that also make use of that cycle time by referring 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 466
Figure 26-16 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 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. The
graph will need to be re-run when this option is changed. 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 graph displays one or two sets of results. These sets of data are selected using the options
below the graph. A key can optionally be included on the graph using the Show key option.
The 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.
26.12 Multiple cycling and repeated greens

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.
26.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 PIs 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.
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

Page 468
running during EVERY cycle while leaving those not coming in every cycle as single-cycled. Also
an alternative method using repeated greens See section 26.12.3.
26.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 26-17 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 the user 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.
26.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 TRANSYTs stage

and phase optimisation facilities accessed via the Timings Diagram and Signals
Data screen. Alternatively TRLs isolated signal junction optimising software
OSCADY PRO can be used, which can automatically provide you with the best
stage ordering for the isolated case.
26.13 Considering the effect of small changes

TRANSYT has facilities which allow the user to assess the effects of small changes relatively easily.
This can be done for: flows, cruise times, cruise speeds, and offsets.
26.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) or to individual links (but not Traffic Streams) using the Link
Sensitivity Multiplier (Outline: Links > Link n > Flows > Advanced).
A pedestrian flow scaling factor can be applied to all pedestrian flows throughout the network
(Outline: Network Options > Traffic Options).
The 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%. Flows for
individual links can be scaled within the range 5% to 2000%.
The global vehicle flow scaling factor and the local Link Sensitivity Multiplier effects are added
together.
26.13.2 Small changes to cruise times and cruise speeds
A cruise time / cruise speed scaling factor can be applied to all traffic streams and links in the
network in Network Options > Traffic Options > Advanced or to individual traffic streams in Traffic
Steam > Modelling > Advanced. A cruise time / cruise speed scaling factor can also applied to
individual links in Links > Link n > Flows > Advanced.
The facility allows a signal plan to be tested for sensitivity to the accuracy of cruise time / cruise
speed data. Cruise times / speeds for the whole network and for individual traffic streams (or
links) can be scaled within the range 50 % to 200%.
The effect of any local cruise scaling factor and the global cruise scaling factor is combined.
26.13.3 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 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.

Page 470
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 471
27 Modelling Examples
This chapter describes an example file to assist users to familiarise themselves 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 28, Modelling Signalised Roundabouts.
The Chapter 28 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.
27.1 Supplied Data Files

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 15 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 27-1 Additional website information and advice
27.2 A small network (Example 1)

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 27.2.16. The example is designed to demonstrate several of the

Page 472
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 27-2 A small network build with lanes

(TRL1 Optimised LANES .T15)
27.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 17).
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 92 seconds.
Controller Stream 1 has three stages: (1) Phases A (western arm) and C (eastern arm), (2)
Phases B (northern arm) and E (southern arm, nearside lane only straight ahead movement)
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 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.
Controller Stream 4 has two stages: (1) Phases A (northern arm) and C (southern arm), (2) Phase
B (eastern arm)
27.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.
27.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 3.3.
There are approximately 21 arms, 23 traffic streams and a total of 27 lanes. 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 link, 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 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.

Page 474
27.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 TRANSYTs new bi-directional pedestrian
crossing object (P1) and the new walk-on-red pedestrian behaviour model. In previous TRANSYT
you would have used two separate pedestrian links to model both directions of pedestrian flow
across the road.
Although this example uses the walk-on-red model, this can be easily switched off if you do not
want to model this behaviour.
27.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.
27.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.
27.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.
27.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, 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. This reduces the unrealistic paths to just one from location 4 to 5 travelling around the
whole network, rather than simply turning left. Therefore, this path has been disabled. The right
turn movement out of the side road has also been disabled as, in reality it does not exist and by
disabling it any traffic accidently put onto it will show up in the resultant flows tab.
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 can be more
appropriate in some circumstances 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.
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.
27.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 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.
27.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.
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.
27.2.11 Delay and stop valuation
Specific traffic stream weightings (on stops and delay) are used on certain links (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.

Page 476
27.2.12 Cycle selection
The information to aid cycle selection from the Cycle Time Optimiser shows that a cycle time in
excess of 82 seconds is needed to prevent any node being more than 90 per cent saturated. The
best overall performance is achieved around the 96 second mark, but with a fairly similar
performance over an extensive range either side of this value. As the cycle time is reduced below
84 seconds the performance rapidly deteriorates.
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.
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.
N.B. to run the Cycle Time Optimiser, the optimisation option Auto-Redistribute must be
enabled.
27.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. 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 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.
27.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 a user-defined Collection has been specified (a sub-set of links or traffic streams)
has been defined. Results are shown for these below the Final Prediction Table results for the
network as whole.
27.2.15 Graph plots
A number of graph plots of cyclic flow patterns (as described in section 19.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 occasionally 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

Page 478
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 link 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.
27.2.16 Link equivalent of the same small network
Figure 27-3 A small network built with links

(TRL1 optimised LINKS.T14)
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 3.4.
There are 27 links. Generally, the links are numbered for convenience so that the first digits
correspond to the node 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 3.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.
27.2.17 Equivalent small network with Wide-Area Assignment
Figure 27-4 A small network with wide-area assignment

(TRL1 optimised LANES with ASSIGNMENT.T14)
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. 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 just one local matrix
covering more-or-less the complete network or one per junction. It all depends on what flow

Page 480
data you have and how you wish to assign traffic to the network. Of course, the use of a wide-
area matrix is also purely 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.
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.

28 Modelling Signalised Roundabouts

28.1 About this chapter
This chapter incorporates all of the advice previously given in RR274 (Lines and
Crabtree, 1990) and further updated in AG48 (Binning et al, 2003), AG63 (Binning et
al, 2008) and AG65 (Binning et al, 2011). 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.
One significant change that makes life much easier in building a model is the direct
representation of lanes since the release of TRANSYT 14. It is still necessary to decide
how to model lanes in terms of streams, which is a similar concept to deciding which
lanes to model with a link.
This chapter discusses in detail the factors to be considered in modelling signalised

roundabouts using TRANSYT. These factors include the network models structure,
estimation of saturation flows, and the use of traffic stream weighting and queue
penalties to avoid blocking back and locking up of the roundabout. Three 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.
To maintain backward compatibility with previous versions of TRANSYT which use a link
structure, an example of this is retained here. This allows users of TRANSYT 15 to
understand the way in which previous models have been built.
28.2 Introduction
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. Several authors have shown that the performance of three arm
roundabouts could be improved by traffic signals (Davies 1980, Flanagan 1983).
Other authors have studied junctions in London (Huddart 1983, Wright 1984) and
Sheffield (Bull 1983) with success. The Sheffield study used TRANSYT to provide
initial signal timings for a six arm junction. Hallworth (1992) examined the factors
that affect the capacity of signalised roundabouts using an example from Bradford (a
three-arm roundabout) and another from Bristol (a four arm roundabout). Following
on from Hallworths article, Jones (1992) examined the techniques used in the design
of signalised roundabouts and strategies for their control.
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

Page 482
TRANSYT such as traffic stream (or link) weighting, the shared link facility, 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 either of the models that are capable of modelling blocking
back situations (CTM or CPDM) 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.
28.3 The TRANSYT program

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 link.
TRANSYT effectively queues vehicles in a vertical heap on the stop line, and this
simplification of the model has implications in situations where links are short and
flows are high - as can occur at signalised roundabouts. This effect is discussed in
more detail in section 28.4.7. The alternative models, CTM and CPDM, are likely to be
useful when modelling a roundabout. The former is suitable for the longer links (over
30 metres) where blocking back needs to be avoided and the latter for short links
(under 30 metres), which can be used to model flares and possibly some of the
shorter circulating sections. CTM and its uses are discussed elsewhere in this manual
(see section 24.2).
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
which can be used if there are any unsignalled entries to the roundabout.
28.4 Modelling a roundabout (Example 2)

The principles involved in modelling a roundabout are discussed below and illustrated
by using a simple, hypothetical, four-arm roundabout (Example 3) shown in Figure
28-1. Further examples based on real-life sites are described in section 28.6 and
section 28.7.
The units used throughout the report are passenger car units (PCU) or
vehicles. The units selected should be set to reflect the data provided.
Switching units does not convert the data. Saturation flows are always
specified in PCU.

Figure 28-1 Site diagram of a four-arm roundabout
28.4.1 Cycle time
In networks which contain some short links (such as roundabouts), severe problems
can arise if traffic queues fill these 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 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 PI versus cycle time can be used to identify the best predicted cycle time by
making full runs on a range of cycle time. 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.
28.4.2 Traffic stream structure
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.

Page 484
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 28-1 (node 2). In this case, only one lane has been marked with a
left turn arrow because further 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.
At nodes 1 and 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.
28.4.3 Modelling using links
[Skip to section 28.4.4 if you are not interested in using a network link structure.]
Prior to TRANSYT 14, the network structure consisted of links. A link-share (i.e. a
major link and set of associated minor links) is directly equivalent to a traffic stream.
Because there will be many existing TRANSYT network models, TRANSYT 15 retains
the ability to use links. When modelling roundabouts, there are some well-established
methods for using links. In order to contrast the use of links and traffic streams, both
are presented in the following two Figures (Figure 28-2 and Figure 28-4)
The link diagram in Figure 28-2 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 28-2 Link diagram for a four-arm roundabout
The use of shared links can improve the modelling of the junction significantly when
using the tradition 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 25.6 for a detailed description
of shared links.
TRANSYT models traffic flows in a series of time intervals or steps, and the number
of steps per second is chosen by the user, but would normally be 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.

Page 486
Figure 28-1, Figure 28-2 and Figure 28-3 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 (f 43), 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 28-3
(a). Of the two platoons only the proportion which entered at node 1 and continuing
to node 4 (f14) 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
(f43) are modelled as a minor shared link, then the fixed proportional reduction for
circulating traffic can be applied to the newly entered traffic only (f13 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 28-3. 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.
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 28.6.

Figure 28-3 Use of shared links to model flows
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.

Page 488
28.4.4 Modelling using traffic streams
From (Figure 28-4) 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 the user.
The model using links above (Figure 28-2) 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-4. 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 28-5). 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 28-4 Traffic stream diagram for four-arm roundabout

Figure 28-5 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.
28.4.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 16 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 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 28-4). The blocking

Page 490
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.
28.4.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.
28.4.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.
28.4.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.
28.4.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 28.4.6.2.
28.4.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 28.4.1. The use of
the limit-queue facility and the effect of increased demand are discussed below.

Page 492
28.4.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, of course,
can be used to more accurately model the situation as it stands. By modelling the
blocking it will then be possible to minimise that blocking through optimisation of the
timings.
28.4.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 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 26.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.
28.4.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 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 PI. 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

Page 494
the optimisation runs, simply switch off optimisation, de-select the Auto Distribute,
and re run: this will run the file with the timings from the last run. Check the results
to see that oversaturation is stored on the entries rather than circulating traffic
streams.
28.4.7.4 Blocked Traffic Streams/Links

When optimising the signal timings and, in particular, the node 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 28.7.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.
However, for most signalised roundabouts, the use of CTM should ensure that the
signal timings minimise problems with unsuitable offsets.
28.5 Checking co-ordination

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 and the time-distance diagrams
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.

28.6 Example 3 a signalised motorway roundabout

The example roundabout shown in Figure 28-6 has been chosen as typical of a
motorway/trunk road site and to demonstrate the features described above. 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 28-7.
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, CTM and
Flare models in order to model the junction portrayed in the most accurate
manner.
28.6.1 Modelling the junction
28.6.1.1 Traffic stream structure

As discussed in section 28.4.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.

Page 496
Figure 28-6 Site diagram of a signalised motorway roundabout

Figure 28-7 network diagram for a signalised motorway roundabout
28.6.1.2 Flows
The Origin/Destination flow matrix is given in Table 28-1. This shows the flow from
each entry to each exit during the period under consideration.

Page 498
Table 28-1 Origin-destination matrix for signalised roundabout
To Node
1 2 3 4 5 6 Total
1 - 220 100 46 124 166 656
2 38 - 132 149 197 146 662
From 3 231 197 - 132 134 148 842

Node
4 26 95 75 - 267 108 571
5 132 153 135 35 - 125 580
6 134 165 166 106 26 - 597
Total 561 830 608 468 748 693
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.
28.6.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 performance index they exist to allow
the OD table facility to be used, and to illustrate the exit arms only.
28.6.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.
28.6.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 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.
28.6.2 The TRANSYT output
28.6.2.1 Normal flows

Example file TRL3 - motorway roundabout.T14 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 61% to 71%. 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 54% for 10/1, 55% for Traffic Stream 1/2, 44% for
62/1 and 26% 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 links, possibly during on-site commissioning and validation.
28.6.2.2 Excess demand flows

Example file TRL3 - motorway roundabout 110 percent flows.t14 gives the TRANSYT
output with the optimised signal timings from TRL3 - motorway roundabout.T14 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 Max 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.

Page 500
28.6.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.
28.6.3.1 Network Diagram output

The following figures are generated using TRANSYTs 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 link and node diagram,
various input data and output results can be superimposed onto it.
Figure 28-8 Network diagram showing Mean Max Queues

The network diagram can provide a detailed diagram of the network a lot of
information for each arm and node is shown, such as flow, degree of saturation, etc.
Figure 28-8 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 28-9 Links on green/red

Figure 28-9 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 links 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).

Page 502
Figure 28-10 Value Comparison Tool

Figure 28-10 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 diagrams 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.
28.6.4 Traffic Model considerations
The motorway roundabout example described above has been modelled using
primarily the Cell-Transmission Model (CTM). The flared approaches are modelled
explicitly, using the Flare traffic model - due to this models 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 28-7). This is more accurate than using the quick flare feature (as used
in previous versions of TRANSYT) 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 either have the restricted flow option turned off, and optionally exit
arms can be removed from the performance index calculation altogether, although
their contribution to it should be minimal with the restricted 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 restricted 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 28-11 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 dont, 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 back these can be modelled as PDM traffic streams (as is the case in
this example). The ability to mix traffic models within the same network is new to
TRANSYT 14. 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 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.

Page 504
28.7 Example 4 an urban signalised roundabout

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. 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.
28.7.1 Description of the roundabout
The roundabout is triangular in shape (see Figure 28-12) 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 28-12 Site diagram of the Walton Street roundabout, Aylesbury

28.7.2 Modelling the junction
The diagram in Figure 28-13 and the TRANSYT input data (see TRANSYT file TRL4 -
Walton Street - AM peak.t14) show how the roundabout has been modelled. A Local
OD Matrix has been used to input the flows. 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 O-D 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 28-13 Link diagram for the Walton Street roundabout
28.7.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

Page 506
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).
28.7.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 26.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 en 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
28.7.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 28.4.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.
28.7.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 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.
28.7.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.t14. Studying the degree-of-saturation on each
traffic stream shows that the aim of giving spare green to circulating traffic streams
has been achieved. If any internal traffic streams had been over-saturated 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.
28.7.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 20 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.
28.7.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.

Page 508
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.
28.8 Recommendations
If using only a traffic stream structure:
Only separate lanes into separate traffic streams when necessary, i.e. when
the queueing behaviour on each lane is expected to be significantly different.
Otherwise, use a single, multi-lane traffic stream.
If using only 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
option can help with this.
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, queue 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).

29 Definitions / Glossary
29.1 TRANSYT GUI Terms
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 7.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.
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 15 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.

Page 510
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 the user 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
section 7.7 for more details.
TS
An abbreviation for Traffic Stream. Occasionally used as short-hand in both
TRANSYT and the User Guide.
29.2 Modelling and Traffic Engineering Terms

Please also see section 29.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.
Actual green time

This is the time for which the signal head for traffic on a link actually shows green.
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.
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.
Bottleneck
A bottleneck is a LTS with 100% green. It is modelled as an unsignalled link with a
Restricted 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 the user
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

Page 512
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
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.
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 15. 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
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 (CYOP)

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

Page 514
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.
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
EQUISAT produces, for each node, initial green splits which equalise saturation for the
most saturated links which determine the green needed by each stage. EQUISAT has
been replaced with an Auto Redistribute option.
(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 TRANSYTs 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 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
bottlenecks are modelled as a give-way with a restricted flow (i.e. has a separate
saturation flow)
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.

Page 516
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 TRANSYTs 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.
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
TRANSYTs 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.

Page 518
(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 21.2.4.
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 the user, 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.
Network
A network is a collection of links, traffic streams, lanes and controller streams
modelled within TRANSYT.
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) 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
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 isnt. 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.

Page 520
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:
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 15 - See Pedestrian Crossing Object.
Ped Gap Accepting Penalty

This is the penalty cost ( per hour) added to the PI as a result of the level of
pedestrian gap-accepting set by the user 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 TRANSYTs 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

Page 522
models the variation in vehicle cruise speeds as they progress down the traffic
stream.
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.
(Link) Sensitivity Multiplier Link or Traffic Stream

A scaling factor applied to both the total and Uniform Flow on a traffic stream (or
link). The source flows of downstream links is increased by the same amount in order
to ensure that flows are consistent and the effect of the increase is taken account of
correctly. A value over 100% increases the flow on the link and increases the
proportion of the flow on downstream links coming from this link, where it not the
only contributor.
(Link) Sensitivity Multiplier - Cruise

A scaling factor applied to cruise times or cruise speeds on a traffic stream (or
link).
Shared stop lines

This is a facility which allows the user 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

Page 524
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.
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 TRANSYTs
Signal Phase 2.
Signal Phase 2
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 Signal Phase or Signal Phase2 is green the link is deemed to be
green.
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.
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.
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.

Page 526
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 giveway 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.
(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 the user. 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.
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.
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-compliance is predicted, as well as giving more accurate predictions of delays to
pedestrians.
Weighting factors
These factors allow the user to modify all stop and delay weightings by a fixed
percentage. In this way the user can check whether or not it would be beneficial
changing these values.

Page 528

30 References
ANON. (1968). SIGOP traffic signal optimisation program users manual. New York,
(Peat, Marwick, Livingston and Co.).
BECKMANN, M, McGUIRE C and WINSTEN C (1956). Studies in the Economics of

Transportation, CT: Yale University Press.
BULL P and G M DUNNE (1983). Traffic signal control of Park Square roundabout,
Sheffield. PTRC summer annual meeting, University of Sussex.
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 (2012). JUNCTIONS 8 User Guide. TRL Application Guide AG 67.

Crowthorne: Transport Research Laboratory. (Incorporates ARCADY and PICADY)
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 (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
FLANAGAN T B and R J SALTER (1983). Signal-controlled roundabouts. PTRS

summer annual meeting, University of Sussex.
HALLWORTH M S (1992). Signalling roundabouts 1. Circular arguments. Traffic

Engineering and Control, 33(6), June 1992, 354-363.
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.
HUDDART K (1983). Signalling of Hyde Park Corner, Elephant and Castle and other
roundabouts. PTRC summer annual meeting, University of Sussex.

Page 530
JONES S E (1992). Signalling roundabouts 2. Controlling the revolution. Traffic

Engineering and Control, 33(11), November 1992, 606-613.
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 users 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.
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. 325378.

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 532

31 Appendix A Importing files

31.1 Import TRANSYT 14 files
TRANSYT 15 can import data from TRANSYT 14 by simply 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 15, 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.
31.2 Import TRANSYT 13 files

TRANSYT 15 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 15, the network may not appear exactly as it did in TRANSYT
13.
There is no longer a T12Mode in TRANSYT 15, so TRANSYT 13 files using this

signals mode will have their signal timings converted when imported.
TRANSYT 12 files using T12mode do not contain intergreens, but use start lags
to define the interstages/intergreens instead. It is safest that TRANSYT 15

Page 534
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, users 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 15 cell saturation flow is set to the highest value
of the TRANSYT 15 default (for the cell sat flow) and the imported maximum
flow value.
Due to the extended options that TRANSYT 15 now offers you may wish to
review/examine your imported file to ensure that you making best use of
TRANSYT 15 and that you are modelling your network in the best way possible.
31.3 Import from TRANSYT 7-SET/10/11/12

TRANSYT 15 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/12and 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.
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 15 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 15 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 15 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 15. In general, TRANSYT 15 checks for more
problems than does TRANSYT 12, therefore a file that ran in TRANSYT 12 may show
errors or warnings in TRANSYT 15.
N.B. Data items that are represented differently in TRANSYT 15 will be automatically
converted on import to the new representation, e.g. -9999 (zero) delay weightings
will be converted to the equivalent 0% weightings.
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 15 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 15. If in doubt, please send your data file(s) to TRL for comment.
31.4 Import from TRANSYT-7F

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 15 checks for more and different problems than does TRANSYT-7F.
Furthermore, due to differences in the two products, TRANSYT 15 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 15.
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

Page 536
61 Route Link
70 Node Coordinates
Intersection Name Record
Link Name Record
*Excluding the actuated phase flag
Partially
1 Run Controls
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 15 will load in and position nodes and links according to this file.
TRANSYT 15 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 15, the network may not appear exactly as it did in

TRANSYT-7F. However, we believe users will benefit considerably from the

obvious visual superiority of TRANSYT 15.
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 the user 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 links 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 15 both arterials and routes are

imported as TRANSYT 15 collections.
The direction of routes (forward/back) is not specifically recorded in

TRANSYT 15 Therefore, the direction of imported reverse routes are
retained by recording the direction in the TRANSYT 15 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. Users may wish to replacer 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 15 stage due the difference in how

Page 538
TRANSYT-7F phases and TRANSYT 15 stages are defined - TRANSYT

stages include the preceding interstage.
Because the opposed right-turn model in TRANSYT 15 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.
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 15 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.
31.5 Import from Synchro

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 15.1 now imports heavy vehicle percentages as well as total

traffic movement volumes. The imported traffic data are converted
into Light and Heavy traffic types.

32 Appendix B Export to TRANSYT 14

Exporting a TRANSYT 15 file to TRANSYT 14 format is possible by selecting
File>Export>To TRANSYT 14. After generating the export file (.T14 format), you
may be shown warning and/or information associated with the conversion process
that you need to be made aware of.
TRANSYT 15 contains new data items compared to TRANSYT 14 and so clearly not all
data can be successfully exported to TRANSYT 14, e.g. priority crossroads object.
Some data items that are represented differently in TRANSYT 14 will be automatically
converted on export to the equivalent representation, e.g. traffic streams or links
using the flare traffic model will be set to use either CTM or CPDM based on their
length, so that they continue to use the same model as before.

Page 540
33 Appendix E Importing SCOOT data

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 15 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 33-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 33-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.
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.

Appendix E Importing SCOOT data Page 541
Figure 33-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 IDs 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 IDs 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.
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.

Page 542
Figure 33-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 33-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 wont 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 F Importing SCATS data Page 543
34 Appendix F Importing SCATS data

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 15 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 34-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 IDs 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 links 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 TRANSYT traffic streams.
Figure 34-2 Associating TRANSYT Links with SCATS Detectors

Page 544
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 34-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 34.1.
Figure 34-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 within the TRANSYT network before sensible
results can be produced. Zero source flows wont 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 F Importing SCATS data Page 545
34.1 Creating data files from SCATS data

This is a description of how users 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
detectors in the current version of Traffic Reporter) in Approach 1 only. The
heading for Approach 2 should be shown without any detectors 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 like this:

Page 546
35 Appendix G Calculating TxC

To switch on the calculation of the Halfstarre TxC values you need to set the
preference option Show TxC values to true.
Additionally, in a VA system (Netherlands), there may be one or more detectors on

each road link. These will be referred to as the first detector, second detector, etc.
and the last detector, numbered from upstream to downstream of the road link. To
cater for a platoon, TxC 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 and 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 via the Data Editor (see screen
capture below). N.B. this input value does not currently appear in the dedicated
traffic stream data screen.

Transyt 15 User Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Transyt 15 User Guide

Transféré par

Droits d'auteur :

Formats disponibles

TRL Limited

APPLICATION GUIDE AG70 (Issue F)

TRL Limited 2013, 2014, 2015. All rights reserved.

First Published 2013

Aimsun is a trademark of TSS-Transport Simulation Systems, S.L.

Aimsun is a product of TSS-Transport Simulation Systems, S.L.

VISSIM is a product of PTV AG

Synchro is a registered trademark of Trafficware Ltd.

WinZip is a registered trademark of WinZip International LLC.

TRANSYT 15 User Guide (Issue F)

TRANSYT is a macroscopic off-line computer program for studying everything from

A traffic model of the network calculates a Performance Index (P.I.) in monetary

TRANSYT 15 User Guide (Issue F)

TRANSYT 15 User Guide (Issue F)

TRL Software Sales:

TRL Software Sales

Telephone lines: +44 (0)1344 770758

Fax: +44 (0)1344 770356

Web site: www.trlsoftware.co.uk

Knowledge base: www.trlsoftware.co.uk/knowledgebase

Latest downloads: www.trlsoftware.co.uk/downloads

Training courses: www.trlsoftware.co.uk/training

For traffic modelling, traffic auditing and traffic consultancy services

Telephone +44 (0)1344 770758

TRANSYT 15 User Guide (Issue F)

TRANSYT 15 User Guide (Issue F)

2 Installing the Software ......................................................................... 25

3 Vehicle Modelling Basics ....................................................................... 29

4 Optimisation Basics .............................................................................. 49

5 How to use TRANSYT 15 ....................................................................... 51

6 Graphical User Interface (GUI) operation ................................................ 71

7 TRANSYT 15 Input Data ....................................................................... 97

8 Custom data-entry screens ................................................................. 105

9 Data Grids ........................................................................................ 127

10 Network Diagram .......................................................................... 137

11 Three dimensional mode (3D) ......................................................... 169

13 Working with Traffic Flows .............................................................. 183

14 Working with Pedestrians ............................................................... 215

15 Working with Traffic Signals ........................................................... 235

16 Working with Flared Approaches ..................................................... 279

17 Working with Priority Junctions ....................................................... 289

18 Working with Traffic Models ............................................................ 337

19 Working with Results ..................................................................... 341

20 Generating Reports ....................................................................... 359

21 TRANSYT 15 Outputs ..................................................................... 369

22 X-Y Graph Analyser ....................................................................... 391

23 Additional Tools and Features ......................................................... 399

24 Traffic Behaviour Models (PDM/CTM/CPDM) ...................................... 405

25 Traffic Model Features in Detail ....................................................... 419

26 Optimisation in detail ..................................................................... 445

TRANSYT 15 User Guide (Issue F)

27 Modelling Examples ....................................................................... 471

28 Modelling Signalised Roundabouts ................................................... 481

29 Definitions / Glossary..................................................................... 509

30 References ................................................................................... 529

31 Appendix A Importing files ........................................................... 533

32 Appendix B Export to TRANSYT 14 ................................................ 539

33 Appendix E Importing SCOOT data ............................................... 540

34 Appendix F Importing SCATS data ................................................ 543

TRANSYT 15 User Guide (Issue F)

1.1 About TRANSYT ........................................................................... 17

1.2 Summary of TRANSYT 15 improvements ......................................... 19

1.3 About this manual ........................................................................ 21

1.4 Training ...................................................................................... 22