TRANSYT 14 User Guide PDF

TRL
APPLICATION GUIDE 65 (Issue J)

TRANSYT 14 USER GUIDE

By James C Binning, Mark Crabtree, Graham Burtenshaw.

Copyright TRL Limited 2010, 2011. All rights reserved.

Certificate No FS 567469

Software manufactured under an ISO 9001
registered quality management system
TRL Software
Crowthorne House
Nine Mile Ride
Wokingham Berkshire
RG40 3GA United Kingdom

Tel: +44 (0)1344 770758
Fax: +44 (0)1344 770356
E-mail: software@trl.co.uk
www.trlsoftware.co.uk

TRANSYT 14 User Guide (Issue J)
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 2010
ISSN 1365-6929

SCOOT is co-owned by Peek Traffic Ltd, TRL 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).
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.

ABSTRACT OF APPLICATION GUIDE 65 2010
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 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.
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 14.1) issued by TRL. It has been updated to
include details of the changes made since TRANSYT 13; in particular the addition of
several alternative optimisation routines; the use of lanes and traffic streams (TS)
as an alternative to the traditional link structure; an enhanced conflict model
allowing conflicts associated with lanes, links, movements or traffic streams; mixing
cell transmission models (CTM) and platoon dispersion models (PDM) within the
same network; ARCADY/PICADY based models, and other extensive enhancements
to both the traffic model and the fully-interactive graphical interface.


TRANSYT 14 user guide
July 2012, Issue J (to accompany TRANSYT 14.1.2)

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

--------------------------------------------------------------------

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


CHAPTER HEADINGS
1 Introduction ........................................................................................ 17
2 Installing the Software ......................................................................... 27
3 Modelling Basics .................................................................................. 30
4 Optimisation Basics .............................................................................. 49
5 How to use TRANSYT 14 ....................................................................... 51
6 General Graphical User Interface (GUI) operation .................................... 69
7 TRANSYT 14 Input Data ....................................................................... 95
8 Other Data Entry Screens ................................................................... 105
9 Network Construction Editor (NetCon) .................................................. 133
10 Working with Analysis Sets, Demand Sets and Time Segments ........... 163
11 Working with Traffic Flows .............................................................. 169
12 Working with Traffic Signals ........................................................... 195
13 Working with Priority Junctions ....................................................... 229
14 Working with Traffic Models ............................................................ 273
15 Working with Results ..................................................................... 277
16 Generating Reports ....................................................................... 295
17 TRANSYT 14 Outputs ..................................................................... 303
18 X-Y Graph Analyser ....................................................................... 323
19 Additional Tools and Features ......................................................... 331
20 Traffic Behaviour Models (PDM/CTM/CPDM) ...................................... 337
21 Traffic Model Features in Detail ....................................................... 351
22 Optimisation in detail ..................................................................... 383
23 Modelling Examples ....................................................................... 401
24 Modelling Signalised Roundabouts ................................................... 411
25 Definitions / Glossary..................................................................... 439
26 References ................................................................................... 457

27 Appendix A Import TRANSYT 13 files ............................................ 460
28 Appendix B Export to TRANSYT 13 ................................................ 461
29 Appendix C - Importing from TRANSYT 10/11/12 .............................. 462
30 Appendix D Importing from TRANSYT-7F ....................................... 464
31 Appendix E Importing SCOOT data ............................................... 468
32 Appendix F Importing SCATS data ................................................ 471

CONTENTS
1 Introduction ........................................................................................ 17
1.1 About TRANSYT ........................................................................... 17
1.2 Summary of TRANSYT 14 improvements ......................................... 19
1.3 About this manual ........................................................................ 20
1.4 Training ...................................................................................... 21
1.5 Student Edition ............................................................................ 21
1.6 Related Software ......................................................................... 22
1.7 Product Background and Versions .................................................. 22
1.8 News-feeder, Updates and Download system .................................. 24
1.9 Acknowledgements ...................................................................... 24
2 Installing the Software ......................................................................... 27
2.1 Hardware/software requirements ................................................... 27
2.2 Installing/uninstalling the software................................................. 27
2.3 Copy-protection and software registration ....................................... 27
3 Modelling Basics .................................................................................. 30
3.1 Traffic Model Basic Assumptions .................................................. 30
3.2 Network representation ................................................................ 30
3.3 Relationship between lanes and TRANSYT links ................................ 31
3.4 Relationship between lanes and traffic streams ................................ 33
3.5 Flow, speed and link/stream/lane data ........................................... 35
3.6 Signal settings ............................................................................. 37
3.7 Traffic behaviour within a link or traffic stream ................................ 43
3.8 Delays, Queues and Stops ............................................................ 43
3.9 Maximum queues ......................................................................... 44
3.10 Give-way situations ...................................................................... 46
3.11 Shared stop lines ......................................................................... 46
3.12 Flared Approaches (and CPDM) ...................................................... 47

3.13 Flared Approaches (and Quick PDM) ............................................... 47
4 Optimisation Basics .............................................................................. 49
4.1 Network timings optimisation ........................................................ 49
4.2 Cycle Time optimisation ................................................................ 49
5 How to use TRANSYT 14 ....................................................................... 51
5.1 Essential GUI terms you need to know............................................ 51
5.2 Quick start for TRANSYT users ....................................................... 51
6 General Graphical User Interface (GUI) operation .................................... 69
6.1 General ...................................................................................... 69
6.2 Getting help ................................................................................ 69
6.3 Accessibility ................................................................................ 70
6.4 Demo (and Viewer) mode ............................................................. 70
6.5 Advanced Mode ........................................................................... 71
6.6 Speed of operation and large files .................................................. 71
6.7 Main toolbars .............................................................................. 72
6.8 Changing the Active Data Item ...................................................... 75
6.9 Padlock system ............................................................................ 76
6.10 The 'Edit in Window' System ......................................................... 78
6.11 Types of Data .............................................................................. 79
6.12 Running Files and using Auto-Run .................................................. 84
6.13 Managing files ............................................................................. 85
6.14 Undo/Redo .................................................................................. 87
6.15 Copying data to the clipboard ........................................................ 88
6.16 Printing ...................................................................................... 88
6.17 Managing Windows ...................................................................... 88
6.18 Preferences Screen ...................................................................... 91
7 TRANSYT 14 Input Data ....................................................................... 95
7.1 Data Files ................................................................................... 95

7.2 Library Files ................................................................................ 95
7.3 Data Outline ................................................................................ 96
7.4 Data Outline Screen ..................................................................... 99
7.5 Data Editor Screen ..................................................................... 100
7.6 Data Grids ................................................................................ 101
7.7 Network Construction Editor (NetCon) .......................................... 101
7.8 Task List ................................................................................... 101
7.9 Data Field Finder ....................................................................... 102
8 Other Data Entry Screens ................................................................... 105
8.1 Data Grids ................................................................................ 105
8.2 Query Builder ............................................................................ 115
8.3 Main (Common) Data Screen ....................................................... 118
8.4 Signals Data Screen ................................................................... 120
8.5 Links Data Screen ...................................................................... 127
8.6 (Traffic) Streams Data Screen ..................................................... 131
9 Network Construction Editor (NetCon) .................................................. 133
9.1 Speed of operation ..................................................................... 134
9.2 Moving around the network ......................................................... 134
9.3 Saving, using and managing Views ............................................ 135
9.4 Printing, copying and exporting ................................................... 135
9.5 Representation of Links, Lanes and Stop Lines ............................... 136
9.6 Manipulating items ..................................................................... 138
9.7 Viewing and visualising data in NetCon ......................................... 142
9.8 Other toolbar buttons ................................................................. 156
9.9 NetCon Options screen ............................................................... 157
9.10 Other NetCon Features ............................................................... 161
10 Working with Analysis Sets, Demand Sets and Time Segments ........... 163

11 Working with Traffic Flows .............................................................. 169
11.2 Flow Consistency Diagram .......................................................... 171
11.3 Flow Allocation Tool .................................................................... 174
12 Working with Traffic Signals ........................................................... 195
12.1 Introduction to traffic signals in TRANSYT 14 ................................. 195
12.2 Overview of Signal Timings ......................................................... 201
12.3 Timings Diagram ....................................................................... 210
12.4 Intergreen Matrix Screen ............................................................ 220
12.5 Stage Sequence Screen .............................................................. 225
12.6 Phase Delays ............................................................................. 227
12.7 Start/end displacements ............................................................. 228
13 Working with Priority Junctions ....................................................... 229
13.1 What is a Priority Object? ............................................................ 230
13.2 Using a Priority Object library file ................................................. 231
13.3 Applying a T-Junction Priority Object to an existing network ............ 232
13.4 Using an Arm, Traffic Stream and Lane Structure ........................... 237
13.5 Steps required using arms, traffic streams and lanes ...................... 237
13.6 Movements and Conflicts ............................................................ 240
13.7 Visibility Adjustment .................................................................. 244
13.8 Using Links to define your priority junction .................................... 244
13.9 Modelling roundabouts................................................................ 247
13.10 Using Links to define your roundabout ...................................... 251
13.11 Mutual opposition ................................................................... 253
13.12 Modelling variations of give-way ............................................... 253
13.13 Give-ways within signalled junctions ......................................... 259
13.14 Give-way simplifications you can make...................................... 269
13.15 Indirect traffic control and give-way bottlenecks ......................... 270
14 Working with Traffic Models ............................................................ 273

14.1 Traffic Model selection ................................................................ 273
14.2 Vehicle-In-Service and the Random Parameter .............................. 274
14.3 Setting Cell Saturation flows ....................................................... 276
15 Working with Results ..................................................................... 277
15.1 Summary Results Screen ............................................................ 277
15.2 Detailed results ......................................................................... 278
15.3 Animation controls ..................................................................... 280
15.4 Graphs ..................................................................................... 281
15.5 Time Distance Diagram ............................................................... 287
16 Generating Reports ....................................................................... 295
16.1 About Report Files ...................................................................... 295
16.2 Report Viewer ........................................................................... 296
16.3 Reporting Options ...................................................................... 298
16.4 Using custom grid layouts in reports ............................................ 299
16.5 File Comparison Utility ................................................................ 299
17 TRANSYT 14 Outputs ..................................................................... 303
17.1 Traffic model predictions ............................................................. 303
17.2 TRANSYT individual link or traffic stream predictions ...................... 306
17.3 TRANSYT network-wide results .................................................... 318
18 X-Y Graph Analyser ....................................................................... 323
19 Additional Tools and Features ......................................................... 331
19.1 Find Shortest/Best Route ............................................................ 331
19.2 Merging Networks ...................................................................... 331
19.3 Saturation Flow Estimation .......................................................... 333
19.4 QUEPROB - Effective Flare length calculator .................................. 335
19.5 Drive-on-the-left/Drive-on-the-right ............................................. 336
20 Traffic Behaviour Models (PDM/CTM/CPDM) ...................................... 337

20.1 Platoon dispersion model (PDM) ................................................... 337
20.2 Congested Platoon Dispersion Model (CPDM) ................................. 343
20.3 Quick Platoon dispersion model (Quick PDM) ................................. 343
20.4 Cell Transmission Model .............................................................. 344
20.5 PDM versus CTM ........................................................................ 347
20.6 CPDM versus CTM ...................................................................... 348
20.7 Restrictions on use of the CTM ..................................................... 348
21 Traffic Model Features in Detail ....................................................... 351
21.1 Signal settings ........................................................................... 351
21.2 Queues and Delays .................................................................... 351
21.3 Stops ....................................................................................... 353
21.4 Wasted green time ..................................................................... 355
21.5 Fundamentals of the Give-way Models .......................................... 356
21.6 Shared link stop lines ................................................................. 360
21.7 Flared approaches The CPDM method ........................................ 361
21.8 Flared approaches the CTM method ........................................... 366
21.9 Flared approaches - quick flares ................................................ 367
21.10 Bus and Tram Links ................................................................ 369
21.11 Pedestrian Links ..................................................................... 374
21.12 Collections and Routes ............................................................ 374
21.13 Traffic Profile Types ................................................................ 376
21.14 Fuel consumption estimates ..................................................... 377
21.15 (Flow) Assignment Model ......................................................... 381
22 Optimisation in detail ..................................................................... 383
22.1 The performance index ............................................................... 383
22.2 Optimisation selection ................................................................ 386
22.3 Optimisation of green times ........................................................ 390
22.4 Initial signal settings .................................................................. 391

22.5 Queue-length reductions ............................................................ 391
22.6 Degree of Saturation limits ......................................................... 393
22.7 Controller Stream groups (Node Groups) ...................................... 393
22.8 Cycle time selection ................................................................... 394
22.9 Cycle Time Optimiser ................................................................. 395
22.10 Multiple cycling and repeated greens ......................................... 397
22.11 Considering the effect of small changes ..................................... 399
23 Modelling Examples ....................................................................... 401
23.1 Supplied Data Files .................................................................... 401
23.2 A small network (Example 1)....................................................... 402
24 Modelling Signalised Roundabouts ................................................... 411
24.1 About this chapter ..................................................................... 411
24.2 Introduction .............................................................................. 411
24.3 The TRANSYT program ............................................................... 412
24.4 Modelling a roundabout (Example 2) ............................................ 412
24.5 Checking co-ordination ............................................................... 424
24.6 Example 3 a signalised motorway roundabout ............................ 425
24.7 Example 4 an urban signalised roundabout ................................. 434
24.8 Recommendations ..................................................................... 438
25 Definitions / Glossary..................................................................... 439
25.1 TRANSYT 14 GUI Terms .............................................................. 439
25.2 Modelling and Traffic Engineering Terms ....................................... 440
26 References ................................................................................... 457
27 Appendix A Import TRANSYT 13 files ............................................ 460
28 Appendix B Export to TRANSYT 13 ................................................ 461
29 Appendix C - Importing from TRANSYT 10/11/12 .............................. 462
30 Appendix D Importing from TRANSYT-7F ....................................... 464

31 Appendix E Importing SCOOT data ............................................... 468
32 Appendix F Importing SCATS data ................................................ 471
32.1 Creating data files from SCATS data ............................................. 473

Installing the Software Page 17

Introduction 1
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.
About TRANSYT 1.1
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.
TRANSYT, at the time of writing, can model up to 200 nodes and 1000 links within a network.
TRANSYT is suitable for both drive-on-the-left and drive-on-the-right operation.


Figure 1-1 The basic structure of the TRANSYT program
Many of the principles behind TRANSYT 14 are essentially the same as those at the heart of
previous versions of the program. However, TRANSYT 14 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.

Summary of TRANSYT 14 improvements 1.2
This section allows existing users of TRANSYT 13 to quickly familiarise themselves with what has
changed and what new facilities have been added to TRANSYT 14 by summarising the changes
and improvements. Full descriptions of the changes are to be found in other chapters.
Modelling:
Traffic Stream and Lane network
representation
Blocking back and platoon dispersion
modelled in the same network
Link-by-link selection of traffic models
Mutual opposition modelling
Enhanced opposed offside-turn model
Complex flare/blocking model
Improved modelling of oversaturated
conditions
Links controlled by up to two phases
Signal controller phases
Separate controller streams
Zero flows allowed
Conflicts defined by movement, link or
traffic stream
amber times definable per phase
Major & minor links with different conflicts
RR67 saturation flow estimation per lane
Constant red or constant green signals
Updated (WebTag-based) fuel consumption
calculation
other minor modelling enhancements
adjustable PCU length
Local OD Matrix traffic allocation using new
Lane Balancing option
New Wide-Area OD Matrix traffic allocation
using Journey Time Equilibrium
Enhanced Priority Object model
Calculation of Dutch TxC values

Graphical User Interface:
File comparison tool
PDF and Word format reports
Enhanced CFP graph
Enhanced X-Y Analyser graph
Easier manipulation of stage sequences
Choice of stage or phase based
manipulation of signal timings
NetCon PDM flow animation
Various NetCon improvements
Signal Terminology choice (UK/Aus)
Data File Library (template) system with
graphical preview screen.
Collection of library files covering the most
common junction layouts
User-defined relative offsets
Improved data-entry screens
Enhanced Time Distance Diagram
Locking of analysis sets and demand sets
Various other graphical interface
improvements
Instant mirroring of data files
Third-party product flow data import
Export to TRANSYT 13
Basic and Advanced modes of operation
Student Edition
Shaped source connectors
Enhanced Flow Consistency Tool
New Window Manager
Window Docking system
Enhanced Summary Results window
Multiple saveable network Views for both
NetCon and the TRANSYT Report


Optimisation:
Phase and stage minimums and maximums
Sophisticated stage and phase optimisation
Alternative optimisers (Shotgun Hillclimb
and Simulated Annealing) for improving
timings
Too high and too low link DoS penalties
Green splits locking

*needs ARCADY 7 or later and/or PICADY 5 or
later
Priority Junctions:
Priority junction objects calculate give-way
coefficients (slope & intercept)*
Assigning of calculated slope and
intercepts to links or traffic streams*
Fully unsignalised junction modelling*
Models one-way situations
Unlimited conflicts on give-ways
Modelling of indirect traffic control effects
at give-ways
Give-ways controlled by mix of signal
controlled and unsignalled traffic

For those wishing to evaluate the differences between TRANSYT 14 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 14, looking for the following
symbol:
About this manual 1.3
The coverage of this user guide is comprehensive and is intended for anyone who is likely to be
involved with the use of TRANSYT 14. It is hoped that new users will quickly understand the
program by reading, and by reference to this manual.
To achieve these aims, this user guide describes, in separate chapters, how to get started
quickly with TRANSYT 14 (particularly if you are already familiar with previous versions), data-
entry including full details of all the features of the graphical interface, 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 necessary.


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 14 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 25).
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.
Training 1.4
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
Student Edition 1.5
A student version of TRANSYT is available in addition to the full version. This version has the
same functionality of the standard version, apart from one specific limitation Data files saved
from within the student version cannot be loaded into the full version.
Several screens, including NetCon, are watermarked so as to easily identify it as a student
edition. The TRANSYT reports are also watermarked and the header information 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.
Related Software 1.6
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-VISSIM LINK is an award-winning
*
software tool that imports a VISSIM
network into TRANSYT 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. *ITS (UK) 2009 Forward
Thinking award for innovation. Versions are available for TRANSYT 13 and TRANSYT 14.
TRANSYT-Aimsun LINK is a software tool that imports an AIMSUN network into TRANSYT
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 13 and TRANSYT 14.
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.
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
many 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.
Data import from, and export to TRANSYT is provided.
OSCADY CLASSIC is (like OSCADY PRO) designed to model isolated (uncoordinated)
signalised junctions, but optimises using a stage-based approach. This product has been
superseded by OSCADY PRO.
All these programs are concerned only with the optimisation and operational performance of
individual junctions or networks. For the overall economic appraisal of wider based road
schemes, an economic appraisal tool will be required.
For further details of all these programs, and for latest news, current pricelists and purchasing
information, please visit www.trlsoftware.co.uk.

Product Background and Versions 1.7
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 14
represents another significant advancement of the product in terms of its traffic models, its
features, and its presentation.
TRANSYT 14.0 (released in October 2010) is the first release of TRANSYT 14.
TRANSYT 14.1 1.7.1
TRANSYT 14.1 was released in December 2011. Details of subsequent maintenance releases are
available at www.trlsoftware.co.uk.
Major changes introduced for TRANSYT 14.1 are indicated in the User Guide in the same way as
those changes made since version 13, using the New icon. For those who are only interested
in the changes since 14.0, a summary of the changes is given below:
- New Wide-Area OD Matrix traffic allocation using Journey Time Equilibrium (section
11.3.2)
- Local OD Matrix traffic allocation using new Lane Balancing option (section 11.3.3)
- Priority Object now models one-way traffic at T-junctions (section 13.3.1)
- New results output for each combined CPDM flared area (section 21.7.2)
- Netcon: Shaped source connectors (section 9.6.9)
- Netcon: Traffic Model Type overlay (section 9.7.4)
- Multiple saveable network Views for NetCon and HTML Report (section 9.3)
- Basic and Advanced modes of operation (section 6.5)
- Student edition (see section 1.5)
- New Window Manager plus user-defined default layout of windows (section 6.17.1)
- New window docking system (section 6.17.2)
- Improved Main Data, Link Data and Traffic Stream data-entry windows
- Easier configuration of Lanes within Traffic Streams (section 9.6.9)
- TRL Default Custom Grids (section 6.7.4)
- Report results grouped by controller stream (section 16.3.1.4)
- Flow Consistency Tool for Traffic Streams (section 11.2)

- Position within HTML Report now retained
- Enhanced Summary Results window (section 15.1)
- Amber times definable per phase
- Calculation of Dutch TxC values
- Network and stand-alone copy-protection versions in same install package (section 2.3)
- Registration of ARCADY and PICADY products via TRANSYT (section 2.3)
- Automatic recognition of both network and standalone licensed versions of ARCADY and
PICADY
- Improved selection of text data for display in NetCon (section 9.9.2)
News-feeder, Updates and Download system 1.8
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 13.1.0.63
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 have to 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.
Acknowledgements 1.9
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.



Installing the Software 2
Hardware/software requirements 2.1
TRANSYT 14 will run on any modern PC under Windows 7, Windows Vista or Windows 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
- Windows 7 / Vista / XP (32-bit or 64-bit)
- 3 GB RAM
- 250 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 14 may run on versions of Windows other than Windows 7/Vista/XP but this is not
guaranteed and is not formally supported.
Installing/uninstalling the software 2.2
To install the software, browse the product CD for SETUP.EXE, and run this file. This will launch
the product installer. If you have been supplied with the product as a zip file, extract all the
zipped files to a temporary folder, and then run SETUP.EXE from this temporary folder.
During installation, all necessary files are copied to the specified folder and an entry added to
the Windows Start menu.
To uninstall the software, please use the Windows Add/Remove Programs system, which is
available from the Windows Control Panel.
Copy-protection and software registration 2.3
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.
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 installation process. However, your selection must
match the licence type you have purchased.
Only the permanent Demo/Viewer version is supplied separately.

Some optional functionality of TRANSYT 14 requires either an add-in module such
as TRANSYT-VISSIM LINK and TRANSYT-Aimsun LINK, or another product to be
registered, such as ARCADY and PICADY. Details of the TRANSYT LINKS are
documented in the separate User Guide provided with TRANSYT. Details of what
added functionality is accessible if you have either ARCADY or PICADY is described
in section 13.1.
ARCADY and PICADY and the TRANSYT LINKS can be registered from within
TRANSYT using the main menu option Help > Licence Manager. 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.
Stand-alone registration 2.3.1
Each installation of the stand-alone version of TRANSYT 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
Network copy-protected (concurrent licence) registration 2.3.2
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.


Demo/Viewer version 2.3.3
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 30

Modelling Basics 3
This chapter gives an overview of the TRANSYT 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, such as flares.
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 25.
Traffic Model Basic Assumptions 3.1
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 the signals in the network 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.
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 constant
1
.
Network representation 3.2
TRANSYT 14 offers the users a choice of how to represent the real network being modelled
either using a series of nodes interconnected by links; nodes interconnected by traffic streams;
or a mixture of both.
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. Each
distinct one-way traffic stream leading to a node is represented either by a link or by a 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.

1
time varying traffic conditions can also be modelled in TRANSYT

Modelling Basics Page 31

Relationship between lanes and TRANSYT links 3.3
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.
This link 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 link.
The relationship between lanes on the road and the way they are modelled as links is illustrated in
Figure 3-1 and Figure 3-2. Figure 3-3 shows a simple triangular road network. Figure 3-2
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.
Page 32


Figure 3-1 Network and flows

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

Relationship between lanes and traffic streams 3.4
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.
Just like the alternative TRANSYT link representation, the traffic stream representation suggests
that a detailed knowledge of traffic routing through a network is necessary to define the traffic
stream within the model. 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 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-3 and Figure 3-4. Figure 3-3 shows a simple
triangular road network. Figure 3-4 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.
Page 34


Figure 3-3 Network lane structure with flows

Figure 3-4 Model lane and traffic stream structure

Flow, speed and link/stream/lane data 3.5
The TRANSYT model requires each link or TS 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.
Link length (or Traffic Stream length) is the distance between the upstream and downstream stop
lines. For links/streams which do not come from an upstream node, e.g. entry links/streams on
the perimeter of the network, it is normal to use a standard length such as 200m, but a zero value
may be used.
Traffic flows 3.5.1
Traffic flows are either specified directly using the method described below or are assigned by
the Flow Allocation Tool. A mixture of these options is allowed, so parts of the network will
typically have assigned flows and others flows entered directly. However any parts of a network
structure defined using lanes rather than links must use the Flow Allocation Tool and its
associated OD-Matrices data to calculate the traffic flows.
Where a Flow Allocation Tool is used, the OD Matrix data (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.
The following section describes how flows are assigned directly to links.
Links 3.5.1.1
Link flows are specified in the Links Data screen (Outline: Links > Link n > Link Flows). Flows are
normally specified in vehicles or PCUs per hour. For each link the user must specify the average
total flow along the link.
Each link may have associated with it a uniform flow source. 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.3).
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.
Cruise times and cruise speeds 3.5.2
Cruise times and cruise speeds are the un-delayed times (or speeds) for traffic travelling from
each upstream stop line (for each source (upstream link or TS)) to the stop line on the currently
selected link (or stream). 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,
Page 36

when the signal aspects at both ends of the link (or stream) are green. It is possibly better to
measure cruise time (as opposed to cruise speed) because it ignores any error in link length
measurement, and by measuring over the whole link it automatically takes into account skin-
friction, curves, bottlenecks etc.
Compatibility of link entry and exit flows 3.5.3
The sum of inflows to a link or TS 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 optimisation proceeds.
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.
Saturation flow 3.5.4
Saturation flow at a stop line is the maximum rate of discharge from a queue. It can be obtained
by measurement or calculation based on stop line width and other site factors, for further details
see section 19.3 or RR67 (Kimber et al, 1986). The saturation flow must be in units consistent
with those used in specifying link (or stream) flows.
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 link in
the Links Data Screen (Outline: Links > Link n > Link Signal Data > Green Period n) (see section
3.6), or may be modelled more accurately using the give-way facility (see section 13.13).
Entry and exit links and traffic streams 3.5.5
For entry links (or streams) 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 link or TS should be defined.
Exit links are not required by TRANSYT unless using the Flow Allocation Tool 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 Restricted Flow
and Is Signal Controlled options should also be de-selected. This ensures an infinite capacity
(unless using CTM) and indicates to anyone looking at the network that the link (or stream) 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.

Restricted Flow (Bottleneck) links and traffic streams 3.5.6
Bottleneck links or bottleneck TS 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 link (or TS) is treated in a similar
way to other links (or TS) 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 Links Data > Shared StopLines screen
(Outline: Links > Link n), as for signalised links, but the main link still has only a traffic node and
no associated controller stream.
Delays and stops are calculated for bottleneck links (or TS) exactly as for other links (or TS),
except that the flow leaving the link (or TS) 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 21.2).
Signal settings 3.6
NB for details of the actual implementation in TRANSYT 14, please see sections 12 and
13.13.
TRANSYT signal terminology 3.6.1
TRANSYT models the operation of the signal control at each controller stream by reference to
stage change times. A 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-5.
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 38


Figure 3-5 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 the nodes in the network fall
into three groups, as follows.
Signal values for whole network 3.6.2
These values are specified in the Main (Common) Data Screen (Outline: Network Options).
The cycle time for the whole network is specified in seconds.
The effective green displacements, to be applied to the whole network, are specified in seconds.
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 links in the network. Figure 3-6 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 red/amber-before-green period is omitted.
1 cycle for node 1
Distance
Time
Arbitary zero for time
Node 1
Node 2
Stage 1 green Stage 2 green
Change to
stage 2
Change to
stage 1
1 cycle for node 2
Stage 1 green Stage 2 green
Change to
stage 1
Change to
stage 2
Distance
in offset
between
node 1 and
node 2
offset for node 2
offset for
node 1


Figure 3-6 Effective versus actual signals
The global end displacement corrects for traffic continuing to flow during the amber-after-green
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.
Signal values for each controller stream 3.6.3
Each controller stream may contain data for up to 50 stages and 50 phases. These values are
specified in the Signals Screen (Outline: Controller Streams > Controller Stream n > Stages).
Phase data, phase delays, a library of stages, a collection of stage sequences and calculated stages
data relating to each stage used by the traffic model, are all stored within each controller stream.
Each controller stream makes reference to a particular stage sequence (the Use Sequence value).
The referenced stage sequence can be any sequence in the list of existing sequences for that
controller stream. Stage sequences can be created manually by firstly creating the required
stages in the Stages library, and then defining the order of stages in a new Sequence. For
convenience, all possible stages, plus a collection of the ten simplest valid stage sequences can be
generated automatically using a Generate Stages and Sequences routine.
From the above described data TRANSYT calculates internally information relating to each of the
stages that is going to be used by the model, i.e. those referenced in the current sequence. This
information is reported under the description calculated Stages.
The Stage change times, part of the calculated stages data, are always shown in seconds.
Green
Amber
D
1
D
2
Effective green displacement
at start of green
D =
at end of green
D =
Red/Amber
Green
Red
Red
Red Actual signal timings
Effective signal timings
Red
Page 40

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 still reports 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.
Stage Library, Stage Minimums and Interstages 3.6.3.1
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 optimisation routines and by the re-distribution or EQUISAT
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 black-out, if used) on the
pedestrian stage. Since no traffic flows during the pedestrian stage, the pedestrian stage length
used by TRANSYT, after optimisation, is the interstage time plus the minimum green period.
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.
Phase Constraints 3.6.3.2
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.
Derived Phase Values and Green periods 3.6.3.3
During one cycle a link (or TS) 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.
Links (or TS) 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 by the TRANSYT model. Some of these parameters can be seen in the
Resultant Stages Data produced by TRANSYT. They may be recognised by users
of earlier releases of TRANSYT, but generally are likely to be of limited interest to
users.
E.g. starting and Ending Stages are derived from the library stage data. The
internal time at which the actual green begins is specified by a TRANSYT Starting
Stage number and a start lag of a fixed number of seconds. Similarly, the time at
which green ends is specified by a TRANSYT Ending Stage Number. The calculated
Start and End lags (used internally by the TRANSYT model) are derived from the
user-specified intergreens and phase delays.
The Starting Stage number defines which of the stage change times starts the
change to the green period on the link (or TS). The start lag then gives the time
in seconds from the stage change time to the start of green signal on the link (or
TS). Usually the start lag corresponds to the interstage time, as shown in Figure
3-7. TRANSYT adds the displacement of start of effective green (see Figure 3-6)
to this lag to give the time of start of traffic flow assumed in calculating delays etc.
for the link (or TS).
The Ending Stage number 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).
Following the ending stage, there is the TRANSYT end lag defining the time in
seconds from the stage change time to the end of green signal. The same
considerations apply as for the start green lag regarding any extra adjustments.
Often this value is zero.
Should the link (or TS) have a second green, the corresponding values detailed above for the first
green will also be derived by TRANSYT for the second one.

Page 42


Figure 3-7 Lag between change demand and start of green signal
Phase Delays 3.6.3.4
Phase actual green times are specified relative to the genuine stage start and end times using
absolute phase gaining and phase losing delays. Relative phase gaining delays can also be
specified, which are relative to the relevant intergreens rather than the stage ends. These values
can either be entered directly or manipulated graphically in the Timings Diagram. Stage change
times are always needed by TRANSYT, and initial ones can be provided by using the Signal Option
Auto Redistribute or EQUISAT routine from the Tools menu of in the Timings Diagram.
Phase Effective Greens 3.6.3.5
As well as the global start and end displacements, additional relative displacements may be
specified for individual phases, if it is thought that the values for that phase differs from the
overall value.
The displacements in the Main (Common) Data and the relative displacements are added
together in the program to give the effective green times before the queue calculations are
carried out. For example, if the global network start displacement (see section 12.7) 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 17.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.
Amber
Red
Red/Amber
Green Green
Red Green Red Red
Start
Lag
Start
Lag
Start green on
stage 2
Start green on
stage 1
Demand
change to
stage 2
Demand
change to
stage 1
Stage 1 actual signals
Stage 2 actual signals

Traffic behaviour within a link or traffic stream 3.7
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 links (or TS). 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 links (or TS), 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 20 and on cyclic flow profiles
in Section 15.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 is used as a direct replacement for the Flare model that was in previous
versions of TRANSYT, but it is more capable. See section 3.12
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 1.
Delays, Queues and Stops 3.8
Total delay to traffic on a link (or stream) 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
Page 44

the sum of the average queues at all the stop lines. In TRANSYT, the total delay rate for traffic
on a link 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 21.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.
Maximum queues 3.9
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 links
(or streams), 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 links (or streams). The signal optimiser then attempts to find settings which
make it less likely that the maximum queues will exceed the limit values (see section 22.5)
Furthermore, the new Cell Transmission Model (CTM) does model blocking back effects, which
can be used instead of the PDM model in certain circumstances.
Mean maximum queue 3.9.1
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-8). 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 value printed out.


Figure 3-8 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.
0 4 8 12 16
4 5 6 7 8
4 3 2 1 0
time
Arrival rate = 1 pcu / 4 seconds
Departure rate = 1 pcu / 2 seconds
Max. back of queue
Queue
Queueing vehicle
Vacated space
Stop line
Page 46

Give-way situations 3.10
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 following sections 13 and 21.5.
Shared stop lines 3.11
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.
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 21.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-ways.
When representing your network using traffic streams and lanes instead of links, you should use
multiple OD Matrices to represent the different vehicle types.


Flared Approaches (and CPDM) 3.12
TRANSYT provides a facility to model the extra capacity available from flared approaches (short
lanes) giving an extra lane or lanes at the stop line. This is provided by the congested platoon
dispersion model (CPDM). In essence, this is a link that has the ability to fill-up, and block
upstream traffic entering it due to its restricted length.
To model a short flare you simply add the appropriate link or TS type and set its traffic model to
CPDM. The maximum queue storage value then determines the amount of traffic that can store
in the flare (short lane). It is recommend that CPDM links are used for links up to 30 metres. For
short bays significantly longer than 30 metres the CTM model will be a more appropriate and
accurate model to use. The link or TS structure is the same for both CTM and CPDM, so switching
models is easy.
In the simplest case this the CPDM model will provide additional capacity which will have an
equivalent effect to that of the TRANSYT 13 (or earlier) flare model - see the stepped form of the
non-linear saturation flow Figure 3-9 which contrasts with the constant, single valued, saturation
flow for non-flared links.
Importantly the new model (CPDM) is considerably more flexible as it will 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.

Figure 3-9 Stepped saturation flow of a simple flare / short lane
For further details on modelling flares see section 21.7. This includes examples of the various
cases where flares are used. Data-entry requirements are detailed in section 8.5 and 8.6.

Flared Approaches (and Quick PDM) 3.13

0
green time
sat.
flow
Page 48

In addition to the new CPDM flare method with its increased applicability, the original quick
flare model is also available for use within TRANSYT 14.

This model provides a facility to model the extra capacity available from flared approaches giving
an extra lane or lanes at the stop line. The non-linear saturation flow is of the stepped form
shown in Figure 3-10. It contrasts with the constant, single valued, saturation flow for non-
flared links or traffic streams.

Quick Flares can be used with the CTM, PDM or quick-PDM link models, but their primary use is
with the Quick PDM model which offers a simpler but quicker solution.

Figure 3-10 Stepped saturation flow of a simple flare / short lane
For further details on modelling flares see section 21.9. This includes examples of the various
cases where flares are used. Data-entry requirements are detailed in section 8.5.

0
green time
sat.
flow
Optimisation Basics Page 49

Optimisation Basics 4
This is only a brief overview of the TRANSYT optimiser. Since changes have been made to the
TRANSYT optimisers, existing users of TRANSYT should also read this. 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.
Network timings optimisation 4.1
The optimisation process searches for a set of timings for the network which minimise queues
and delays 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 14 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 22
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. Alternatively a
process called EQUISAT (Equalisation of saturation can be used which removes the need for the
user to provide these initial timings.
The controller streams which are to be optimised are listed in the Optimisation Order List
(Outline: Network Options > Optimisation Options > Optimisation Order). 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 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.
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.
Another comma-separated list is provided to allow the locked controllers to be
specified (see section 22.3.1 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.

Cycle Time optimisation 4.2
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
Page 50

selected. The operation of, and output from the Cycle Time Optimiser is described in section
22.9 which also discusses issues related to the choice of cycle time.
How to use TRANSYT 14 Page 51

How to use TRANSYT 14 5
Essential GUI terms you need to know 5.1
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 14. Please spend a few moments reading the
introductory section of the Glossary. (TRANSYT 14 GUI Terms)
Quick start for TRANSYT users 5.2
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 14 Input
Data),) 8 (Other Data Entry Screens), and 9 (Network Construction Editor (NetCon)). For details
of further program functionality please browse through the rest of this User Guide.
There is no fixed route through TRANSYT 14, 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.
If you are a new user 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. Even with advanced mode
switched off, 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.

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 New File, TRANSYT will start off
Page 52

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.

Although the Data Editor can be used to enter most data it will often be easiest to use the
Network Construction Editor (Netcon) 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 NetCon, 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.


Network: traffic nodes, lanes and links
2. Optionally, use NetCons Insert Library File button to merge more junctions into your
network Thus saving you time (section 7.2).

3. Having merged all the files you wish to bring into your network, now connect the relevant
links and traffic streams.

4. 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 (9.6.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
NetCon and can affect how many paths an OD Matrix generates. There is only one type of
traffic node (unlike TRANSYT 13), with a different 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 the Flow Allocation Tool to assign flows to the network, and also hide the
underlying structure of the network.

If using lanes carry out steps 5 to 12 and if using links carry out steps 13 - 18.

When using Arms, Traffic Streams and Lanes:

5. 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.
6. 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
Page 54

occurs. 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 nearest equivalent is a major link).

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

8. Attach each Arm to its traffic Node using the connector tool in NetCon. These associations
are shown with the blue cones; moving each traffic node will now move all attached arms
as well.

9. Create one controller stream for each genuine controller stream, and attach each
signalised traffic stream to the relevant controller stream using the connector tool in
NetCon. This tells TRANSYT which controller stream controls the traffic for each signalised
traffic stream. These associations are shown with the green cones. N.B. By default traffic
streams are connected to controller stream 1 (if it exists). The connector tool can be used
to redirect connection to the right controller stream.



10. Attach each traffic stream to its downstream traffic streams by using the connector tool in
NetCon.

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

12. 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.
Page 56


When using Links:

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


14. Attach each Arm to its traffic Node using the connector tool in NetCon. These associations
are shown with the blue cones; moving each traffic node will now move all attached arms
as well.

15. Create one controller stream for each genuine controller stream, and attach each link to
its controlling controller stream by using the connector tool in NetCon. 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.

16. Attach each link or TS to its downstream link(s) or TS(s) by using the connector tool in
NetCon.

17. Set up any shared stop lines by using the shared stop line tool in NetCon.

Page 58


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

19. 1
st
ALTERNATIVE: As an alternative to using the Data Outline and Data Editor, you can
use the Signals, Links and Streams screens, which show all common data in an easily
accessible format (see chapter 8).

20. 2
nd
ALTERNATIVE: Use one or more Data Grid screens to rapidly enter data for all traffic
streams, links, etc. in one go (see section 7.6). This saves having to click on each item in
turn, especially if you have all data to hand in a tabular form.


Traffic Flows

You have a choice to enter traffic flows directly or to use the Flow Allocation Tool to assign
flows from an OD-Matrix. 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 two or three junctions (a signalised roundabout counts
as one junction) as otherwise the underlying structure within TRANSYT can become very large
and will slow TRANSYT down appreciably.

When using an OD-Matrix to define flows:

21. Use NetCon to add a OD-Matrix (section 11.3) and then add the required number of
locations. (Locations are where traffic enters and leaves the network.) Using the
connector tool, attach each location to the link to which the traffic will be entering the
network and also attach the 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 link, and exit link to
the 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 Flow Allocation tool are valid paths. If not, disable
those that are not, using the Allocation Type.

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.

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

Page 60


26. ALTERNATIVE: Use the Links or Streams Data screen to view and edit sources for each
link or stream and all flows for links.

27. ALTERNATIVE: Use one or more Data Grids to view and edit for all flows for all links (and
similarly for all sources) or for each traffic stream.

TIP: Use the Flow Consistency Diagram to check the consistency of flows entering and leaving
each link. For traffic streams the Flow Consistency Diagram can also be used to check the
consistency of traffic crossing from one OD Matrix to another.



Signals

There are various ways of entering signals data: some suggested methods are given below:

The two Signal Representation Modes of TRANSYT 13 do not exist in TRANSYT 14
A single, straightforward method of representing signal timings has been
adopted. However, the Timings Diagram does provide two different manipulation
modes stage mode or phase mode.

28. Use NetCon to add the required number of controller streams.

29. Attach each link or TS to set the controller stream controlling it by using the connector
tool in NetCon.

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


31. On the same tab, set any minimum greens or maximum greens you wish to define.

32. For each link or TS use NetCon (Right-click on controller stream), Link Data Screen, TS
Data screen or Data Editor to set the Signal Phases which define the signal conditions
given to each link or TS. Up to two phases can be associated with each traffic stream or
link, which allows filters and turn indicative arrows to be modelled. Note: NetCon can only
be used to set up the first phase.

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

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. 1
st
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. 2
nd
ALTERNATIVE: Double-click on a controller stream in NetCon to display the Timings
Diagram for that controller stream. 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.

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
Page 64

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. 2
nd
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. 3
rd
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.
Stage mode ensures stages are NOT created, destroyed or redefined.


Network properties (NB you may prefer to set these at the beginning)

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

44. Use the Main Data screen (or Outline: Network Options>Optimisation Options) to choose
which optimisation type and optimisation level you would like to use. Also select whether
to apply the auto-distribute (stage timings) routine as part of the optimisation process.

Running the file and inspecting results

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

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


47. Inspect network results by locating Network Results in the Data Outline and then
expanding the relevant section.

48. Inspect individual link results by expanding the Results section of each link in the Data
Outline.

49. Inspect collections of link results with the Data Grid screen.

50. To analyse any subset of controller streams, traffic nodes, traffic streams or links, define a
collection (Outline: Collections and Routes).

51. Generate CFP, Queue and CTM graphs using the Graphs button.



52. Generate a report that summarises all input and output data by clicking the Run Report
button.

53. View the optimised signal timings via the Timings Diagram.

54. Compare files using the main menu tool Compare Files

55. View animations of signals, link effective greens, queues and cell occupancies in
NetCon by showing the Animation Controls screen and then selecting from various options
within NetCon.

Page 68


56. Generate Time Distance Diagrams using the Graphs button, in order to observe
coordination along links.

General GUI operation Page 69

General Graphical User Interface (GUI) 6
operation
General 6.1
The TRANSYT GUI contains many screens, many of which can be displayed at the same time. It
is dynamic, in that altering a value on one screen will if necessary 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 (Evaluation
run only i.e. not optimised) as input values are changed. Many screens also interact with each
other. 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 14. 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.
Getting help 6.2
The whole of this User Guide is available from within TRANSYT as an electronic document. To
access this help file, use the Help menu, or, press F1 at any time.
Page 70

If you cannot find an answer to your question, check the TRL software website for latest news or
contact us directly at TRL.
Accessibility 6.3
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 main Preferences screen. Select File>Preferences, and then
adjust the options in the Colours section.

A number of NetCon colours can also be changed via the NetCon options screen.
Demo (and Viewer) mode 6.4
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 or run files. 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 2 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 14 files include results from running the program, the demo
version of TRANSYT 14 can be used by anyone to view both the input and output
from TRANSYT 14 files. This includes animations and graphs, as long as the offer
of re-running the file is taken up.


Advanced Mode 6.5
TRANSYT has a considerable number of inputs, outputs, options and features. 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. It is recommended that
anyone totally unfamiliar with TRANSYT should switch this mode off while they learn the basic
operation of TRANSYT, i.e. work in Basic Mode.
By switching off Advanced Mode a number of advanced, and non-essential inputs, outputs and
features are hidden, making it easier to get to grips with TRANSYT.

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.
Speed of operation and large files 6.6
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
Page 72

- The CTM traffic model is significantly slower than the PDM traffic model. Model links and
traffic streams that cause no blocking back problems using PDM. 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.

See also section 6.12.1.

Main toolbars 6.7
Main Menu 6.7.1
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.
The 'Go To' menu 6.7.2
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 Node Go To Link and Go To Traffic Stream options to go straight to a specific
node/link/traffic stream if you know the ID of the node/link.
Horizontal toolbar 6.7.3

From left to right, the buttons on the horizontal toolbar are:
Icon User guide reference
New File
Managing files Open File
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 Windows Manager Windows Manager
Back
Changing the active data item
Forwards
Previous
Next
Toggle Auto-Run
Running files Evaluation-only Run
Run File
Generate Report Reports

Page 74

Vertical toolbar 6.7.4
From top to bottom, the buttons on the vertical toolbar are:

Icon
Show/hide Summary Results screen
Show a new NetCon 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 the Local Flow Allocation Tool
Show the X-Y Graph Analyser
Show Flow Consistency Diagram
Show the Cycle Time Optimiser screen
Shows a menu of available graph types
The TDD button shows a new Time Distance Diagram
The Custom button allows you to quickly access any user-
defined data-grids. It is populated with a few useful pre-
defined data-grids.


Changing the Active Data Item 6.8
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, Link 110 or Node 7. It may also be a specific type of data
such as Link 110: Modelling Parameters, or a general network wide item such as Network
Options. See section 25.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 7.6)
- Click or double-click on the item in NetCon
- 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 Link 1: Modelling, the Next button will move to Link 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 76

Padlock system 6.9
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 NetCon, 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 NetCon 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 NetCon, 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.

Page 78


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.
The 'Edit in Window' System 6.10
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.
Types of Data 6.11
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.
There are several reasons why items may be disabled:
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
o It may be a data item that is shown for information only and is always calculated
by the program (i.e. never editable)
- If a data item is a result, i.e., an output from TRANSYT, it is shown with a light green
background:

Page 80

- 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.
Units 6.11.1
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) (NOT pence, as in TRANSYT 12), but you can
change this to any other symbol via Network Options>Economics>Unit of Cost in the Data
Outline.
In the screenshot below, the user has used euro 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. Change these
via the Options>Units section of the Data Outline. 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.


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 main preferences).
Link IDs and other unique IDs 6.11.2
TRANSYT works with links, nodes, controller streams, arms, lanes, traffic streams, routes,
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 Links with the same
ID, and similarly with nodes, controller streams, arms, routes, locations and paths.
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 link or other item via the Data Outline or NetCon, 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 Link 112 should be named Link X120, you can make the change using the Data Editor: any
part of the file that referred to Link 112 (e.g. link sources/upstreams, shared links, give-way
links, and so on), will automatically be changed to refer to the new ID, and so the file will remain
self-consistent.
Referencing Traffic Streams, Lanes and Link-shares 6.11.3
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
Page 82

Stream ID. So 7/1 as shown in screenshot is referring to first Traffic Stream on Arm 7. In
NetCon 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.

Sorting Network Items 6.11.4
As explained above, TRANSYT works with many network items, such as links, 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 links, traffic
streams, 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 main preferences). You
will therefore see the same sorting of controller streams/traffic streams/links/collections and
routes every time you load the file.
Regional Settings 6.11.5
This is where TRANSYT allows file-based regional-specific options to be selected. At the moment
there is only one such option The option to tell TRANSYT to calculate US Highway Capacity
Manual (2000) Level of Service values. Product-specific regional settings are changed via the
main Preferences screen (File>Preferences).
Details of the Level of Service (LoS) calculations are in chapter 17.3.4.
Page 84


Running Files and using Auto-Run 6.12
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 model (e.g. Quick PDM, PDM/CPDM or CTM). 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

Run Times 6.12.1
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 the Quick-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 slower
than both Quick-PDM and PDM.
The status bar at the bottom of the main screen shows what TRANSYT is doing at any time.
Managing files 6.13
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 NetCon or using the Merge Network facility. See section 19.2 for details on this.
Page 86

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.
Importing from older versions and from different products 6.13.1
TRANSYT 14 can import data from TRANSYT 10, TRANSYT 11, TRANSYT 12 and TRANSYT 13
using the relevant File > Import option. See Appendix C - Importing from TRANSYT 7-
SET/10/11/12 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.
Appendix D Importing from TRANSYT-7F.
Appendix E Importing SCOOT data
Appendix F Importing SCATS data

Files generated with different releases of TRANSYT14 6.13.2
If a TRANSYT 14 file that is opened has been generated with a different release of TRANSYT to
the one currently being used, a message will report this and provide an option to examine a
report detailing any differences made to the file as it is opened. 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.
Exporting data to TRANSYT 13 6.13.3
TRANSYT 14 data can be saved to a TRANSYT 13 file format by selecting File>Export>To
TRANSYT 13. See Appendix B Export to TRANSYT 13 for full details.
Duplicating a file 6.13.4
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.
Opening a file's containing folder 6.13.5
Click on the File>Open Containing Folder to open the folder where the file is located in Windows
Explorer.

Saving results from TRANSYT runs 6.13.6
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 particularly useful if it is a large network or is
otherwise slow to run. Showing the Summary Results screen at any time will always give you a
summary of what data is available and when the file was last run.
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 14, 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 14 can be downloaded
from www.trlsoftware.co.uk.
Undo/Redo 6.14

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 because they automatically re-run the file (assuming 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 TRANSYT Preferences regarding reducing the number of Undo points to
reduce the memory requirements of TRANSYT.
Page 88

Save Diagram State 6.14.1
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 NetCon diagram layout. Subsequently you can
revert back to the NetCon 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 Netcon save option.
Copying data to the clipboard 6.15

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 NetCon diagram,
for example, click in the NetCon window 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.
Printing 6.16
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
NetCon, the Report Viewer, and also various other screens such as graphs and the Timings
Diagram.
Use File>Page Setup to control the paper size and orientation.
Managing Windows 6.17
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 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 personal 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).

Window Manager 6.17.1
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.
Docking system 6.17.2
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.
Page 90

How to dock and undock windows 6.17.2.1
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.

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.



Preferences Screen 6.18
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.

General:
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.
Page 92

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.
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.
Reports:
All the Include options set the default report items that will be included in the
report. All the items shown here are also editable on the Report Viewer screen.
Report 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.
Flow Units for CFP graphs: choose either PCU/hr or PCU/step for the vertical axis for
CFP graphs
Link Connector Arrow Type: controls how arrow directions are automatically calculated
in NetCon and also in Stage Sequence diagrams
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.
Junction/Network Diagram:
Safe Mode: Turn this on if you experience any problems with text rendering in NetCon.

Start NetCon Inside Application Window: Turn this on if you wish to have NetCon
opening in its own Window on a permanent basis. This option is useful when using
multiple monitors, and wishes consistently to use NetCon on its own monitor. This option
can also be set within NetCon on temporary basis.
Colours: Use these options to adjust the default colour scheme for various items.
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:
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 TRANSYT14-Aimsun User Guide for details on this option.
Transferring user preferences 6.18.1
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.

Page 94


TRANSYT 14 Input Data Page 95

TRANSYT 14 Input Data 7
Data Files 7.1
TRANSYT 14 saves data as files with a .T14 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 full 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.
See 6.13 for more details about file-handling.
Library Files 7.2
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 14, which can be supplemented by any files users wish to store as additional library
files. TRL supplied Library files are displayed in blue.

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 NetCon or using the Merge Network facility. See
Page 96

section 19.2 (Merging Networks) for details on this. When Library files are saved, a snapshot
image of the NetCon is stored with the file so that a preview screen can be provide 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 14 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 14/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
NetCon button.
In addition to the ordinary Library Files, some of the pre-supplied Library Files are deemed to be
sacrosanct and cannot be altered or deleted. These files do not show up in the Library File
folder, but do appear in the Library List.
Data Outline 7.3
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 NetCon 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
textual description, 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, Routes, Controller Streams, Traffic
Nodes, Arms, Links, Priority and OD Matrices.

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 shop TRANSYTs Advanced/Detailed data items option has been switched on, revealing
the Advanced items Priority Roundabouts and Priority T-junctions.
Page 98



Data Outline Screen 7.4
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 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 NetCon 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 if it is not already shown.
Page 100

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 nodes and links, and to
remove existing ones. For example, to add a new link, firstly select any of the existing links (or
the Links 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 NetCon.
Notes:
- In some cases, TRANSYT will prevent you from deleting an item if it is the last item in the
group for example, you cannot delete Traffic Node 1 if there are no other traffic nodes.
- When adding a new item, the new item's data fields are copied from the Active Data
Item. For example, if you select Link 2 and then click Add, then the new link 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 Link 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 Link 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.
Data Editor Screen 7.5
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 NetCon), 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)
Data Grids 7.6
Data Grids show and let you edit potentially large amounts of data in a concise, customisable,
manner. See Data Grids (Section 8.1) for full details.
Network Construction Editor (NetCon) 7.7
NetCon 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
Netcon (chapter 9) for full details.
Task List 7.8
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.
Page 102


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.
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.)
Data Field Finder 7.9
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 then click Find; 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.
So if, for example, 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.
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.

Page 104


Other Data Entry Screens Page 105

Other Data Entry Screens 8
Data Grids 8.1
Data Grids provide a convenient way of viewing and editing several rows of data at one time.
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 also 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 Link (or click on a Link in NetCon, or any other
screen), then any Data Grid screens will show all link properties (ID, Name, Description,
Saturation Flow, etc.) for ALL links 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 Link, then any Data Grid
screens will change to show all Modelling properties for all links.

Page 106

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-mode 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.
Selecting items 8.1.1
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 NetCon 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; NetCon shows the same links highlighted in orange. This also
works the other way round click on items in NetCon to see them highlighted in the Data Grid.



Grid orientation 8.1.2
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.

Locking the grid 8.1.3
Please see section 6.9 for use of the padlock system.
Editing data 8.1.4
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 108

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. Queue
Limit is greyed out if Has Queue Limit 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. Other items
may be greyed out depending on the state of other data value, 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.
Using an external spreadsheet 8.1.5
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.
Sorting and grouping rows 8.1.6
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.
Adding/deleting rows 8.1.7
To add/delete rows, right-click on any row header. This will show a sub-menu where you can
choose to delete the current row or add a copy of the current row. You can also a new row,
which will use default values for all fields as opposed to copying the current row. For example if
showing a Data Grid of links, you can use this menu to add new links 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 link. These extra options are also useful for any situation
where none of the chosen item exists for the selected link/traffic stream etc.
Column layouts 8.1.8
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 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 NetCon. 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 110


The Data Grid should now look like the below:

You can save column layouts by selecting Column Layouts>Store Current Columns Layout.
This will prompt you to enter a name, and this layout will then be available in the Column
Layouts 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 column layout. Column layouts are saved to your personal
preferences; not in the file.
Select Column Layouts>Manage Stored Column Layouts to access a screen where you can see
all saved column layouts and rename/delete them. You can store multiple layouts for the same
data item (e.g. Traffic Streams). If you tick the IsDefault column then this layout becomes the
default layout for that data item and will be chosen automatically every time you show an

appropriate Data Grid in this way you will not have to select it manually each time. Tick the
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.

Mixing input and output data in Data Grids 8.1.9
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 Results>Summary for any major link in the Data Outline.
The Data Grid will show summary results for all links.
- 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 Column Layouts>Remove All Columns
- In the Data Grid, turn on Column Layouts>Add Columns 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 link and then in the Data Editor select Length. Then select
Link Flows>Total Flow
Page 112

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 Column Layouts menu. (See Section 16.4)
In the example shown below, the grid shows both input and output versions of saturation flow
and total flow. This clearly shows differences between the inputs and outputs, due to e.g. a
sensitivity multiplier on link 2.

Viewing results and time segments 8.1.10
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 links, show a Data Grid and then click on the Results section of any link
the Data Outline. (The screenshot below shows the Results>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 links in the data
grid. By default, these will therefore be network totals, but, if you have filtered the grid to show
e.g. only bus links, then the totals will be for bus links 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 links, but, this information is available in
generated reports.
Filtering rows 8.1.11
The Filters menu provides a way to restrict the Data Grid to show only certain rows. A set of
built-in filters is provided, and you can also build your own using the Query Builder tool.
The built-in filters available depend on the type of Data Grid. For example if showing a Data
Grid of Links, only the Links filters will be available.
We recommend using the padlock system to prevent Data Grids from switching to showing other
data as you change screen see section 6.9.
Some filters are self-explanatory, such as Filters>Links>Bus Links Only. This will restrict the
Data Grid so that only bus links are shown in the grid. If you edit a link and make it a bus link,
the Data Grid will update to include this new bus link.
Other filters are more advanced and may depend on selections that you make in other Data
Grids or in NetCon. The general idea is that screens interact with each other, so that each Data
Grid dynamically updates according to what you have clicked on in the Data Outline, or NetCon,
or other Data Grids, or what selection you have made in these screens.
To remove any filters, click Filters>No Filter or simply close down the Data Grid and open a
new one.
A few examples are shown below.
In the screenshot below, a Links data grid has its filter set to Filters>Links>Links Controlled By
Selected Traffic Streams. Node 2 has been selected in NetCon, and so the Data Grid only shows
links 21-25, all of which are controlled by Node 2. Clicking on a different node in NetCon would
update the Data Grid to show links controlled by that node or nothing, if no node is selected.
If you dont want the Data Grid to keep changing, use the padlock to lock the rows to the exact
rows shown.
Page 114


In the screenshot below, a Links Data Grid has the Show Only Items in Current Selection mode
enabled (this is a special filter that applies to any type of item). A rectangular selection has
been made in NetCon 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.


Query Builder 8.2
Launch the Query Builder screen from any Data Grid or via the main application Tools menu.
The Query Builder is intended mainly for use with Data Grids, but, it can also be used to
calculate how many items (if any) match a query - for example, to find out if the network
contains any signalised links of length <200m where the DOS threshold is exceeded. (Of course
you could just scan down the results or a generated report, but, with large networks or more
complex queries this may be difficult and/or tedious.)
The Query Builder is a powerful and flexible tool and the example given here is relatively simple.
In common with many other screens in TRANSYT, the data fields of interest are set in the Query
Builder by clicking on them in the Data Editor or in any Data Grid screen. In way you build one
or more clauses (sections) of the query. In the example above there are three clauses (link
must be signalised, length is less than 200m, and DOS threshold exceeded).
The Query Builder after setting up the above example is shown in the screenshot below.

Start off by selecting a data field in the Data Editor (or in a Data Grid click in any cell); it will
be shown at the top left of the Query Builder. Select an operator from the menu (=, <, > etc,
depending on the data type), and then enter a value or choose from a drop-down list in the
Compare to box. The press Add Query Clause, and it will be added to the Query Clauses list.
Use the OR/AND options to control how the clauses should be combined. In this example, the
AND option (default) is used, since we want all three conditions to be met.
If there are no errors, then the status bar at the bottom gives a quick indication of how many
items in the TRANSYT network meet these conditions. To see the actual links, drag from the
Query Clauses box into any Data Grid. I.e., click anywhere inside the Query Clauses box,
and then drag the mouse pointer on top of any Data Grid. Releasing the mouse button will then
set the Data Grid into Filters>Query Builder mode and will show the results of the query, as
shown in this screenshot:
Page 116


In this example, there are six links that are less than 200m in length AND are signalised AND
have their DOS threshold exceeded. Note that what you see in the Data Grid depends on what
data item the Data Grid contains: the grid shown above shows Links, and the one below shows
Link Results. As explained elsewhere you can usually build your own column layouts in the
grids.

Here is another query example where a Data Grid shows all Phases with a minimum green
greater than 7 seconds.


Continuing with this same example, using this filter in a Data Grid to show all Phases with a
minimum green greater than 7 seconds would show ALL green periods for all phases that meet
the conditions in this case, the green periods for Phase 11 and Phase 13.

Imagine now that you wish to filter further and are only interested in green periods where the
above conditions are true and furthermore the green period is one that starts in the first half of
the signals cycle (for whatever reason). Adding this further clause to the Query Builder would
look like the below:

In this case, there are two possible types of results: you may either want to view all links
containing at least one green period whose start time is less than 46s, or, you may only want to
view the green periods themselves. TRANSYT wont know which of these possibilities you want,
so use the Data Item To Find box and then drag the query into an appropriate Data Grid. If the
Data Grid shows Green Periods, then it will either show 2 rows or 1 row depending on which
option you select here.
It is not currently possible to save queries, but, you can press the Edit manually button and then
save the code that is shown in a text file. Subsequently you could paste this text back in and re-
run the query.
Page 118

Main (Common) Data Screen 8.3
Although all main data (data common to the whole network) is available via the Data Outline
and Data Editor, this data is also available via a Main Data Screen, which you can access via the
button on the main vertical toolbar or the main View menu. The layout has been chosen to
ensure that the commonly used data appears on the first visible tab on the screen and the rest
split between the remaining three tabs.
The data on this screen works in exactly the same way as the Data Editor.
You can leave this screen visible and it will update and synchronise with other screens, as with
any other window in TRANSYT.



Page 120


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

Signals Data Screen 8.4
Although all Controller Stream data is available via the Data Outline and Data Editor, commonly
needed data and useful signal related tools are also available via a Signals Data Screen, which
you can access via the button on the main vertical toolbar or the main View menu.
any other window in TRANSYT.
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.

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.4.7, while a full description of the contents of each tab is given here in the following
sections:
Controller Stream 8.4.1
The Controller stream tab shows the basic controller stream data such as its ID, name and
description.
The reporting of relative offsets (positive and negative) can be set up from this screen. See
section 17.1 on how these appear in the TRANSYT output.
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.
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.

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

Page 122

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.
Phases 8.4.2
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 more phases 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.
For convenience two buttons are provided If you click on Create New Phases you will be
asked to enter the number of phases you want and TRANSYT will remove all existing phases and
add the number you asked for. After setting the number of phases you will often want to set up
the conflicts between phases. The Intergreen Matrix conveniently opens the intergreen matrix
screen for you.

Stage Library 8.4.3
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 more stages
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 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.
An addition three buttons are also provided, in order to make it quick and easy to set up your
stage data for the currently selected controller stream. 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 second button, Create New Stages allows you to quickly add as many library stages
as you like. Click on the button, enter the number of stages you wish to add, and then confirm
whether or not you wish to add them to the existing library stages or to replace them all. If you,
for example, use the button to ADD two more stages, TRANSYT would add the Library Stages 3
and 4, both of which will have no phases running in them.
The third button, Interstages opens the interstage tab of the Intergreen Matrix screen, to
let you see the derived interstages.

(Phase) Delays 8.4.4
The Phase Delays tab shows a grid of phase delays for the current controller stream. By default
the grid is empty. To add the first phase delay, click the button Create New Delays and enter
the number you want. Once you have created at least one phase delay 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, or use the button which gives the option of either replacing all the existing delays
or adding to them.
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.
Page 124

N.B. Phase delays can also be created and deleted directly on the timings diagram. See
chapter 12.

Stage Sequences 8.4.5
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 more sequences 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 option to either delete, copy or 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.


Resultant (Stages and Green periods) 8.4.6
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 and end times can also 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.

Page 126


How to use (Signals Data Screen) 8.4.7
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 12
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 NetCon):
1. Create your new controller stream, if needed, either in NetCon or via the Add a new
Controller Stream button on the data outline.
2. In Netcon 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 NetCon. 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. 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. 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.
Links Data Screen 8.5
Although all Links data is available via the Data Outline and Data Editor, commonly needed data
is also available via a Links Data Screen, which you can access via the button on the main
vertical toolbar or the main View menu. The data on this screen works in exactly the same way
as the Data Editor.
any other window in TRANSYT. You can also lock the screen to a particular link.
Select the link to view using the list on the left hand side, or via the Data Outline, or via NetCon.
You can also use this screen to add/delete links.
Each of the data grids in this screen (for flows, give-ways, etc.) works in exactly the same as
any other Data Grid, including the ability to add/delete columns and rows.
See notes below for each tab.

The Modelling tab is split into two sub-tabs: The first allows weight and penalties, as well as
queue limits and the new degree of saturation limits to be specified.
Page 128


The second traffic Modelling tab allows maximum queue storage to be set as well as some
advanced items such as dispersion type and queue and delay calculation parameters.

The Flows tab shows a grid of each Source for the current link. If the link is an entry link, then
the grid will have only one row and will apply to the entry sources. Add new sources by right-
clicking on the row header and selecting Add New Source. If the link is not an entry link (i.e.
has at least one internal source being fed from another link), then the grid will show only the
internal sources. In other words the grid will automatically show either entry sources OR
internal sources, but not both together.

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 Give-way and Conflicts.


Movements, each of which may have their own set of conflicts, are set up via the main
Conflicts tab.

The Flares tab allows access to the old-style (TRANSYT 13 or earlier) quick flares. To add a
quick flare for the current link, right-click in a row-header (the grey area on the left of any row)
and click on Add New Flare in the drop-down menu that appears.
We recommend that flares are specified using the new technique (i.e. using CPDM
links) unless the intention is to use the Quick PDM traffic model which requires
you to use Quick flares to model flares.

Page 130


Shared links can be set up using the Shared-stoplines tab.

Results for each individual link can also be examined using the Results tab.


(Traffic) Streams Data Screen 8.6
Although all Traffic Streams data is available via the Data Outline and Data Editor, commonly
needed data is also available via a Traffic Streams Data Screen, which you can access via the
button on the main vertical toolbar or the main View menu.
any other window in TRANSYT. You can also lock the screen to a particular traffic stream.
Select the traffic stream to view using the list on the left hand side, or via the Data Outline, or
via NetCon. You can also use this screen to add/delete traffic streams.
Each of the data grids in this screen (for sources, give-way conflicts, etc.) works in exactly the
same as any other Data Grid, including the ability to add/delete columns and rows.

There are no particular differences between using this screen or the data editor to enter and edit
traffic stream data, i.e. unlike the Signals Data screen there are no unique function buttons.
However, you may find is easier to specify data using this screen, and in particular give-way
data.
Page 132


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 Give-way and Conflicts.
Movements, each of which may have their own set of conflicts, are set up via the main
Conflicts tab.
Please see the relevant sections of this user guide for details of the various data items.

Network Construction Editor (NetCon) Page 133

Network Construction Editor (NetCon) 9
In TRANSYT you can show one or more NetCon windows, 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 NetCon window by clicking the NetCon button on the main
vertical toolbar.
NetCon can be used to build a network from scratch because it lets you add, delete and
connect traffic nodes, links and other items.
The NetCon layout is saved automatically as part of the main data file - there is no need to
manage separate files
Much of NetCon 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 horizontal toolbar control the view of the network and turn on and off
various overlay tools and other features. The icons in the vertical toolbar represent a set of
tools which you can use to add and connect network items. The colours used for links
correspond to the colours used in the toolbox on the left hand side.
You can check what each icon does by hovering the mouse over the item and checking
the status bar at the bottom of the NetCon screen.
Shared minor links are shown with dashed lines; bus and tram links are shown with dotted lines.
Pedestrian links are shown with a large open arrow at one end (and optionally with reversed
arrows at both ends). The blue cones around traffic nodes indicate which links are providing the
traffic that travels through the traffic node. The green cones around controller streams indicate
which links or TS it is controlling. Automatically, traffic nodes that are signalised have a solid
outline, while unsignalled junctions have a dotted outline.
By default, each link or TS, also shows its total flow, and its degree of saturation (assuming that
the file has been run at least once).

Page 134


Speed of operation 9.1
NetCon 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 NetCon is more responsive if you close down any
other screens that you are not using, including the Data Editor.
Moving around the network 9.2
The diagram will automatically re-size to fit the window when you resize the window, or, you can
click on the Fit To Window button.
Use the Zoom 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 wheel.
Use the Pan mode to move around the network, or use the scroll bars and/or arrow keys on your
keyboard. Alternatively, you can hold-down the mouse wheel and pan without having to switch
to Pan mode at all.
To focus on a particular node or link, right-click in a blank area and select View>Go To
Node/Link.

Saving, using and managing Views 9.3
Often it is useful to be able to look at exactly the same View of a Network as someone else. To
this end, NetCon allows you to save NetCon Views within your TRANSYT file. To save a view,
firstly arrange your view of your network in NetCon and right-click on the background and select
Store View. You can give the view a name up to 50 characters long.

The right-click option Available Views allows you to select one of your stored views.
The menu option Manage View brings up a screen which allows you to individually set views to
be included in TRANSYTs report.

The Is Default option allows one particular view to be defined as the view which is displayed
when NetCon is opened. The Landscape option can be ignored as it is currently not used by
TRANSYT.
Printing, copying and exporting 9.4
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 then manoeuvre and zoom the network so
that the desired portion fits inside this outline. Pressing the Print button will then print out the
same area.
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.
Page 136

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 9.3 on how multiple views of your network can be stored, selected and also included
in a TRANSYT report.
Representation of Links, Lanes and Stop Lines 9.5
link:

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

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.

Moving Lanes between Controller Streams and Arms 9.5.1
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.
Page 138

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.
Shaping traffic streams, links 9.5.2
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.
Manipulating items 9.6
Selecting items 9.6.1
Simply click on any item in the diagram (traffic nodes, links, sources, etc.) to select it. It will
be shown with orange highlighting and any other relevant data screens (e.g. Data Editor, Data
Grids) will update to show data for this item, if appropriate.
To select multiple items, hold down the CTRL key.
To select a rectangular selection of items, use the Rectangular Selection Mode button and drag a
rectangle on the diagram.
Moving items 9.6.2
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.
As you move a traffic node, you will notice that all connecting links 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.
Similarly, as you move entry links via their outermost bend-handle, you will notice that they
pivot around their controlling node. 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 rotation is carried out around the first point that you click on in this mode;
drag the mouse to control the amount of rotation.
To revert to a previous layout, use the Undo/Redo buttons together with the Save NetCon state
in the main application Edit menu or toolbar.
Aligning to a grid 9.6.3
Turn on the Show Grid mode 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
View>Align Now.
Adjusting spacing 9.6.4
The spacing between all nodes and links can be adjusted by right-clicking in a blank area and
selecting Tools>Adjust Network>Link/Arm 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.
Changing properties of items 9.6.5
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.
Note that in some cases you will need to use the Data Outline to access exactly the item or sub-
item that you need.
If the Links Data screen or Signals Data screen are visible, then they will update to show data
for the currently selected controller stream/link, as does the Data Editor.
Adding and deleting items 9.6.6
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.
Page 140


You can also add items by using the toolbox on the left of the NetCon window. 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 icon and then click anywhere in the diagram to add the node to
the network. Unlike TRANSYT 13, you do not need to choose a node type now that the
controller stream is a separate network item.
- Drag the traffic node icon onto the diagram to add a traffic node
- Click on one of the link or arm icons (signalled, give-way, unrestricted exit, etc.) and then
click anywhere in the diagram to add an item of that type. Each mouse click will add one
link/arm section (i.e. a new bend for the link/arm), until you right-click. To add a
straight link, click once to set the start point, again to set the end point, and then right-
click. You can also finish the link/arm using the middle mouse button, which has the
effect of staying in link/arm-adding mode, so that you can easily add further links/arms
of the same type.
- Drag any of the link icons onto the diagram to add a link of that type (you will then need
to reposition it)
- NB you do not need to necessarily use the different link or arm icons: you can use any
link/arm icon and then right-click on the newly added link/arm 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.
Depending on options you select in the User Preferences screen, NetCon may prompt
you to enter an item ID each time you add a new item.
Merging Library Files into your network 9.6.7
You can merge Library Files into your existing network via the Insert Library File button on the
vertical 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.
Connecting items 9.6.8
Use the Connect Items mode to connect items in the following ways:
- Click on a link, lane or TS and then click on a traffic node to set that node as the traffic
node for that item. If the link, lane or TS is already connected to a traffic node, the new
node will replace the old node.
- Click on a link, lane or TS and then click on a controller stream to set that controller
stream as the controller stream controlling that item. If the link, lane or TS 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 or TS 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 link/traffic stream to set that link/traffic stream as
an Entry for that particular Location. Click on a link/traffic stream and then click on a
Location to set that link/ traffic stream as an Exit for that particular Location. Note how
the order in which you attach the link/traffic stream or location determines whether or
not the link/traffic stream is defined as an entry or exit for the selected Location.
Use the Share Links mode 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.
Shaping (source) connectors 9.6.9
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 Source - The connector is automatically split into a number
Page 142

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 Source right-click option. Individual sections can be
added and deleted using the right-click menu, and the individual bend handles can each be
manipulated to form whatever shape is required.
To quickly recurve all source connectors in the network, right-click in NetCon 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.

Adding labels 9.6.10
You can add textual annotations to the diagram via the Add Label mode. 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.
Viewing and visualising data in NetCon 9.7
The toolbar at the top of the NetCon window provides access to a number of extra modes and
menus where you can turn on various features and visualisations. In general, the key at the
bottom of the diagram indicates which options are switched on.
Signal states 9.7.1
Use this icon to display actual signal states for each link or TS, 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.

Optionally (and by default), the current stage running at each controller stream is shown
underneath the controller stream number in brackets.

You may wish to use this in conjunction with the Timings Diagram and/or Stage Sequence
screen so that you can see the signal plan for one or more controller stream at the same time,
as in the screenshot below.

Page 144

Signal stages can now 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.
Animated Arrows 9.7.2
This mode is useful to check the directions of links or TS and also to give an overview of which
links or streams feed into which other links or streams.
Select the Show Upstreams or Show Downstreams modes and then hover the mouse pointer
over any link or TS to show yellow arrows on the upstreams or downstreams of that link or
stream.
Use the Show Effective Greens mode to show yellow arrows on any link or TS 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 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 below, link 72 at the bottom right of the diagram is showing actual red, but
the yellow arrows indicate that traffic on the link would still be crossing the stop line.


Controller streams and node cones 9.7.3
A controller stream in NetCon 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. Traffic Nodes are represented by circles.
The Traffic Node cones show coloured cones indicating the traffic node for each link or TS. The
controller stream cones, shown in a different colour, indicate which controller stream (signals) is
associated with that particular link or TS. Each link or TS traffic feeds into the traffic node, but
its signals are controlled (if relevant) by the link or TS 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 cones highlighting the connections between links.
Overlay tools 9.7.4
Use the Value Comparison Tool to show blue highlighting on each link or TS, 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 difference
between the smallest and largest values via the NetCon options screen.
Page 146


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,
NetCon will attempt to colour the blue overlay boxes according to the relative value of this data
field for each link or TS. In the example below, the value comparison tool is showing the
relative values of Stop Weighting for each link, and it is immediately obvious that the user has
entered a high (or non-zero) stop weighting for 4 links.

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 11.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 link and traffic stream. 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

Page 148


Highlighting bus/tram/pedestrian links 9.7.5
Use this tool to fade out all links in the network other than the selected link type. In this way
you can easily see where the bus/tram/pedestrian links and traffic streams are, as in the
screenshot below, where Highlight Bus Links has been chosen. To restore normal appearance,
select Turn off Highlighting.

Showing link lengths, queues, flows and CTM data 9.7.6
A variety of tools are available via this menu for the visualisation of link and traffic stream
lengths, queues and CTM data. To show queues, you must have run the file at least once, and

PDM and/or CTM data must be available. 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 NetCon
Options screen.

Link/Traffic Stream Length Display 9.7.6.1
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 links are 100m long. Link 10 has been stretched to be longer
than its real length so the yellow bars stop short of the ends of the link, and finishes with a
dotted extension line. Link x11 is too short, indicated by the yellow bar showing a thicker
section at one end. When the links are positioned correctly, the lengths of the yellow bars will
exactly fit the links, as in the case of Link 11.
Scale Ruler (and changing the scale of your network) 9.7.6.2
A scale ruler can be displayed or hidden using its NetCon menu button. 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 NetCon, 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 NetCon scale to that of the
background.
Once your network is adapted to fit your diagram, the Link Lengths view can be used to quickly
check to see if youve forgotten to enter any of your link (or TS) lengths.
Page 150


Mean Max Queues (MMQ) 9.7.6.3
In this mode orange bars are overlaid on each link or TS to indicate the mean max queue. The
queue is shown as a proportion of the link or TS 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 link or TS 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.



Uniform Queues (PDM) 9.7.6.4
In this mode red and green bars are used to show the uniform component of the queue on each
PDM link (or TS). 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 on each link or TS represent stationary queues, which will tend to build up when
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. The
green part of the bar can therefore be thought of as representing moving traffic. In other words,
the red bars show where the front and back of queue are located.
The PDM uniform queue animation exactly matches the data shown in PDM Queue Graphs.

PDM Cell Flows 9.7.6.5
This mode (activated using the PDM/CTM Cell Flows option) shows the flow rate along every link
(or TS) for the current point in the cycle time, as set via the Animation Controls screen.
The link or stream is split into a number sections N.B. the PDM model does not have cells as
the CTM has. One obvious difference between this animation and that of CTM cells is that you
are likely to spot traffic disappearing at the stop line rather than joining 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 cyan block is proportional to the flow at that point along the link. (Control the
width scaling of the blocks via the NetCon Options screen.) Larger blocks show where the
highest flows occur at the current point in the cycle. They will be largest on links and traffic
Page 152

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.
Despite the rather unrealistic nature of this output, it can assist in the interpretation of traffic
flow through complex junctions and larger networks.

Uniform Queues (CTM) 9.7.6.6
For CTM links (or TS), this mode shows CTM average queues using yellow blocks which can be
animated via the Animation Controls screen. These represent a summation of any queues that
occur throughout the link or TS.
Note that the PDM queue bars show both the length and the front and back of queues for PDM
links or TS, while the CTM queue bars represent only the length of queues (always shown at the
stop line of each link or TS), not the location of the front and back of queues. You can see the
information on position of queues by using the CTM Cell Queues option.


CTM Cell Occupancy 9.7.6.7
For CTM links (or TS), this mode shows CTM 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 the NetCon
Options screen.)
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.
In the screenshot below, the link at Node 3 from the south is a pedestrian link. Because of the
way cell occupancy is calculated, this link appears to have a very large occupancy in its cell
closest to the stop line. This is because the maximum occupancy of each cell is proportional to
the link or TS saturation flow, and the pedestrian link has an arbitrarily high saturation flow. Of
course it is questionable to considerable what cell occupancy represents in the case of
pedestrians, but, you can interpret it as showing a large pool of pedestrians waiting at the
crossing point which is intuitively true, since pedestrians do not generally wait in line back
from the crossing point. The same would be true of any stream of traffic with a large saturation
flow; and conversely for a stream with a very low 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
link or TS, you will notice the difference between the width of a full cell at the stop line compared
with the rest of the CTM cells.
Page 154


CTM Cell Flows 9.7.6.8
This mode (activated using the PDM/CTM Cell Flows option) shows CTM cell flows at each cell in
each CTM link or TS for the current point in the cycle time as set via the Animation Controls
screen. The width of each cyan block is proportional to the occupancy of that cell. (Control the
width scaling of the blocks via the NetCon Options screen.)
Larger blocks show where the highest flows occur at the current point in the cycle. They will be
largest on links or TS with the highest flows, and at times where these links or TS are
discharging the maximum amount of traffic, e.g. when a queue begins to dissipate.


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 CTM/PDM Cell Flow Arrows,
which will use arrows for flows instead of blocks. In the screenshot below signal states are also
shown and the diagram clearly shows the location of traffic, the signal states shown to traffic at
the stop line and the areas of heaviest flow. Note that flows are shown at the upstream ends of
links or TS on red up until the point where queuing traffic begins, at which point the flows
diminish to zero.

Page 156

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

Other toolbar buttons 9.8
Use Show/Hide Background/Diagram to choose 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.
Use Fast Mode to turn off certain textual items to increase the drawing speed.

Other buttons on the main toolbar at the top of the NetCon window let you choose whether to
display bend-handles, connectors, show stop lines (see section 9.5) and to turn on and off a
layout grid.

The screenshot below shows the effect of turning these items off and choosing a larger
connector arrow size via the NetCon Options screen.
Stop lines of signalled links are represented by black square brackets, located at the
downstream end of each link.


NetCon Options screen 9.9
There are a large number of options controlling the appearance of NetCon, and you can access
these via the NetCon Options screen. (Use the icon on the right-hand side of the main toolbar or
right-click in NetCon and select Tools>Options).
Most items are self-explanatory and are not listed here other than the ones of particular interest
below. Most tabs have a Defaults button, which will restore the options on that tab to their
default values.
Most NetCon options are saved in the data file, so the same options will be used when you next
load the file.
Please also see the main TRANSYT Preferences screen for other options that may
affect NetCon.

Page 158

Setting a background image 9.9.1
Add one or more background images via the Backgrounds tab. Press the Add button and then
browse to a bitmap (bmp/gif/jpg format), which will then be placed in the middle of the NetCon
diagram. To adjust the opacity, position and size of the image, you must select it in the
list box. The image will then be shown with a red outline and red handles in NetCon, 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 links
and nodes in the TRANSYT network.
The images are embedded in the main TRANSYT data file; there is no need to save the image
files separately.



Showing textual data 9.9.2
Multiple Text Sets can be defined to store user preferences for displaying text on
traffic streams and links using the Texts tab. A single Default Layout is already set
up in TRANSYT in any new file. This can be adapted or other sets can be added to it.
Buttons are provided to add, delete and rename sets.
Within each set, settings for both link text and traffic stream text are defined. Sub tabs are used
to set the data items separately for links and traffic streams. 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 Enabled box 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.
Page 160


Changing the foreground and background colour 9.9.3
The foreground and background colours can be changed via the Other tab of the NetCon Options
screen. A dark background and a light foreground can be useful for high visibility visualisations.


Other NetCon Features 9.10
- Use user arrows on each link or TS to show turning proportions without necessarily
having to set up actual connectors or exit links. Right-click on the link or TS and select
from a left, straight or right user movement. The movement will be depicted using a blue
arrow at the stop line.
- You can show two or more NetCon windows at the same time, using one for an overview
of the network, and one as for close-ups of individual nodes.
- There are options in the User Preferences screen to control the way that directions for
arrows are calculated.
- If you have dual monitor display, either right-click in a blank area of the network and un-
select Tools>Keep NetCon Inside Application Window each time you open NetCon, or set
your preference via the main Preferences screen. The NetCon window will then become
detached from the main TRANSYT window and you can position it on the secondary
monitor.

Page 162


Working with Analysis Sets, Demand Sets and Time Segments Page 163

Working with Analysis Sets, Demand Sets 10
and Time Segments
NOTE: The system of Analysis Sets and Demand Sets used in TRANSYT 14, 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. 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 164

Analysis Sets 10.1.1
When you start a new file, the file contains a single Analysis Set. 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 you can store multiple Analysis Sets within one file, only one set of
results is stored at any one time, representing the results from one Analysis Set.
To run different Analysis Sets, you must select each in turn via the Analysis Set
drop-down menu and run it 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 main 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.


Demand Sets 10.1.2
When you start a new file, the file contains a single Demand Set. You can rename it by locating
it in the Demand Sets section of the Data Outline and then using the Data Editor to set its
properties.

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 166

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.)
The Total Flow and Uniform Flow for each link can then be entered separately for each Demand
Set, using the Data Editor and/or Data Grids.

Locking Analysis and Demand Sets 10.1.3
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 Flow Allocation Tool: 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.


Time Segments 10.1.4
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 specified only on entry links which allow flows to propagate
through the network. (See section 11.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 168

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 169

Working with Traffic Flows 11
In TRANSYT, traffic flows can be entered by using the Data Editor and/or Data Grids, as with
most other data items. Alternatively the Flow Allocation Tool can be used to automatically
assign flows to links or TS. 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 11.3.

Traffic streams flows MUST be assigned using the Flow Allocation Tool.

If Link N (or Traffic Stream N) is fed by other links or TS, then it has one or more sources. (In
TRANSYT 12 and earlier these were referred to as upstream links). If Link (or TS) N is fed by
no other links (or TS) then it is an entry link (or entry traffic stream) 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 source.
A default source shows slightly different data compared to a normal source for example, entry
links can have a time-varying profile attached, and this is entered using the default source data
item.
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 NetCon 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 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 170


Entry profiles 11.1.1
Entry links can have a time-varying traffic profile attached, which will propagate through the
network when the TRANSYT model is run. To use time-varying profiles, you must set up the
Network Timings options so that there is more than one time segment. (See section 10.1.4)
Each entry link has a set of extra properties in its Default Source section (click on Link
n>Sources in the Data Outline) where you can set up the time-varying profile, as shown below.
Entry profiles can only be applied to links and not to traffic streams. Traffic Streams have a
FLAT profile.

By default, the Entry Profile Type is set to FLAT, and a single number appears in Entry DIRECT
Flows. This number is greyed out and is the same as the Total Flow entered in the Flows section
for the Link.

Changing Entry Profile Type to GAUSSIAN will take the Total Flow as the flow for the central
time segment and will then 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, choose DIRECT as the profile type. The Entry DIRECT Flows box
will then be editable and you can enter a flow for each time segment using commas to separate
the values.
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.
Flow Consistency Diagram 11.2
Launch this screen via the Flows button on the main vertical toolbar or via View>Link Flows
Consistency Diagram. Only one of these screens can be shown at any one time but it will show
details for the currently selected link or TS and update 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 link or TS, 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 NetCon or any other screen) is
Link 71, and this is shown in the centre of the diagram. Link 71 flows into Link 112, which is
shown on the right. On the left, are shown the upstream links (23, 24 and 25).
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, the user has entered a total flow of 1950 PCU/hr on link 71, which includes
240 PCU/hr as uniform flow. The total flow entering the link at its upstream end is 1950-
240=1710. The user has specified that link 71 is fed by 110, 390 and 1190 PCU/hr from links
23, 24 and 25 respectively, which totals 1690. Therefore an additional 20 PCU/hr must be
entering link 71 from somewhere, and this is shown at the foot of the diagram. (A similar
calculation is performed for traffic leaving the link.)
Page 172

TRANSYT scales the upstream flows so that the total matches the total entered flow on link 71.
These scaled numbers are shown in brackets (111+395+1204=1710).
In the screenshot, link 71 is fed by link 23, which has a total flow of 1200, 110 of which feeds
link 71. This block in the diagram is shown in amber, which indicates that there may be a
problem with link 23. Click on the amber block and the diagram will update to show data for
Link 23, as shown below.

You can now see that Link 23 has a specified flow of 1200 PCU/hr, and that it has no
downstream links other than Link 71. The user has specified that 110 PCU/hr flows from Link 23
to Link 71, which internally will be scaled to 111 PCU/hr by TRANSYT. Therefore the rest of the
traffic (1200-111=1089) must be leaving the network. This may be genuine, but the screen
highlights this in amber in case you have made a mistake with flow entries.
Such warnings are 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 NetCon, by selecting Flow Consistency Tool
from the overlay bars button.


Page 174

Flow Allocation Tool 11.3
The Flow Allocation Tool (Tools>Flow Allocation Tool) 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 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 11-1 A highlighted Flow Allocation Tool path
The Flow Allocation Tool makes use of a number of network/Netcon items 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 (when the
Flow Allocation Tool is being used.)
- A Path defines the continuous route within a section of the network related to an
OD Matrix. Each path starts at a location and ends at a location. Therefore, a TRANSYT
path is a defined sequence of links between an OD pair (i.e. between one origin and one
destination Location). It contains only links that are consistent, i.e. each item is
downstream of the previous item. When using traffic streams instead of links an
underlying equivalent (hidden) structure 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).
Local OD Matrices, locations and paths 11.3.1
OD matrices and locations are created in a similar way to creating links, arms and controller
streams. This is described in section 9.6.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 Flow Allocation Tool 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
Page 176

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 11-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 11.3.4 for an explanation of the allocation options that can affect the
generation of paths.
WIDE-AREA OD Matrices 11.3.2
WIDE-AREA OD matrices are created in a similar way to ordinary OD Matrices. See section
11.3.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


Allocation Mode 11.3.3
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 11.3.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.
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
11.3.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 21.15 for more detail on the Assignment model.
The allocation modes provided simply aids 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 suitable and in such situations users
have the freedom to specify flows in a more direct manner.
Flow allocation options 11.3.4
The Flow Allocation Tool has a number of other user options for matrices These are set from
the Local Matrix tab or 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.

Page 178

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 11-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 11-3 Allow looped paths on traffic nodes

Figure 11-4 Locations (for links and traffic streams)

To check that the created paths are OK the easiest way is to select each path in turn and
examine the Netcon diagram which will highlight all of the links of the selected path. A Data
Grid can also be used to examine and filter data associated with OD Matrices, Locations and
Paths.
Validation of the specified Flow Allocation Tool 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 Flow Allocation Tool.
Typical order of construction 11.3.5
The Flow Allocation Tool 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
the flow Allocation Tool:
Creating the model:
1) Create your network structure (e.g. traffic streams, links, traffic nodes and controller
streams (e.g. using NetCon) in the usual way, if it does not already exist
2) Specify the Traffic Type for each traffic stream and Source Traffic Type of each link.
3) Add a Local OD-Matrix by dragging it from NetCons vertical 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 links 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 the LTS, so should still be set appropriately.
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

Page 180

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 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.
10) Set the required Allocation Types of each path (see section Error! Reference source
ot found.). Leaving a path as Normal will leave the Flow Allocation Tool 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).
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 links (or
TS). An example of the use of the Flow Allocation Tool on a signalised roundabout can be seen
in chapter 24.


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 NetCons vertical toolbar. Wide-Area
matrices are shown in NetCon 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 NetCon 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)

WIDE-AREA Location Local Location

Page 182

15) Specify your Wide-Area OD Flows (see the section 11.3.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 Flow
Allocation Tools Assign from Wide-Area Matrix button.
Specifying Local OD Flows 11.3.6
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 11.3.7.
Flows are specified by filling in the Entry Flows matrices for normal traffic, buses and trams.
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.
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 11-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
Flow Allocation Tool 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
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.
N.B. 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 11-6 Path Allocation Type
After allocating the flows to 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 assigned 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 184


Figure 11-7 Resultant Flows
Flow Allocation Types Example 11.3.6.1
This figures shown here display how Fixed Flow, Percentage Flow and Normal Allocation each
work in a simple case.

Figure 11-8 Simplest OD Matrix

A single flow of 500 is specified from location 1 to location 2.

Figure 11-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 example is Path Equalisation


Figure 11-10 NetCon 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 the Flow Allocation Tool on a signalised roundabout can be seen in
chapter 24.
Specifying Wide-area OD Flows 11.3.7
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 186


Figure 11-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 11-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.
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.
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.
Multiple Local OD Matrices and Demand Sets 11.3.8
The Flow Allocation Tool 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.
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 TS) of one is an entry link (or TS) of the other. This
will generate an error on the task list. Either the doubly-referenced links
(or TS) should be split with unrestricted links (or TS) to avoid an overlap
between the two OD matrices or a single combined OD matrix used for
both junctions.

Page 188

However, 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.
Connecting the network at Local OD Matrix boundaries 11.3.8.1
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 11.3.8.2
should also be read, as an additional consideration applies in this case.

Figure 11-13 Adjoined matrices This is OK and recommended.

Figure 11-14 Adjoined matrices OK too, but see wide-area OD considerations



Figure 11-15 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 definitely be
avoided.
Connecting the network at WIDE-AREA OD Matrix boundaries 11.3.8.2
The part of the network defined within a wide-area should not be within any other wide-area
matrices, i.e. no overlaps. All of the 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
exist an inconsistency between the wide-area matrix and the flows within the network.
An additional consideration also applies when connecting local OD matrices to each other:
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 11-16) 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 11-17.
Page 190


Figure 11-16 Local OD boundary

Figure 11-17 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
11-18. 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 11-18 Alternative local OD boundaries


Normal, Bus and Tram Data 11.3.9
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 11-19 Normal, Bus and Tram Data

Before specify traffic flows within the OD Matrix for each of the traffic type, the relevant traffic
streams must be defined as carrying buses or trams. By default all new traffic streams 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
11-20). All combinations of Normal, Bus and Tram are allowed.
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 11-19 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.
Page 192


Figure 11-20 Traffic Steam: Traffic Type

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 > 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).
Journey Times 11.3.10
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 Flow Allocation Tool. Selecting
the Use For Point to Point Table OD Matrix option will result in an additional Journey Time table
appearing in the Report. Journey times are provided for all vehicles combined and also
separately for normal traffic, buses and trams.
When the auto-calculate option is used, the OD Journey Times calculated will be the flow-
weighted average of all path journey times between each pair of origins and destinations. A
path journey time is the sum of the link (or TS) journey time for links on the path.


Figure 11-21 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.
Additional features 11.3.11
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>Routes>Convert Path to Route can be used to convert the currently selected Path into a
TRANSYT Route. This then gives access to the Collection and Routes-based results in the
Report.

Page 194


Working with Traffic Signals Page 195

Working with Traffic Signals 12
Introduction to traffic signals in TRANSYT 14 12.1
This section briefly describes some important points to be aware of when working with signals in
TRANSYT 14, especially for users who may be used to earlier versions such as TRANSYT 12 or
TRANSYT 13. 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.
We recommend using the Timings Diagram and accessing stages and link green periods by
clicking and double-clicking on the relevant part of the diagram. The signals data screen (see
8.4) is also particularly useful for setting up signal timings quickly and easily.
Signals representation 12.1.1
TRANSYT 14 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
14. However, the Timings Diagram provides 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 14 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 12.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
Page 196

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.

Actual / effective greens 12.1.2
In TRANSYT, actual greens and effective greens are explicitly shown as separate values,
wherever possible. (In TRANSYT 12, lags were often used to represent both actual timing lags,
and positive/negative bonus greens, and could therefore be ambiguous.) 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.


Dummy Phases and Dummy Links 12.1.3
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.
Dummy Phases 12.1.3.1
You can define any Phase as a Dummy Phase (Outline: Controller steam n>Phases>Phase n).
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.

Page 198

Global vs relative start/end displacements 12.1.4
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.
Controller Streams 12.1.5
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. The controller stream is a replacement for the TRANSYT 13
signal node which no longer exists in TRANSYT 14.
Stage Library 12.1.6
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
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.
Stage Sequences 12.1.7
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 12.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 12.5.
The nominal first stage in the current stage sequence is indicated by a + sign next to the
sequence.

Stage numbering 12.1.8
Like many items, stages have IDs. There is no longer any distinction between display ID
and index ID as there was in TRANSYT 13. 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.
Base / non-base stages 12.1.9
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.
Page 200


Full optimisation vs evaluation mode 12.1.10
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 set
Optimisation Level = None and turn off Auto Redistribute.

To optimise timings, set Optimisation Type to an option other than None. If you turn on Auto
Distribute then TRANSYT will also calculate an initial set of timings which it will then
subsequently optimise, as opposed to only 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.
During optimisation TRANSYT does not attempt to calculate the actual stage order
or which 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.
Common errors 12.1.11
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.)
Overview of Signal Timings 12.2
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.
Timings with and without phase intergreens or phase delays 12.2.1
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.

Page 202


The timings shown below could exist in TRANSYT 13, but will never be seen in TRANSYT 14.

In TRANSYT 14 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.
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 0-36s; Stage 2 runs from 46-88s.
- 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 now stores phase gaining and losing delays explicitly in the data file (unlike
TRANSYT 13). This allows them to be created, deleted and edited both graphically and
Page 204

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.

If phase B is now adjusted to start at 51s, 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.
Running multiple-cycled nodes 12.2.2
If the controller stream in this example is specified as being double-cycled (via the Data Outline;
Controller Stream>Multiple cycling), the timings could look like this.


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.
Stage parameters 12.2.3
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)
Page 206


- Stage Ends are filled in automatically as you move the stages around using the Timings
Diagram, but you can also, if you wish, directly enter when each stage ends. This is part
of the Stage Sequence Data (as shown).
- Stage 1 ends at 18 seconds and stage 2 at 60 seconds. Stage start times are dictated too
/ defined by the intergreens and phase delays.
- Internally TRANSYT keeps track of a number of stage data. This is presented in 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 those more familiar with previous
versions of TRANSYT as most of the derived values will be familiar.
Resultant Stage Data that use TRANSYT 12 definitions are prefixed with
TRANSYT e.g. TRANSYT Stage Start. Data parameters that use newer
definitions have no prefix e.g. Stage Start.

- 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, as well as the
TRANSYT stage start. When doing this is can be useful to use a data grid and to also
have the Timings Diagram open at the same time so that you can see the changes
graphically as you make them.



- TRANSYT has calculated that the Stage Minimum for Stage 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 via the User
Stage Minimum box. 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.
- TRANSYT has calculated that Stage 1 has a TRANSYT Minimum Preceding Interstage
of 5s. 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.
- Stage 1 also 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.
You can also use the Signals Data screen to conveniently view, edit, add and delete stages,
phases, phase delays and stage sequences at any controller stream:
Page 208


Phase parameters 12.2.4
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 is 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 for yourself.

- Phase A has only one green period in this example. It runs from 65s - 18s. 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.

- TRANSYT Starting/Ending Stage, TRANSYT Start Lag and TRANSYT Minimum
Start Lag are retained only for reference and you may choose to ignore these values.
- Phase As TRANSYT Minimum Start Lag is computed as 5s. This means that Phase A
could start as soon as 5s after the previous stage ends (given phase-losing delays and
intergreens etc.). Normally, after optimising timings, the minimum start lag and the
actual start lag will be the same.
Stage definitions using Phase Mode 12.2.5
The Link 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 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 210

Timings Diagram 12.3
The Timings Diagram illustrates the timings for each phase and shows the stages that each
phase runs in. It also shows which links (or TS) are controlled by which phases.
Furthermore, it illustrates many other important points about the way phases and stages fit
together and is the main way in TRANSYT of visualising the timings at each controller stream. It
can be used in conjunction with the Intergreen Matrix and Stage Sequence screens.
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 either Stage
Mode (the default) and Phase Mode. In Stage Mode stages cannot be created or deleted,
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.

Menu Items 12.3.1
Appearance>show effective greens: this shows the effective greens as a lighter green above the
actual green. It is on by default.

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 212


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 link or TS (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 links (or TS) the phase is controlling. 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: Once the interstage
design has been completed on the Timings Diagram, selecting this option will update the
intergreen matrix with phases that conflict (or at least appear to conflict from what has been
entered in the Signals form). It is a one-shot option and would need to be selected again if the
intergreen matrix needed re-calculating after a change.
Before: After:

Tools>calculate link intergreens from phase timings>conflicts and timings: Once the interstage
design has been completed on the Timings Diagram selecting this option will update the
intergreen matrix both with phases that conflict (or at least appear to conflict from what has
been entered in the Signals form) and the times as deduced from the form. It is a one-shot
option and would need to be selected again if the intergreen matrix needed re-calculating after a
change. Below is the same matrix as immediately above, but including values:
Page 214


N.B. the timing 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>EQUISAT>This controller and Tools>EQUISAT>All controllers: Applies the EQUISAT
routine to the signal timings for the current controller stream or for all controller streams in the
network. This routine is no longer required (use Redistribute option instead) but is retained here
for backward compatibility.
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.
Manipulating items 12.3.2
In Stage mode:
stages cannot be created or deleted 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
Page 216

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

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


Entering signals data 12.3.3
The various options listed above are available so that the user can manipulate the phases,
intergreens, and stage data as she/he feels 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
NetCon): This method is described in a sub-section of part of the manual covering the use of
the Signals Data Screen see section 8.4. This is likely to be your preferred method.
The second uses a mixture of the Signals Data screen, intergreen matrix and NetCon
as follows:
1. Create your new controller stream, if needed, either in NetCon or via the Add a new
Controller Stream button on the data outline.
2. In Netcon associate the traffic streams with the new controller using the connector tool.
3. Double-click the Controller Stream to bring up a 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 NetCon. 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
Page 218

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 link or TS.
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.
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.
Control of two traffic nodes using a single controller stream 12.3.4
When there are two traffic nodes 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
the green cones illustrate the fact that arms 2, 4 and 6 are controlled by node 1, despite being
attached to node 2.


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.
Using the Timings Diagram with the clipboard 12.3.5
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 14, then an easy way is to enter them in e.g. Microsoft Excel, and then use the
Clipboard>Paste Link Timings option. TRANSYT 14 will calculate the corresponding stage
timings.

For example, the timings above give the below when the clipboard option is used:

Page 220

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

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.
Intergreen Matrix Screen 12.4
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.

Intergreens 12.4.1

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.
Phase intergreens can be visualised in the Timings Diagram:

You can also use the Timings Diagram to generate a set of phase intergreens, based on the
current phase timings. 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.
Use 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.
Page 222


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.

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

Banned stage changes 12.4.3
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 224


Using Clearance Times and Amber Times 12.4.4
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 >
Phase n).


Stage Sequence Screen 12.5
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.
Defining which phases run in each stage 12.5.1
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.

Re-arranging stage sequences 12.5.2
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).

Page 226

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.

Showing banned stage changes 12.5.3
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 2 to 1 is banned,
and also from stage 8 to 9 and 9 to 8.


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.
Options and Tools 12.5.4
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.
Phase Delays 12.6
Phase delays are shown in the Data Outline as part of the relevant controller streams data. The
diagram below illustrates losing and gaining delays.

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
Relative phase
gaining delay = 2 s
Where Phase B would normally start
Absolute phase
gaining delay = 8 s
2 seconds
Intergreen A to B = 6 seconds
Phase B
End of Stage 1
Start of Stage 2
Phase A
Stage 1 to 2 = 10 seconds
Phase losing
delay = 3 s
Page 228

Start/end displacements 12.7
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.

Working with priority junctions Page 229

Working with Priority Junctions 13
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 21.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 21.5 as well. Section 13.9 provides the additional
information specific to the modelling of unsignalised roundabouts in TRANSYT.
In TRANSYT, for the first time 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. Also, for the first time in TRANSYT
the new 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 14, which can be supplemented by files
users wish to store as additional library files. A priority T-junction with full
movements and conflicts is 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 13-1 Example priority T-junction

Page 230

Figure 13-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.
What is a Priority Object? 13.1
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 21.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.
A crossroad object is not yet available in TRANSYT, however a fully specified library file is
provided. 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 a T-Junction 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 > Licence Manager.



Figure 13-2 T-junction using a Priority Object
Using a Priority Object library file 13.2
Figure 13-2 shows the lane and traffic stream network structure of the simple T-junction (Figure
13-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 NetCon if not already open

2. Click on the Insert Library File button on NetCons vertical toolbar and then click on the
Netcon diagram where you wish the new file contents to be deposited. This will bring up
a list of available Library Files.

3. From the list, select one of the files indicated as containing a T-junction Priority object,
and click OPEN.

4. Select the default prefixes or re-enter your own arm IDs and traffic stream IDs must be
unique within the network, and click MERGE. The contents of the file will be deposited at
the chosen location.

5. Connect the external traffic streams to the rest of the network (if required).

Page 232

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
13-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 13-3 Geometric Data for a T-junction
7. Double-click on the OD Matrix in NetCon and add your OD flows. The flows entered will
be assigned automatically to the traffic streams. Use the Flow Allocation Tool to control
how the flows are assigned to the network. Details on how to use the Flow Allocation
Tool is in section 11.3

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 .T14 file, but can also be
saved as a new library file if you wish.

Applying a T-Junction Priority Object to an existing 13.3
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 NetCon 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 13-5). In either case the names of the items make use of an approach naming
convention copied from ARCADY and PICADY The names of each of the approaches to the
junction are as shown in Figure 13-4Error! Reference source not found. and Figure 13-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.
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 13-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
case you will not want to rename existing traffic streams in your network. This example also
illustrates the need to reference the same traffic stream twice if it carries traffic making both
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 13-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 13.3.1.

Figure 13-4 Priority Object Link names (Drive-on-the-left)

Page 234


Figure 13-5 Matching up Priority Object to links or traffic streams

Figure 13-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 21.5 or read the
relevant sections of an ARCADY or PICADY User Guide.
Modelling one-way traffic 13.3.1
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 13-7 and Figure 13-8).

Figure 13-7 Priority object - Exit only on Arm A

Figure 13-8 Arm B to Arm C movement has no conflicts
Page 236

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.
Modelling banned movements 13.3.2
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 13-9).

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


Using an Arm, Traffic Stream and Lane Structure 13.4
Figure 13-12 shows the standard arms, lanes and traffic streams needed to model a basic T-
junction. The yellow pentagons shown are two of the Flow Allocation Tool 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 TRANSYTs Flow Allocation Tool
to specify your traffic flows in and out of the priority junction. A link structure can be used
instead and is described in 13.8 (Using Links to define your priority junction).

Figure 13-10 Network structure using arms, traffic streams and lanes
Steps required using arms, traffic streams and lanes 13.5
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
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 Netcon items to the diagram, you will
move them around to look like the sample diagrams.
1. Using Netcon, 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 the Flow Allocation Tool. For our example you
will need six arms in total.

2. In NetCon, 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.

Page 238

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 NetCon) and the same for Arm C1 (Outline: Arm B1>Traffic
streams>Traffic Stream 1). The Is Signal controlled option should be de-selected as
the arm is not signalled. The exiting arms Ax and Cx will be whatever type is required by
the rest of the network, or if all the traffic on it is exiting the network it should be set as
an unrestricted traffic stream (sandy-coloured in NetCon).
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 19.3.

For Arm A1 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 B1 give-way will not use the saturation flow value so can
be left as the default. Arm C1 does not use the saturation flow value either but a give-
way max flow for the straight ahead movement (Movement Ax/1) is required. This
should be set to 1800 if you wish the results to match PICADYs as closely as possible.

6. Add an OD Matrix using NetCon: 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 Flow Allocation Tool to
control how the flows are assigned to the traffic streams. Details on how to use the Flow
Allocation Tool is in 11.3.
7. Add your Give Way Data:

By default, a give-way link will have its property Opposed Traffic set to AllTraffic
(Outline: Traffic Stream n>Give Way Data). This means that all traffic on in this traffic
stream is opposed by some other movement(s) irrespective of where it is going.
In the T-junction example not all of the main road traffic arriving from the left (Traffic
Stream C1/1) is opposed, as some is travelling straight ahead. Setting the Opposed
Traffic to Movement allows individual movements to be added, so that the different
characteristics of each movement can be defined separately as required for this example
situation. See Figure 13-19. When opposed traffic is by Movement ALL movements

must be set up, even for movements that have no conflict. Those movements that have
no conflicts should have their Percentage Opposed value set to zero.

Figure 13-11 Give Way Data
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 13.7 for an explanation of what this option does.

8. Add a T-junction Priority Object or specify your movements and conflicts. See section
13.6 on how to set up movements and conflicts. See section 13.6 on how to add a
Priority Object. Since using Priority Objects avoids the need to set up movements and
conflicts manually, it is 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 13.14. 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 appear in the
TRANSYT report

Page 240


Figure 13-12 Movements, conflicts and example conflict data
Movements and Conflicts 13.6
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 13.15 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 C1/1 needs two movements specified to traffic stream Bx/1
and to Ax/1 (see Figure 13-13). These are necessary as the straight ahead movement requires
having a high maxflow compared to that of the turning traffic. This is to reflect the fact that it is
not opposed by any traffic. In this example the opposed movement has a max flow of 715 (N.B.
this is an example value only Not a default).

Figure 13-13 Movements for Arm C1 (major left arm)
B1/1 requires movements to C1/1 and Ax/1 as again the give-way properties for each
movement are different, e.g. different conflicts and give-way coefficients.

Figure 13-14 Movements for Arm B1 (minor arm)
However, A1/1 does not require ANY movements defined as both traffic movements (to Bx/1 and
Cx/1) are modelled as having the same experience, i.e. nether give way to any other
movements. (In some countries this would not be the case, in which case separate movements
should be defined.) They CAN be specified for consistency and will not affect the model, but are
not required in this example.
Page 242

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.

Figure 13-15 Conflicts for Arm C1 (right-turn movement)



Figure 13-16 All four conflicts for Arm B1 (right-turn movement)

Figure 13-17 Conflicts for Arm B1 (left-turn movement)
The data needed to define a conflict is as follows: For a given movement, first you need to
specify the Controlling type. Since we are using arm/traffic stream/lane structures
throughout this example, the Controlling Type required will either be TrafficStreamMovement
or TrafficStream. If Traffic Stream was chosen you would need to specify the conflicting
Page 244

traffic stream and this would mean all the traffic on that named traffic stream would conflict with
the current movement. In this example we wish to specify a full model and means that we need
to specify that the different movements conflict in different ways even when all the traffic
conflicts. We therefore chose TrafficStreamMovement (see Figure 13-15, Error! Reference
ource not found. and Figure 13-18). This necessitates specifying where the conflicting
movements come from and goes to, by entering the Controlling From Traffic Stream and
Controlling To Traffic Stream values.
Percentage Opposing: You also need to indicate what percentage of this movement is
actually conflicting Often this will be 100% when using 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. This value determines the rate at which
the give-way maximum capacity (Max Flow) diminishes as the opposing traffic increases. See
21.5 if you wish to know more.
The Upstream Signals Visible defines how give-way traffic reacts to upstream signals See
13.15 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 (A1 to Bx in the example) affects the capacity of
the minor arm B1.

Visibility Adjustment 13.7
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.
Using Links to define your priority junction 13.8
This section briefly describes how to model priority junctions using a link network structure.
Alternative methods are described in earlier sections 13.2, 13.3 and 13.4. We recommend that
you read these sections too, as they contain information relevant to this method too.
Figure 13-12 show the standard links and link-shares needed to model a basic T-junction. The
yellow pentagons shown are two of the Flow Allocation Tool locations.


When using a link structure to model a T-junction you do not need to use TRANSYTs Flow
Allocation Tool 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 the Flow Allocation Tool is in section 11.3. 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 13-18 Network structure using links and link-shares
The definition of links depends on the junction being modelled. In this example the main road
left approach is modelled using a shared link that models the traffic turning into the minor road.
This structure is equivalent to what is called Full Blocking in PICADY, which is the situation
where the traffic turning blocks the straight ahead movement, hence the use of a major and
minor shared link.
If the particular layout shown is used it will produce identical results to the
example T-junction model 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-

Page 246

junction example, we do not want to do this, as the model required the properties of the
two links to be different (e.g. different conflicts), hence this option has been deselected.

Percentage Opposed: Used to define how much of the traffic on this link is yielding
to the opposing traffic. In the T-junction example, 100% of the traffic on each of the
give-way links has to give way.

The T-junction example could have been modelled with a single link instead
of links 27 and 28. In that 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 will not produce quite
the same results as before.

Figure 13-19 Link Give-way Data
Opposed By Conflict 1 only: This data item allows a percentage of traffic to be
opposed by only the first defined conflict. This option is no longer required in TRANSYT,
but has been retained for backward compatibility with previous versions. Imported files
with this option set will use this feature.

Max Flow (Opposed): This the maximum flow that can be achieved when traffic is
giving way to one or more opposing traffic streams, but when that opposing flow is zero.
N.B. this IS not the same as not giving way at all. When give-way traffic behaves as if it
is unopposed then this situation can be modelled see section 13.15 to find out how.


Max Congested Capacity: See Modelling give-way links in CTM. This item is only
relevant to the CTM model.

Use Step-wise Opposed Turn Model: This item is only relevant to opposed turns at
signalled junctions.

Visibility Restricted: See section 13.7 for an explanation of what this option does.

Modelling roundabouts 13.9
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 chapter 13 first to learn about
how to define give-ways generally and optionally section 21.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 TRANSYT 14 Priority Object (see section 13.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 13-20) 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.
The steps described in section 13.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 links (or TS) with unrestricted flow if the exiting
traffic is also leaving the network, or whatever link (or TS) type is required for modelling of the
downstream situation within the network.
For step 7 - Add your Give Way Data:
By default, a give-way link 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. This is the case here, so there no
need 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.
Page 248


Figure 13-20 Traffic Stream and Lane Structure of a roundabout
Under All Movements the Max Flow 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 13-21 Roundabout Conflicts

Each approach you will need to specify just one Conflict this conflict being a single traffic
stream (Controlling Stream = Traffic stream) representing all the traffic passing the entry.
Figure 13-21 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.
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 Tool 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.

Page 250


Figure 13-22 Roundabout Priority Object data
The Type value should be set depending on whether you are referencing traffic streams or
links.

The geometric data associated with each entry to a standard roundabout is shown in Figure
13-23. 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 13-23 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. If storing more than one signalled
copy of a roundabout please be aware that there can only be one cycle time so the timings of
both signalled roundabouts must fit within this constraint.
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.
Using Links to define your roundabout 13.10
This section briefly describes how to model roundabouts using a link network structure. An
alternative method is described in the previous section 13.9. We recommend that you read this
section too, as it contains information relevant to this method.
Figure 13-24 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 TRANSYTs Flow
Allocation Tool 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 the Flow Allocation Tool is in section 11.3. 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.

Page 252


Figure 13-24 Link Structure of a roundabout
The link structure is generally the same as that used for signalised roundabouts other than the
fact that all the circulating links will be unrestricted links, and all the entries will be give-way
links. Each path through the roundabout that exists on-street must be provided for by way of a
series of connected links. Shared links are used to represent more than one path on the same
physical road space. This use of shared links allows the traffic from different approaches to be
kept separate within the model. There are simplifications, such as using just one full link to
represent the circulating carriageway, but the model will not then be equivalent to the
alternative lane structure method, will give different results, and most importantly will not
correctly take account of platooning effects that may be present within the traffic flows.
If the roundabout is not attached to any further network containing signalled lanes
or links, circulation carriageways CAN be represented by a single link, because
there will not be any platooning of traffic within the network. If you are intending
to experiment with partial or full signalisation of the roundabout it is
recommended that you use the full link structure anyway for consistency and ease
of conversion to a signalled situation.
We also recommend that you read chapter 24 modelling signalled roundabouts in order to
ensure you fully understand the link structures required.


Mutual opposition 13.11
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.

Modelling variations of give-way 13.12
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.
T-junction with Two lanes on the minor road and no blocking of 13.12.1
straight ahead traffic by right-turners

Figure 13-25 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.
Page 254

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.

T-junction with one lane on the minor road 13.12.2
The only difference with the two-lane example is that the minor arm uses two shared links.

Figure 13-26 T-junction with one lane on minor road (using links)


T-junction with a turning bay on the main carriageway 13.12.3
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.

Figure 13-27 Partial blocking using CPDM About to block
Page 256


Figure 13-28 Partial blocking using CPDM - Blocked
New Zealand-style nearside turn give-way 13.12.4
In New Zealand traffic turning left into a minor road gives way to traffic turning right from the
main carriageway, as shown in Figure 13-29. 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.

Figure 13-29 New Zealand give-way

The right turn lane can be set as simply a restricted link or TS, 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.
UK-style nearside slip-road giving way to exiting traffic on minor 13.12.5
road.
This situation can be modelled with a few small changes to a standard T-junction library file. A
restricted link (or TS) 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
link (or TS) 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 13-30 T-junction with slip-road
Page 258


Figure 13-31 Model of T-junction with slip-road
An all conflicts defined Crossroads 13.12.6
To ensure that the effects of all movements (as modelled by PICADY) are taken account of, a
considerable number of conflicts need to be defined. Fortunately, a Library File of a fully-
defined crossroads is supplied with TRANSYT 14. This reduces the amount of effort required
considerably. All that remains is for you to merge the library file into your network and specify
the slope coefficient and max flow (PICADY intercept) for each of the already-created conflicts,
having calculated them using PICADY.

Figure 13-32 A fully-defined priority crossroads


Give-ways within signalled junctions 13.13
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 14 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 13.13.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.
Wholly opposed offside turn with no unopposed stage 13.13.1
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 13.13.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 13-33 Simple signalised T-junction with opposed offside-turn movement

Page 260

Shown in Figure 13-33 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 13.13.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 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 13.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)
7. 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 > All Movements).
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 13.13.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.


Opposed offside turn with storage in front of the stop line 13.13.2
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 13-34 Signalled opposed offside-turn movement with storage
As shown above, there is additional room for right turners to store out of the way of other traffic.
This will give additional capacity by allowing more vehicles to store before blocking the other
movements. Fortunately this is relatively easy to model in TRANSYT and the use of the supplied
Library File for this situation can speed up the modelling process.
The recommended method involves modelling the right-turn storage explicitly by adding a short
traffic stream in the middle of the junction which is long enough to store the number of PCUs
expected (see Figure 13-34). This additional lane has the right turn give way parameters. An
alternative method is described in section 13.13.2.1.
The situation requires the following to be set up:
1. The approach to the opposed turn (Arm 1) should be defined as a normal signalled traffic
stream (with a saturation flow restriction), i.e. it is NOT a give-way traffic stream.
2. An additional traffic stream (on Arm 1B) 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.
Page 262

3. Traffic Stream 1B/1 also needs to be set to use the CPDM traffic model (Traffic Stream
1B/1 > Traffic Model = CPDM) 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 1B/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 11.3.4 for the reason for this.
Older method for modelling storage in front of stop lines 13.13.2.1

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), we recommend using the recommend method in which the
storage area is explicitly modelled using its own traffic stream.


Opposed offside turn with a turn bay 13.13.3

Figure 13-35 T-junction with offside turn bay

Where a right turn bay exists, as shown in Figure 13-35, there is additional room for right turners
to store out of the way of other traffic. This will give additional capacity by allowing more vehicles
to store before blocking the other movements. This situation requires the addition of a second
traffic stream at the stop line.
Traffic Streams on Arm C1 need to be modelled with CPDM. Using a model like this allows the
blocking by right turners of the other movements to be modelled. Note that the traffic streams on
Arm C1 may need to be modelled with CTM if it is longer than about 30 metres.
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 13.13.1

Page 264

Opposed offside turn with a turn bay and storage area 13.13.4

Figure 13-36 T-junction with offside turn bay and modelled storage
Where a right turn bay exists, as shown in Figure 13-36, there is additional room for right turners
to store out of the way of other traffic. This will give additional capacity by allowing more vehicles
to store before blocking the other movements. This situation requires the addition of a second
traffic stream at the stop line and a third traffic stream to model the storage area in front of it.
Traffic Streams on Arms C1 and C2 all need to be modelled with CPDM. 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. Note that the traffic streams on Arm C1 may need to be modelled
with CTM if it is longer than about 30 metres.
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
13.13.2.


Standard two-lane situation 13.13.5
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. Versions of the program prior to TRANSYT 14 were not able to accommodate more
than one opposing traffic stream. With TRANSYT 14 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 266

Two-lane situation with a turn bay 13.13.6

Figure 13-37 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 CPDM blocking model.
Whether or not the bay can cope with the turning traffic will be taken account of by modelling the
bay area as a CPDM 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 CPDM 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 13-38 NetCon image of model showing where CPDM model is used.
Alternative method using quick flares. 13.13.6.1
Despite the ease in which this situation can now be modelled in TRANSYT 14, 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 the Congested-PDM (CPDM) 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
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 13-37) there will be some space ahead of the
point where the right turners divert into their bay. This extra space can be fully used by the
straight ahead traffic (whether they actually use the space is another matter). In many cases it
may prove difficult to find an ideal modelling solution to your problem. However, with the
application of common sense and experience it should be possible to find a solution that meets
your particular requirements.
Page 268

Using the step-wise opposed turn model 13.13.7
TRANSYT 14 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.
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:

Figure 13-39 Required step-wise opposed turn model


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 Arm X.
N.B. it has no influence during times when the opposing traffic flow is rising.
Alternative way to modelling opposed offside turns 13.13.8
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.
Give-way simplifications you can make 13.14
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.
Page 270

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

Indirect traffic control and give-way bottlenecks 13.15
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 link (or TS) 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 13-40 Specifying that upstream signals influence a give-way bottleneck

To set one up is straight-forward: Firstly you need to specify a link or TS as a give-way WITH a
restricted flow and enter both the give-way and restricted flow data. If the controlling link (or
TS) is signalled, that is all that is required. However, if the controlling link (or TS) is not itself
signalled the effect you wish to model will not operate as the controlling link (or TS) would
normally have to be signalled. However, new to TRANSYT 14, is the additional conflict option
Upstream Signals Visible (see Figure 13-40). This allows, say, a controlling link to be a
restricted or unrestricted link (or TS) 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 links (or TS) OUT-profile.

Figure 13-41 Example of near-side slip lane

Page 272

Figure 13-42 Near-side slip lane modelled in TRANSYT
If all the controlling links upstream are at red and this link has zero out flow and zero traffic on
the link then the conflict is modelled as unopposed. This means that TRANSYT assumes that
drivers can see the upstream signals and that there is no traffic between the signals and them
and will therefore cross the give-way line at the higher saturation Flow rate defined by the
restricted flow value, instead of the maxflow associated with the give-way.

Figure 13-43 OUT-profile from the give-way
The OUT-profile in Figure 13-43 clearly shows the expected three levels of out flow initially
running opposed, then discharging at saturation flow, and finally free flow (once any queue has
dissipated).

Working with Traffic Models Page 273

Working with Traffic Models 14
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.
Traffic Model selection 14.1
The selection of the traffic model for each link or TS 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 20 (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 link or TS (Outline: Arm n > Traffic Streams > Traffic
Stream n > Modelling > Advanced).

The Link or Traffic Stream options for Traffic Model are as follows:
Page 274

- Network Default: Select this if you wish the network (global) value to determine what
option is used for this link or TS.
- PDM: Select this if you wish to use the platoon dispersion model for this particular link
or TS.
- CTM: Select this if you wish to use the cell transmission model for this particular link or
TS.
- CPDM: Select this if you wish to Congested platoon dispersion model for this particular
link or TS.
At the network (global) level, the following Traffic Model options are available:
- PDM / CTM / CPDM / Quick PDM: Select between Platoon Dispersion, Cell
Transmission, Congested Platoon dispersion, and Quick PDM. N.B. Quick PDM is a
version of the PDM that is considerably quicker to run that any of the other models, but
excludes all blocking back capabilities (other than quick flares).
- Force To PDM / Force To CTM / Force To CPDM: 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 PDM
model throughout the network.
The NetCon overlay Traffic Model Type can be used to inspect what links and TS are modelled
using which model.
Vehicle-In-Service and the Random Parameter 14.2
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 link (or TS) 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 requirement that networks have to be
predominantly signalised.
These values can be set either globally for the whole network (Outline: Network Options >
Traffic Options) or for each individual link or TS (Outline: Arm n > Traffic Streams > Traffic
Stream n > Modelling > Advanced).
Working with Traffic Models Page 275


Figure 14-1 Vehicle-in-service and Random Parameter options
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.

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 link or TS.
- Automatic: Select this if you wish the TRANSYT internal logic to work out which option is
best for this link or TS. 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.

Page 276

At the network level, the following Vehicle-in-Service options are available:

- Automatic: Select this if you wish the TRANSYT internal logic to work out which option is
best for every link or TS which has been set to the Network Default option.
- Uniform (TRANSYT): Select this if you wish to assume uniform queueing for every link
or TS which has been set to the Network Default option.
- Random (ARCADY): Select this if you wish to assume random queueing for every link
or TS 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.
Setting Cell Saturation flows 14.3
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 277

Working with Results 15
In TRANSYT, results are generated when you run a file. There are several types of results:
- Basic results for each link, such as each links (or lanes) Performance Index
- Basic results for the whole network, such as the whole network Performance Index, which
are calculated by summing and/or averaging individual link (or lane) results
- Basic results for parts of the network, such as routes, or bus links. You can see such
results by generating reports or by setting up Data Grids to show such subsets. Any
user-defined custom data grids are in addition to TRLs default Data Grids both
accessible from the vertical toolbar option Custom
- 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 PDM traffic model, used to show CFP/Queue graphs and queue
animation in NetCon.
- Detailed results from the CTM traffic model, used to show CTM graphs and CTM cell
occupancy animation in NetCon.
Basic results are saved in the file when you save it - To generate animation and graph data the
file needs to be re-run. Whether PDM or CTM detailed results are available depends on what
models are used to model the links or TS 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.
Summary Results Screen 15.1
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 278

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).
Detailed results 15.2
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 17 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 e.g. there is a mean max queue (MMQ) for each link,
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.
- Data Grids (see below) can also be used to display results, either as they are, or in a
customised format (see section 8.1.10 for how to use data grids to show results.)

Page 280

Animation controls 15.3
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 NetCon. When animation is turned on, a
time-bar will cycle through the network cycle, and this will be reflected in signal states in
NetCon, queue/flow animations in NetCon, and also in time-lines that may be visible in the
Timings Diagram and other screens.

See NetCon (Chapter 9) for details of the items that can be animated.

Graphs 15.4
After running a file, you can view various graphs for each node. These are all accessible via the
Graphs button on the main vertical toolbar, or via View>Graphs.
You can display any number of graphs; each graph will update to show data for the current link
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 Graphs button menu or via the main Preferences screen.
PDM and/or CTM graphs may or may not be available, depending on run options used 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 PDM CFP
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 links are available; simply select the graph type via the Graph button on the main
vertical toolbar, and then select the link of interest, via the Data Outline or NetCon. You can
show several graphs at once, and each graph will update to show data for the current link or TS,
unless you lock it.
With PDM graphs, the green times are displaced forward by the cruise time between the
upstream node and the node being viewed. Therefore, the arrivals from the upstream links
should more or less correspond with a vertical line dropped to the link on view. These
displacement times are shown in brackets. With CTM graphs, there is no displacement, since the
'green waves' can be seen directly.
PDM Cyclic Flow Profile (CFP) Graph 15.4.1
The Cyclic Flow graph plots a number of different graphs. The normal CFP graph plots the
variation over a complete cycle of the rate at which traffic arrives at the stop line (the IN-profile)
Page 282

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 20.1.2
Each normal graph represents, for one link or TS, 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.
The Cyclic Flow Profile 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 link or TS. 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 link or TS.

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. There are two Performance Indices shown on the left-hand side of the queue graph - one
for the chosen link; the other for the whole network.
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 a link 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 links 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 link may not be worth
considering for coordination.
5. As well as the normal graph a collection of other useful CFP graphs can be plotted. These
are as follows:
- 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 link (or TS) was fully
saturated, and no blocking was occurring.
- GOFlowWithBlock This shows what the outflow would be if the link (or TS) was
fully saturated, with existing blocking effects taken account of.
- Occupancy - This shows how many PCUs are currently on the link (or TS) at any
point in the cycle.
- Pointflow This graph is used in combination with the Distance value to show the
CFP at any point along the 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.
Page 284


PDM Queue Graph 15.4.2
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 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.
Green Capacity is the maximum number of PCUs that can be dissipated during the next green.
It is the product of saturation flow and effective green time. When queues exceed this value,
oversaturation is indicated.
UMMQ is the uniform component of mean maximum queue, taken over the whole TRANSYT run
for that link.
At some junctions, queueing may occur during the green period. This happens when the flow
along the link (or TS) 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 graphs displayed, the main and shared links are, in
effect, treated as separate links, even though they in fact share the same road space.
PDM PI-Offset Graph 15.4.3
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 node and the upstream node. 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 link or TS against the offset-difference. The
link 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 link P.I. would vary if the offset-difference was altered by
an amount varying between zero and the cycle time.
Since links on the edge of the network have no upstream nodes they cannot be offset from them.
For these links the P.I. remains constant. In all the other links the P.I. for a particular link will
vary depending on the offset-difference. The lower the P.I. the better the co-ordination.
CTM Cell Occupancy Graph 15.4.4
With CTM graphs, the signal states of the upstream links (or TS), shown at the top, are shown at
their real times and NOT displaced by their cruise time as they are with the PDM graphs.
With CTM graphs, the vertical axis represents distance back from the stop line. (The stop line is
at the bottom of the graph.)
The CTM cell occupancy graph is essentially a type of time distance diagram, and clearly shows
green waves travelling from the upstreams (at the top of the diagram) to the stop line of the link
in question (at the bottom of the diagram). In the screenshot below, traffic from Link 112s first
green period reaches Link 14s stop line during green, and is undelayed. Traffic from Link 112s
second green period, however, reaches the stop line during red and the subsequent build-up of
queueing traffic can clearly be seen by the density of shading.
Page 286


CTM Cell Flow Graph 15.4.5
The CTM Flow graph shows the relative flows at each point on the link at each point in the cycle.
Heavy shading shows traffic that is flowing freely; lighter or absent shading shows either an
absence of traffic, or, slowed or queued traffic.

CTM Cell Queue Graph 15.4.6
The CTM Queue graph is almost an inverse of the CTM flow graph: heavy shading shows where
traffic is stopped and queueing.


Time Distance Diagram 15.5
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.
Page 288


Figure 15-1 A typical (non-cumulative) time distance diagram
Features of a time distance diagram 15.5.1
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 15.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 links (or TS) that are feeding into the displayed downstream
link (or TS). 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 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 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 15-2).


Figure 15-2 Cell Flow showing three cycles
Using time distance diagrams 15.5.2
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 multiple-link or TS selection in NetCon. When making a multi-link 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.
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 NetCon 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 NetCon.
You can show several TDDs at once, and each one will update to show data for the current valid
selection, unless you lock it.
Changing offsets 15.5.2.1
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

Page 290

changes the offset for its related traffic node. This allows you to adjust the coordination
between nodes in order to achieve the particular progression you wish for the displayed flows.
This feature mirrors that of the Timings Diagram where you can also change offsets. The TDD is
automatically updated when offsets are changed, irrespective of where in TRANSYT they are
changed.
In order to see the effects of offset changes, you will need to switch off Auto
Distribute and set the optimisation level to None and re-run TRANSYT. If you
do not re-run TRANSYT after changing the offsets, the TRANSYT results (and
hence the diagram) will be out-of-date. Using the TRANSYT auto-run feature in
this situation is useful as it will allow the effects to be seen straight away each
time you make a change.
Measure of Effectiveness (MoE) 15.5.3
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.
Showing Dispersion 15.5.4
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.


Figure 15-3 Time Distance Diagram showing dispersion
Progression band types 15.5.5
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 15-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.
Cell Flow: Shows flow rates (in blue and grey) along the selected item at all
times of the cycle, and additionally shows CTM queues in red. Blue indicates
the presence of high flow rates.
The flows make use of the same cell information used to display animations in
NetCon.
For PDM items, platoon dispersion can also be clearly seen.
This mode, in some ways, gives the most traditional looking time distance
diagram (particularly for CTM) and is probably the most useful.
Cell Flow (tolerance): A variation of Cell Flow mode - A flow threshold
can be set to hide any flow rates below the chosen threshold.
Page 292


Figure 15-4 Non-cumulative reset

Figure 15-5 Cumulative Progression

Figure 15-6 PDM Cell Flow


Figure 15-7 CTM Cell Flow

Other features 15.5.6
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 main 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 Routes, by definition and multi-link selection via NetCon, do not necessarily
consist of contiguous links, progression of TRANSYT routes is limited to those links that
are linked to the first link
- The Flow Threshold value allows the Cell Flow (Tolerance) mode Flow Threshold to be
set. Only cells with flows greater than or equal to this threshold are drawn
Page 294


Figure 15-8 The effect of using a Flow Threshold

Generating Reports Page 295

Generating Reports 16
Click this button on the main toolbar to generate a report.

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.) Optionally, you can convert the report to a Word document or a PDF file.
To generate a report, click the Generate Report button on the main toolbar. The newly
generated report will be displayed in the Report Viewer (16.2).
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. Since they summarise link and
stage timings, you may prefer to use reports to view such data.
To generate a quick report, show the Report Viewer and then turn off all options other than the
Final Prediction Table option. See chapter 16 for a detailed description of each of the individual
results.
About Report Files 16.1
Each generated report is an HTML document, whose filename is based on the filename of the
current data file. It will be saved either to the same location as the data file (unless this cannot
be accessed, such as if the data file was located on a drive without write permissions, in which
case the Windows temporary folder will be used), or to a specified folder. These options are set
via the main Preferences Screen (not the Report Setup screen) see 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, which it will do by default, 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. The Report Viewer (16.2) includes options to zip
all files together to make this process easier.
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.
If you intend to save reports as PDF files, then the HTML files are effectively only
temporary files and we recommend using the Preferences Screen to set the Report
Folder to a temporary folder such as c:\temp folder.

Page 296

Report Viewer 16.2
As soon as a report is generated, it is shown in the Report Viewer. Reports are HTML
documents, and the Report Viewer built into TRANSYT is a cut down version of a web browser,
with a few useful features added. 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.

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

Refreshing the Report 16.2.1
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 above the Refresh button (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 this button to refresh the report. 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 16.3).
The Refresh button does NOT re-run TRANSYT for you. Therefore, if the TRANSYT
data has changed and TRANSYT has not been re-run, the results in the file will be
out-of-date. These same out-of-date results will be reflected in the report, even
after a refresh of the report. To ensure that the report shows up-to-date results
you need to re-run TRANSYT before pressing the Refresh button.
In order to ensure you 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.

Report Viewer Tools 16.2.2
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 applications Paste Special command and
the Spreadsheet Export Mode option.) 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.
The Tools and Zip/e-mail drop-down menu will show a menu containing a few utility functions:

Page 298

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.
Reporting Options 16.3
There are various options affecting the contents and appearance of reports. These can be set
via the Report Viewer tabbed header or via the main Preferences screen.

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.
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.
The Level of Service results are part of Output, but only appear if enabled via Regional Settings.
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 main Preferences screen
(File>Preferences), using the Import Settings From External File option.

Other Advanced options are described below.

Spreadsheet Export Mode 16.3.1.1
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.
Use Metafiles 16.3.1.2
When selected, diagrams such as NetCon 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.
Highlight Result Fields 16.3.1.3
By default, TRANSYT will use a pale-green background colour for any results in the report. This
option can be switched off.
Group by Controller Stream 16.3.1.4
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.
Fuel consumption 16.3.1.5
When selected, two fuel consumption data input tables will be created in the Input section, and
fuel consumption results tables for each traffic stream (or link) and for the whole network
created in the results section of the report.
Using custom grid layouts in reports 16.4
If you use the Data Grid screen (Section 7.6) to store custom column layouts, then you can
mark each custom layout for inclusion in reports. To do this, you need to use the Data Grid
menu item Manage Stored column Layouts to set the UseInReport flag. You can then turn
off the default report options in the Report Viewer, so that each report that you generate only
contains your own Data Grid custom layouts.
You must also turn on the Custom Grids option in the Report Viewer screen (and then refresh
the report if needed).
File Comparison Utility 16.5
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.
Page 300

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

Comparing Analysis and Demand Sets 16.5.1
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 302


TRANSYT 14 Outputs Page 303

TRANSYT 14 Outputs 17
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.
Traffic model predictions 17.1
A set of traffic model predictions are provided for the optimised or provided (evaluation) signal
timings.
For optimised runs, only the final optimised traffic predictions are provided. The
initial and intermediate timings are NOT provided.

The results are split into the following basic sections (depending upon the report options
chosen):
Banner: Describing what version of TRANSYT produced the results
File Info: Data filename used; date and time the file was run
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.
Network Diagram: A NetCon image of the complete network
When requesting Input (This is a collection of sub-sections which includes all of the
input data, except for signal data:
Analysis and Demand Sets: Lists analysis and demand sets specified within
the file.
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.)
Links: Details all input link input data

Page 304

Traffic Streams: Details all input traffic stream input data. Includes data on
Lanes, Modelling, Advanced Modelling, Flows, Sources and Give-ways.
Flow Allocation Tool Tables: A list of any Flow OD matrices. Includes
Locations, Paths, Path Flows for normal traffic buses and trams.

When requesting Signals (This is a collection of tables under the sub-heading Signal
timings, which includes all of the signal timings data AND signal timing results):
Controller Stream
Phases
Library Stages
Stage Sequences
Resultant Stages
Resultant Phase Green Periods
Optionally, Intergreen matrices
Optionally, 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):
Resultant Stages
Resultant Phase Green Periods
TRANSYT 12 style Stage Timings
Link green times
Traffic Stream green times
When requesting Final Prediction Table: (This is a summary table of Link and Traffic
Stream results):
Link Results
Traffic Stream Results
Network Totals
Network Totals (ROUTES)
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

When requesting Output (This is a collection of sub-sections which includes all of the
TRANSYT output data):
Link Results: link results summary, stops and delays, queues and blocking,
fuel consumption, journey times etc. Note: Must also be enabled in the
Advanced Tab.
Network Results: Same as the above, but results for all links combined,
within the network.
Cyclic Flow Profile Graphs (Optional): Full collection of user-specified CFP
graphs.
Point to Point Journey Time Tables (Optional): A point-to-point journey
time tables for each user-defined OD Matrix.
When requesting Offsets 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.

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 (as shown below), in the same way they are presented for individual links, traffic
streams and the complete network.

Page 306

TRANSYT individual link or traffic stream predictions 17.2
This section provides a description of the main output values provided within the TRANSYT
results relating to each individual link or TS. 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.
Link Results and Traffic Stream Results: Summary 17.2.1
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 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 LTS (link or traffic stream) (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 link (or TS) to be oversaturated,
either with the initial signal settings or at any part of the hill-climb process, downstream links
(and TS) will have reduced inflows. In such cases where the flow into a link (or TS) is smaller than
the original value by more than 10 PCU/hour, the inflow value is marked with a < symbol in Final
Prediction Table>Link (or TS) Results. An oversaturated link (or TS) 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 link at its upstream end if the first CTM cell is
occupied. Therefore, even for entry links Calculated Flow Entering link values can
be reduced or even zero. Zero values of Calculated Flow Entering link may
indicate that the traffic on that part of the network has locked up.


Calculated Flow out of LTS (link or traffic stream) (PCU/hour)
This is the flow counted crossing the stop line, i.e. the sum of the OUT flow profile elements. If
the link (or TS) is under-saturated this will be the same as the Calculated Flow Entering the link
(or TS). However, in the event that the link (or TS) 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 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 link flow and the TRANSYT
calculated total flow. Values over 10 PCUs are additionally indicated in the output as described
immediately above.

Calculated Saturation flow (PCU/hour (of green))
This value is the saturation flow associated with either a signalled link (or TS) 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 greyed 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.

Calculated Capacity (PCU/hour)
The average rate of 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 308

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 cycle time 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 link to let traffic out of the link.
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 link is the entry flow as it takes account of oversaturation of the
upstream sources feeding that link, 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 link (or TS). 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 link (or TS) 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%.


Actual Green Time (seconds per cycle)
This is the time for which the signal head for traffic on a link or TS actually shows green.

Effective Green Time (seconds per cycle)
This is the time for which traffic behaves as if the signals were green.

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 link or TS.

Performance Index (/hour)
This is the sum of the delay and stop costs for the link or TS plus any excess queue penalty (see
Maximum Queue Length and Penalty). The components are 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.

Page 310

Results: Stops and Delays 17.2.2

Mean cruise time per PCU (seconds)
This is the mean un-delayed travel time along a link or TS obtained from up to six possible inflow
cruise times specified in the Link Flow Data or TS 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 (seconds)
This is the average value of delay experienced by a PCU on the link or TS. It is obtained by
dividing the total delay rate (uniform and random + oversaturation) by the flow into link. The
delay is similarly calculated for Traffic Streams, but the mean delay value is a weighted average of
the delays of the traffic on all paths passing through the traffic stream. For traffic streams, please
note that the delays experienced by PCUs using a particular TRANSYT path through the network
will experience their own delays specific to that path. This ability of TRANSYT 14 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 link or TS. This result is only available if the LoS option under Options/Regional
Settings has been enabled.

Mean delay per PCU (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)
This is the uniform component of the total rate at which delay is incurred on the link or TS. The
uniform component is equivalent to the average number of PCUs queueing on the link or TS
during the typical cycle.

Random + oversaturation delay (PCU-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 link or TS. 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 link or TS 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 link or TS during the period specified in the General Data, Simulated
time (mins) (Main/Common Data).

Unweighted Cost of delay (/hour)
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)
The total delay rate for the link or TS 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 link (or TS data equivalents).

Mean stops/PCU (per cent)
This is the average percentage of stops per PCU entering the link or TS, 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 21.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 312

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 link or TS. 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 link (or TS data equivalents).

Results: Queues and Blocking 17.2.3
Initial queue (PCU)
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)
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)
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 user-defined maximum number of PCUs that can fit within the physical space of the link
(or TS) (which is appropriate for the modelled time period).

Max Utilised Storage (PCU)
This is the maximum used storage on the link (or TS). This value is only relevant if all traffic is
stopped.

Average Excess Queue (PCU)
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)
On links (or TS) 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 link or TS.
For links other than those specified with a Max Queue Storage value, TRANSYT computes:

Maximum (Link) queue storage (PCU) =

75 . 5
) (
*
) / ( 1800
m length Link
h PCU
SF

(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 Traffic Streams other than those specified with a Max Queue Storage value, TRANSYT
computes:

Maximum (Traffic Stream) queue storage (PCU) =

) (
) (
*
m length PCU
m length Link
lanes of number

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 link or TS associated with excess queue.
Page 314


Max End of Green Queue (PCU)
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)
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 links (or TS).

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 links (or TS).

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.

Results: Fuel consumption 17.2.4
As described in section 21.14, 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. 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)

Results: Journey Times 17.2.5
- Distance Travelled (PCU-hr/hr)
- Time spent (PCU-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 17.3.3).

Results: Advanced: 17.2.6
The advanced output values are only accessible from the Results/Advanced section of the Data
Outline.
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.
Page 316


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.

Point1 In flow (PCU/hr); Point1 Out flow (PCU/hr); Point1 Go flow (PCU/hr)
Point2 In flow (PCU/hr); Point2 Out flow (PCU/hr); Point2 Go flow (PCU/hr)
The above six values can be used in conjunction with the X-Y graph. Used for advanced
investigative purposes only.

TRANSYT 12 tables: Resultant Stages 17.2.7
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.

TRANSYT 12 tables: Resultant Phase green Periods 17.2.8
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 may be of interest to those
familiar with earlier versions of TRANSYT.
The following data is presented:

TRANSYT Starting Stage
This is the first stage in which the named phase runs.
TRANSYT Ending Stage
This is the first stage in which the named phase no longer runs.
TRANSYT Start Lag
The start lag is the time in seconds from the stage change time to the start of green signal for
that phase. Usually the start lag corresponds to the interstage.

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.

TRANSYT 12 tables: Stage Timings (TRANSYT 12 timings) 17.2.9
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
Page 318

Stage n
TRANSYT Stage start times (including preceding interstage).

TRANSYT 12 tables: Link Green Times 17.2.10
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 NetCon. 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 link (or TS) is presented. The times are the actual green times: to obtain effective green
times, add the displacements specified in Main (common) Data
TRANSYT 12 tables: Traffic Stream Green Times 17.2.11
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.

TRANSYT network-wide results 17.3
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.
Summary report section: 17.3.1
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.

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.

Output report section: 17.3.2
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.

Final Prediction Table output: 17.3.3
The Network Totals Table consists of up to four rows of results as follows:
Page 320

1st line: TOTAL For all links.
2nd line: BUSES For bus links only.
3rd line: TRAMS For tram links only.
4th line: OTHER For neither bus nor tram links (i.e. normal traffic).
The 2
nd
, 3
rd
and 4
th
lines appear only when there are bus or tram links (or TS).
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)
This is the product of total flow entering the link and link length, summed for all links (or TS
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)
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 links (or TS 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 (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.


Regional Settings output: 17.3.4
This result is only available if the LoS option under Options/Regional Settings has been enabled.
The result is part of the Link and Network Stops and Delays tables.
Signalled LoS
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 links (or TS) feeding into that particular Traffic Node.

Path Segment results: 17.3.5
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: TRANSYT Network
> Options > Calculate results for path segments. See Outline: Traffic Streams > Traffic Stream
n > Path Segments.

Page 322


X-Y Graph Analyser Page 323

X-Y Graph Analyser 18
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, but 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.
Adding inputs and outputs 18.1.1
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.
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.

Page 324

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.

X-Y Graph Mode 18.1.2
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:
1. Show the Analyser Screen and select X-Y Graph mode.

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

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

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



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

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 328

About X-Y Graphs 18.1.3
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 14 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.
Time Graph Mode 18.1.4
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 330


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 331

Additional Tools and Features 19
Find Shortest/Best Route 19.1
(Tools>Routes>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 NetCon and save it in the file as a new TRANSYT Route.

Merging Networks 19.2
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 14 file
that will be merged with the current file. The screen shown below will then appear.
Usually, both the current network and the network being merged, will share various IDs such as
those associated with links, traffic streams, controller streams, e.g. both will probably contain a
Traffic Stream 1. Since IDs must be unique, a prefix/suffix mechanism is used to distinguish the
items in the network being merged from the existing items. In the screenshot, the letter N is
entered as the prefix for all items requiring a unique ID. When the Merge button is pressed, all
the items from the new network will be prefixed with an N, as long as this does not cause any
other errors. You can of course rename items once the merging process is complete.

Page 332


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.


Saturation Flow Estimation 19.3
Saturation flow is the flow across a stop line during green while there is still a queue remaining.
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 lane widths and turning radii. The prediction of saturation flows is covered in
TRRL 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.
TRANSYT applies these formulae in the Saturation Flow Calculator Tool (see Section 19.3) and
when using the Use RR67 option in Lane data (Outline: Arms > Arm n > Traffic Stream m >
Lanes > Lane P.)
By using these formulae it is possible to predict saturation flow values quite reliably 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.
Calculating Lane Saturation Flows 19.3.1
Saturation flows need to be specified for most traffic streams or lanes. Only 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.
When using lanes, the Saturation Flow can either be entered directly or derived from
geometric data using the RR67 equations. If Use RR67 is selected the saturation flow data
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.

- (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
the same as saying the road surface condition is dry.

- 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). Due to the schematic nature of
Netcon and the fact that lane movements do not necessary match the physical
movements required by vehicles, it is not possible to glean this information from
the lane data If the turning proportions change, say, due to changes you make
to the O-D Matrix you should also update these values.

Page 334

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

Saturation flows are always used when modelling unopposed situations. Opposed movements
make use of max flow values. Both values are used where a traffic stream has periods of time
when it is opposed and unopposed.
Saturation Flow Estimation Tool 19.3.2
Although RR67 saturation flows can be calculated and applied within each traffic stream and link,
TRANSYT still includes an RR67 saturation flow calculator utility. Access this either from
Tools>Saturation Flow Calculator, or by clicking the RR67 Calculator link shown in the Data
Editor when viewing a Link.

The unopposed saturation flow for each lane, and the total for all lanes, is shown as you input
data. If you accessed the screen from a Link, then pressing the Use calculated sat flow button
will take the calculated value and use it to populate the links Saturation Flow data field.

QUEPROB - Effective Flare length calculator 19.4
The flare capacity calculation program QUEPROB provides 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.
QUEPROB is only ever required for the quick flare model, and therefore is
essentially obsolete for all but those files containing quick flares. It is
recommend that CPDM or CTM models are now used to model flares, neither of
which require the use of QUEPROB.
QUEPROB 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.
Access this either from Tools>QUEPROB, or by clicking the QUEPROB link shown in the Data
Editor when viewing a Links Flare.

The user is 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.
Probability of traffic using main lane (in percent)
Enter the proportion of traffic which uses just the main lane, and hence the remainder which
uses the flare is effectively specified.
The QUEPROB component then outputs the following information, with example values included:

Page 336

1) Max number of vehicles (or PCU) that can fit into flare 8
2) Probability of traffic using main lane (in percent) 60
3) Mean utilisation of short (flare) lane 5.43
4) Mean utilisation of long (main) lane 7.65
5) Extra capacity due to flare 5 (rounded from 5.08)
The extra capacity (line 5) is the difference between the sum of the mean queues for the main
lane plus the flare lane (line 3 + line 4) minus the entered number (line 1). Thus, for the above
example values:
5.08 = (5.43 + 7.65) - 8
If the Use Result option is clicked, the Extra capacity due to the flare is entered as the
Effective Storage value for the currently selected flare. Alternatively, this value can be entered
manually as the Effective Storage value.

Drive-on-the-left/Drive-on-the-right 19.5
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 and links in NetCon.
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.

Traffic Behaviour Models (PDM/CTM) Page 337

Traffic Behaviour Models (PDM/CTM/CPDM) 20
For modelling of traffic behaviour within the network, TRANSYT makes use of up to four traffic
models - the platoon dispersion model (PDM), the cell- transmission model (CTM), the congested
platoon dispersion model (CPDM) and the quick platoon dispersion model (Quick PDM) .
Any of the first three models can be applied to each individual link or TS or across
the whole network. Various options are provided within TRANSYT to select the
model required at any particular moment for the situation being modelled. The
Quick PDM model can only be applied globally across the whole network.
For all four 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 following sections give details of the four models.
Platoon dispersion model (PDM) 20.1
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.
Cyclic flow profiles 20.1.1
An example cyclic flow profile is Figure 20-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
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.
Page 338


Figure 20-1 A traffic flow histogram
IN, OUT and GO profiles 20.1.2
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 20-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.

40 units = 1 cycle
Time (seconds)
40 30 20 10
0


(a) IN PROFILE

(b) OUT PROFILE

(c) GO PROFILE
Figure 20-2 Definition of IN, OUT and GO flow profiles
Page 340


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 links (or TS)
(see section 20.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 20-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 number of vehicles (m
i
) at the stop line during time interval is calculated by the relation:
m
i
= m
i-1
+ q
i
- s
i
or 0 whichever is the greater
where
q
i
is the number of vehicles arriving in interval i (given by the IN-profile)
s
i
is the maximum number of vehicles allowed to leave during an interval i (given by
the GO-profile)
The number of vehicles leaving the stop line in time interval i is:
m
i-1
+ q
i
- m
i

These values are used to derive the OUT-profile.
The calculations using the IN, GO and OUT profiles are carried out for each step of the cycle for
each network item (link or TS) 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 20-3 Example of measured and predicted dispersion on a link
Simplified traffic behaviour 20.1.3
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 20-4 by the trajectory in time and distance of vehicle 1.
Page 342


Figure 20-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.
The platoon dispersal coefficient 20.1.4
The platoon dispersal coefficient is a number, K, which modifies the platoon dispersion factor F
as follows:
Effective signals
as in TRANSYT
(Actual signals) Green
Amber
D
1
D
2
at start of green
D =
at end of green
D =
Red/Amber
Red Red
1
2
Realistic trajectory
TRANSYT trajectory
Undelayed vehicle trajectory
Delay for vehicle
Time
Stop-
line


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 21.10.
Congested Platoon Dispersion Model (CPDM) 20.2
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. It has the ability to model blocking
effects where traffic on a particular link (or TS) 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 links/flares. 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.
Feeding links (or TS) upstream of a CPDM modelled link (or TS) are those that will experience
the blocking effects. This in turn can prevent traffic on these upstreams reaching other
downstreams, such as with a flared situation.
Details of how to use this model are in sections 3.12 and 21.7.
Quick Platoon dispersion model (Quick PDM) 20.3
The Quick PDM model is an adaptation of the standard PDM model developed by TRL which has
been enhanced to include extra functionality, such as the ability to model mutual opposition, but
excludes the ability to have mixed traffic models within the same network. Therefore, it
excludes all blocking capabilities e.g. CPDM cannot be selectively used within the network
however quick flares can be used instead. N.B. the Quick flare model is the same flare model
as provided previously in TRANSYT 13 and earlier versions.
The models main advantage is that it is significantly faster than the other traffic models, hence
it is provided for when a quick solution is required, and the modelling of blocking effects is not
required.

100
Kt
+ 1
1
= F

Page 344

Cell Transmission Model 20.4
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 14.3.
Link flows and occupancies 20.4.1
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.

Figure 20-5 Spatial representation of traffic on the road in the CTM

Shared links in the CTM 20.4.2
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.
Cell 1 2 3 4 5 ... ... Cell 1 2 3 4 5 ... ...
Page 346

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.
Modelling flared links in the CTM 20.4.3
Although the original flare model (now called quick flares) can be used with CTM to model
flares. it is not the recommend method quick flares are provided primarily for backwards
compatibility and their use in conjunction with the Quick PDM. The recommended method of
modelling flares is to represent the flared area using separate traffic streams or links which are
set to use the new CPDM (Congested PDM) model. The network structure of this method,
matches that of TRANSYT 13 flares which have used CTM to model them. However, only where
flares are particularly long should you now consider using CTM to model a flare. How to model
flares (short bays) using each available method is fully described in sections 21.7, 21.8 and
21.9.
Modelling give-way links in CTM 20.4.4
The CTM models traffic flow both in uncongested and congested situations. This has an
implication in the modelling of give-way links (or TS). 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 link (or TS), 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 link (or TS). Note that
the minimum uncongested give-way capacity is either zero or F(s), whichever is larger.
In the congested situation for the controlling link (or TS), at the onset of oversaturation due to
reducing downstream capacity, the flow starts to drop from the saturation flow. As the
controlling link (or TS) 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 link (or TS) is over saturated, and that the
give-way capacity decreases linearly as controlling link (or TS) 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 20-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 20-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.
PDM versus CTM 20.5
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.
Page 348

The PDM and the CTM emphasise different aspects of traffic flow behaviour; it is inappropriate to
assume that one mode is best suitable in all road and traffic situations. The PDM is appropriate
to long links and un-congested traffic, while the CTM is suited to short and congested links. The
later situation is typically found in city centres where the free-flow dispersion is not dominant
and where traffic is more likely to be restricted by downstream traffic and traffic signals.
Although the CTM is computationally more efficient than most other discretized macroscopic
traffic models, it is still computationally more demanding compared with spatially aggregate
models, such as the PDM. The runtime depends mainly on two factors:
1) Level of congestion, because it affects the amount of traffic to be "transmitted"
2) Size of network, in terms of numbers of links / nodes, and the length of links. This affects
they affect the number of cells traffic is transmitted.
How to select the models is described in chapter 0.
CPDM versus CTM 20.6
These two models differ in the same way as PDM and CTM differ (see section 20.5) except for the
modelling of the spatial extent of queue. CPDM links (or TS) do have some spatial awareness -
TRANSYT has awareness of the availability of space for traffic upstream of a CPDM link (or TS) for
traffic to flow into i.e. CPDM links (or TS) can block upstream links (or TS). 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 the capability of. 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.
How to select the models is described in chapter 0.
Restrictions on use of the CTM 20.7
The limitation to a network 20.7.1
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 link or TS 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 link or TS.
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.)
TRANSYT 14 functionalities that CTM does not handle 20.7.2
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.

Time segment analysis with time-varying entry link flows is now supported
by the CTM - This was a restriction in TRANSYT 13.

Page 350


TRANSYT Model Features in Detail Page 351

Traffic Model Features in Detail 21
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.
Signal settings 21.1
Full details are given in section 3.6
Queues and Delays 21.2
Queue length derivation 21.2.1
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.
Uniform delay rate 21.2.2
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.
Oversaturation delay rate 21.2.3
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. Thus, the queue is
zero at the start of the modelled period and twice the average at the end.
Random delay rate 21.2.4
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 21-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 352


Figure 21-1 Traffic delay on a link
Delay calculation 21.2.5
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:
( ) ( ) hour / hours pcu F f
T
f 4
F f tion oversatura Random
2 / 1
2
4
T

+
(
+ = +

1000 1200 1400 1600 1800
Mean arrival flow rate (pcu/hour)
60 70 80 90 100 110
Degree of saturation (percentage of maximum discharge flow)
Oversaturation
delay
Random
delay
Uniform
delay
saturation flow
Cycle time
Red time
Duration of flow
= 3600 pcu / hour
= 90 seconds
= 50 seconds
= 30 minutes
60
40
20
0
0
stopline data:

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 21-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. 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.
Comparing real and predicted queue lengths 21.2.6
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.
Stops 21.3
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 354

Uniform and fractional stops 21.3.1
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 21-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 21-2 Valuation of full and fractional stops
from various cruise speeds
As discussed in section 21.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.
Comparing real and predicted queue lengths 21.3.2
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.
Wasted green time 21.4
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 356

Calculation accuracy 21.4.1
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 22.5.2). If the optional
maximum queue storage is provided by the user it is used, otherwise a TRANSYT estimate of
this value is calculated (previously known as Link Capacity) and is used instead. The accuracy
of the wasted green times will be improved wherever the user-defined value is present.
Fundamentals of the Give-way Models 21.5
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 link or TS. 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 link or TS 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 link or TS 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
13.13).
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 13.15 on Indirect traffic
control.



Figure 21-3 Give-way capacity relationships for a typical junction
Figure 21-3 shows two examples of typical linear relationships between major (controlling) and
minor (give-way) traffic flows. Figure 21-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 link or
TS 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 20.4.4 for full details.
Parameters controlling the give-way model 21.5.1
Give-way links (or TS) 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.

1000
0
200
400
600
800
0 500 1000 1500 2000 2500 3000 3500 4000
Major road controlling link flows, q , q (pcu/h)
1 2
F = 715 - 0.22q
L 1
F = 600 - 0.22q - 0.19q
R 1 2
q = q
1 2
q
2 F
R
F
L
Minor road
Major road q
1
Page 358


Figure 21-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 = F
0
- A
1
q
where F
0
is the maximum flow from the give-way link when the controlling flow is zero; A
1
is a
constant. The user must specify F
0
and A
1
.
Two controlling links:
In this case, the linear relationship is of the form:
F = F
0
- A
1
q
1
- A
2
q
2
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 F
0
, A
1
, A
2
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 13.6.
Signalled
node
Signalled
node
'Give-way' links for minor-road traffic,
controlled by major-road flow emerging
from the 'bottleneck'.
'Bottleneck' for major-road links.

When a give-way is controlled by more than one controlling link, these links can be
either signalised or unsignalised - The TRANSYT 14 model allows mixed types of
opposing links as well as allowing many more conflicts to be defined.
Choice of give-way parameters 21.5.2
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 21-3.
Typical (not default) coefficients in this case are:
F
0
= 715 PCU/h
A
1
= 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 W
1
= 4.5m.
F
0
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 (A
1
) varies similarly with w and V but
also varies inversely by about -10 per cent per metre change in W
1
.
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 21-3. The give-way capacity is determined
by the flows (q
1
and q
2
) on the two controlling links as follows:
F = F
0
- A
1
q
1
- A
2
q
2

with typical (not default) coefficients being;
F
0
= 600, A
1
= 0.22, A
2
= 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 (W
2
) occupied by both controlling flows,
where W
2
= 9m. Coefficients F
0
, A
1
and A
2
vary by +10 per cent per +1m in w, and by +1
per cent per +10m in V. The slopes (A
1
and A
2
) also vary inversely by about +5 per cent per
+1m in W
2
.
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 F
0
, A
1
, A
2
should then be
Page 360

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:
F
0
(total) = F
0
(Lane 1) + F
0
(Lane 2) etc, and similarly for A
1
, A
2
.
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 21-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 latest version 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.
Vehicle In Service and Random Parameter 21.5.3
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 14.2.
Shared link stop lines 21.6
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 21.10). 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.
Shared link stop line specification 21.6.1
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?). 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.
Shared link give-ways 21.6.2
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.
How shared links relate to traffic streams 21.6.3
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.
Flared approaches The CPDM method 21.7
Flares can be modelled using two different techniques - The new Congested Platoon Dispersion
Model (CPDM) method and the CTM method. The CPDM method, which is described here, is the
principal method recommended for flares close to or below 30 metres in length. Detailed advice on
the CTM method is described in section 21.8. The CPDM method is recommended for shorter
flares due to the fact that it models random effects in addition to its inherent ability to model
platoon dispersion. For longer links the superior spatial awareness of the CTM model will make it
a more appropriate model to use.
Page 362

Both the CTM and CPDM models in TRANSYT 14 provide a natural way of defining
flared approaches. For complex situations it easy to set up and also models
situations more accurately, due to the inherent ability of both models to take
account of blocking effects.
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:
Simple Flare Example 21.7.1
The simplest example (Figure 22-7) 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. Error! Reference source
ot found. Figure 21-6 shows the required traffic stream structure in TRANSYT.

Figure 21-5 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
NetCon.
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.
main lane
flare



Figure 21-6 CPDM 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 CPDM so that they will block. Traffic Stream 1/1 is left as a standard
PDM link Essentially, you are defining which links have the capability to block upstream
traffic.
5. Maximum Queue Storage: TRANSYT, by default will calculate internally the amount of
traffic that can store on any link using the link 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 link or TS using the CPDM
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.
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.
CPDM flares 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.
Page 364


Figure 21-7 Cyclic Flow Profile of exiting traffic

Figure 21-7 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 the new CPDM model 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 previous 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.
Further examples of using this method are detailed in Chapters 23 and 24.
Flare Results 21.7.2
Modelling of a flare using individual components as described here (or when using the CTM
method) 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 21-8 Flare Results Example Network

Figure 21-9 Data Outline and Flare Results
Page 366

For the feeding (upstream) traffic stream (traffic stream 2Cf/1 in the example) additional Flare
data is provided under the 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.
Flared approaches the CTM method 21.8
Flares can be modelled using two different techniques - The new CPDM method and the CTM
method. The CTM method, which is described here, is the principal method available for flares or
short bays of any type which are over 30 metres in length. Detailed advice on the CPDM method
is described in section 21.7.
The CTM method is recommended for longer flares due to the fact that it is has full horizontal
spatial awareness, unlike the CPDM model. The diagram below shows an animation of the flow
rate, and clearly shows how the traffic stream is represented by a series of CTM cells.
Both the CTM and CPDM models in TRANSYT 14 provide 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 both models to take
account of blocking effects and platooning effects.
The network structure and general requirement required for using the CTM model is the same as
that required for the CPDM model, except that all three traffic streams should have their traffic
model set as CTM, hence please also refer to section 21.7.
Combined results for the flared area are obtainable as described in section 21.7.2

Figure 21-10 CTM model of a simple flare

Further examples of using this method are detailed in Chapters 23 and 24.


Flared approaches - quick flares 21.9
Previous versions of TRANSYT modelled the extra capacity available from flared approaches giving
an extra lane or lanes at the stop line, as in Figure 21-11(a) by explicitly defining one or more
quick flares on a link. TRANSYT 14 has newer, more accurate, and considerably more flexible
methods of modelling flares using either the Congested PDM model (CPDM) or the CTM model.
Because the new techniques offer considerable advantages over the previous quick
flare model, it is recommended that any quick flares are removed from imported
and the new techniques used instead. TRANSYT 14 will import existing flares, but
will not attempt to convert them.

A summary of how quick flares work and how they are specified is retained in this section only 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).
Flares modelled in TRANSYT 13 using the CTM model can still be modelled in the
same way, so do not necessarily benefit from conversion. However, the CPDM is
the recommend model for short flares due to its ability to model random and
platooning effects. The link structure is generally the same, so it is easy to re-
specify the relevant links as CPDM links instead of CTM links.
The quick TRANSYT flares model the extra capacity available from flared approaches giving an
extra lane or lanes at the stop line, as in (a) by explicitly defining one or more flares on a link.
The non-linear saturation flow is of the stepped form shown in Figure 21-11(b). It contrasts with
the constant, single valued, saturation flow for non-flared links.
The normal saturation flow specified for a link (Outline: Links>Link n) represents the value for the
main lane alone. In addition, the user is required to specify, in Flare Data (Outline: Links>Link
n>Flares>Flare n);
(i) the saturation flow for the extra lane(s) provided by the flare,
(ii) the average number of vehicles which are able to use the flare during each green,
estimated or measured (Effective storage)

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.

main lane
flare

Page 368

(a)

(b)
Figure 21-11 Flared link and corresponding stepped saturation flow
Examples of using the flare model in various cases are given in the following sections.
Flare fully used 21.9.1
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.
Unequal use of flare and main lane 21.9.2
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 the GUI component QUEPROB. Again, the assumption is that the flare green is the same as
that of the main-line green.
Queues interact, and flare traffic is opposed right-turn:
0
green time
sat.
flow

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 14 make the modelling of such complex
situations a lot easier and simpler to model.
Bus and Tram Links 21.10
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 21-12 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 21-12, the green period is offset to reduce the delay to the bus even though
the platoon of other traffic then suffers some delay.
The BUS TRANSYT model 21.10.1
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:
t b
F
15 . 0 7 . 0 1
1
+ +
=

where t = mean cruise time (measured in steps)
b = mean stationary time at a bus stop (steps)
Page 370


Figure 21-12 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 22.1.2) or
special traffic stream weighting factors which are applied to either all traffic or to individual OD
Paths on each traffic stream (see section 22.1.2.1). Weightings can be applied proportional to an
assumed number of passengers. The optimising routine will then attempt to find signal settings
which minimise total passenger delay.
This method of optimising specifically to take account of the different behaviour of buses within the
network and their value in terms of passenger numbers, is likely to be most effective where bus
flow rates are relatively high (more than 10 to 20 buses per hour) and the average time spent at
SIGNAL 1
Bus
Bus stop
Red Green
Time
Distance
Green
Bus
A platoon
of traffic
SIGNAL 2
One-way
progression
Red

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.
The TRAM TRANSYT model 21.10.2
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.
Bus/Tram model coefficients 21.10.3
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 >
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)
Details of the equations used are given in TRL Laboratory Report LR666.
Specifying bus link/TS parameters 21.10.4
While shared stop lines allows you to separate classes of vehicles which are part of the same
queueing situation, the Source Type (Outline: Links > link n > Sources, or Traffic Streams >
traffic stream n > Sources) allows you to define what category of traffic is entering these links or
traffic streams (see Figure 21-13).
There are currently three types of source Normal, Buses and Trams. The default Normal
source is the name given to a link which is assumed will not be modelling buses or trams.
In place of the normal cruise speed / cruise time entry for normal links, 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 21.10.4.1 and 21.10.4.2.
Specifying bus parameters for links 21.10.4.1
The average free-running speed and average time stationary at bus/tram stops are set in Link
Data - Flows (Outline: Links > Link n > Sources)
Page 372

A link having one or more bus sources is identified as a bus link by the program and all such
links are marked on the output with B, and are separately totalled. If only some of the
sources carry buses, then the GUI will show a warning to check that the user is aware of
this mixed traffic. The same applies to trams, with the output marked with a T and also
pedestrians which are marked with a P.

Figure 21-13 Link Source Types
If ALL sources for a link are BUSES or TRAMS, then the Dispersal Type for the link should
be 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. 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). Note how Bus and
Tram dispersion parameters can only be applied globally.
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.
Specifying bus parameters for traffic streams 21.10.4.2
The average free-running speed is set in Traffic Stream Data - Flows (Outline: Traffic Streams
> Traffic Stream n > Sources
The average time stationary at bus/tram stops is set in Traffic Stream Data Bus and Tram
(Outline: Traffic Streams > Traffic Stream n > Buses/Trams)


Figure 21-14 Traffic Stream Source Data
A traffic stream containing any bus flow is identified as a bus traffic stream by the program
and all such traffic streams are marked on the output with B, and are separately totalled.
Mixed traffic is allowed, as the different traffic types are still kept separated within the
internal model. The same applies to trams.
For convenience, 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.
If ALL the traffic on a traffic stream is BUSES or TRAMS, then the Dispersal Type for the
traffic stream should be 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. 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)
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.
Page 374

Pedestrian Links 21.11
Links in TRANSYT can be assigned as either vehicular (the default) or pedestrian streams.
Please note that TRANSYT models all links in the same way regardless of type: it does not
include a separate pedestrian model. Furthermore, traffic streams cannot be pedestrian links.
Pedestrians are increasingly important in urban signalised junctions, and TRANSYT can help
emphasise their effects by use of delay weighting relative to other streams. When pedestrian
links are required to be identified within the network, but their presence is not required to
influence the choice of signal timings their contribution to the Performance Index calculations
can be excluded using the global option Network Options > Traffic Options > Exclude Pedestrian
Links
Pedestrians 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 mentioned above there is no separate
pedestrian model in TRANSYT and therefore these results 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 good indications as to the performance of the pedestrian links,
and are therefore a good 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. If needed, these effects can be compensated for by
reducing the pedestrian demand.
Collections and Routes 21.12
TRANSYT allows the specification of Collections. A collection is simply a defined subset of the
links or controller streams within the 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. The term route (its equivalent name in TRANSYT 13) is
retained in the name, as a reminder that collections can also be routes i.e. the user can, if
they wish, make the collection of links (or TS) 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 and Routes 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 and Routes):


If using this method, various options have provided to make it easy to select all the links
or TS 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 Netcon) and the menu item
Tools>Routes>Store New Route from currently selected Links or controller streams or
traffic nodes.
3. The menu item Tools>Routes>Calculate all routes in network, which will replace all
existing routes.

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 links can be identified graphically within NetCon 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.
Page 376

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 routes 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 19.1.
Traffic Profile Types 21.13
Uniquely, for this type of analysis tool, TRANSYT can calculate signal timings based on varying
traffic conditions. These are specified by specifying a traffic profile over time. The different
types of profile that can be used are described in the following sections.
DIRECT traffic profile 21.13.1
In DIRECT mode, detailed demand flow profiles (i.e. mean flow in each time segment) are
directly input to the program via the Traffic Flow screen.


The traffic model will always use DIRECT traffic profile data, if it exists, in
preference to the total flow value, i.e. no matter how the total flow is derived, it
will be ignored, therefore even if a wide-area matrix (assignment) or local matrix
is used to derive the total flow it will be still be ignored.
FLAT traffic profile 21.13.2
In FLAT mode, a value is entered for the first time segment for each traffic stream, and the flows
for all other time segments set to be equal. This represents a set of traffic flows that remains
constant over time.
By default, each entry link has a FLAT profile, which requires no data other than the 'average
flow over modelled period' when there is only one time segment.
Gaussian traffic profile 21.13.3
This mode is intended for modelling peak periods when flows start off low, climb to a maximum
and then decline towards the end of the time period.
The Gaussian mode takes the Total Flow as the flow for the central time segment and then
applies 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.
Fuel consumption estimates 21.14
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 links and traffic streams are excluded automatically from the calculations
The original principles behind these estimates are explained in LR 934, (Robertson et al, 1980).
However, the latest equations and associated coefficients are now taken from the more up-to-
date DfT WebTag: TAG Unit 3.5: The Economy Objective Vehicle Operating Costs Fuel
2

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
21-17 shows these relationships for the average UK car (as of March 2010). Details of the
revised fuel consumption equations and coefficients are in section 21.14.1
Fuel consumption parameters (Revised 2010) 21.14.1
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:

2
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 378

L = a + b.v + c.v
2
+ d.v
3
/ 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.

TRANSYT 14, not only provides parameters for each of the vehicle categories (Outline: Network
Options > Fuel consumptions) for the default 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, e.g. March 2010 WebTag data.

Figure 21-15 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 (Data Outline: Network Options > Fuel Consumption)
references the ID of the parameter set that will be used by TRANSYT to produce the results (see
Figure 21-16). 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 21-16). Again, TRANSYT
provides default vehicle composition appropriate for the UK, but this can be easily replaced if
necessary.
Fuel used as a result of delay 21.14.2
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.
Fuel used as a result of stops 21.14.3
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 21-16). Again, defaults are
provided, but your own values can be specified directly. If you wish to bypass the calculation
you can specify the E parameter directly by changing the ECoefficent Mode from ByWeights
to Custom for each vehicle category.
The stops consumption formula is of the form:
L = E.V
2

Where: L = consumption, expressed in litres per stop

Page 380


Figure 21-16 Vehicle categories: proportions and weights
The relationships used in the fuel estimates assume that traffic flows in the network (and
saturation flows) are specified in PCU/hour. If vehicles/hour is used, the fuel consumption should
be increased by a factor based on the traffic mix specified as part of the fuel consumption
calculations. E.g. if all the vehicles happened to be heavy vehicles the final fuel consumption
figures would need to be doubled to reflect the fact that they represent 2 PCUs.

Figure 21-17 UK Fuel consumption relationships
F
u
e
l

c
o
n
s
u
m
p
t
i
o
n

a
t

c
o
n
s
t
a
n
t

c
r
u
i
s
e

s
p
e
e
d

(
l
i
t
r
e

/

1
0
0

m
i
l
e
s
)

Link cruise speed, V (km/h)
Average Car Consumption (litre/100 miles)


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.
(Flow) Assignment Model 21.15
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.
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 382


TRANSYT Optimisation in detail Page 383

Optimisation in detail 22
As explained in section 3.3, 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-5. The offset of an intersection is defined
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 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 22.9
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). 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.
Individual links (or TS) can also be excluded from the calculation of P.I. by setting the modelling
option Exclude from Results Calculation (Outline: Links > Link n > Modelling or Outline: Traffic
Stream > Traffic Stream n > Modelling). A global setting to exclude all pedestrian links from the
results calculation (no matter what the above option is set to) is also provided (Outline: Network
Options > Traffic Options).
The performance index 22.1
In TRANSYT the main measure of performance considered is a weighted combination of the delay
and stops on all the links and traffic streams in a network. It represents the cost of traffic
congestion. The Performance Index (PI) is defined as follows:

N
PI = E (W.w
i
d
i
+ ((K/100).k
i
s
i
))

i=1
where N = number of links and traffic streams
W = overall cost per average PCU-hour of delay
K = overall cost per 100 PCU-stops
w
i
= overall delay weighting on link (or traffic stream) I
d
i
= delay on link(or traffic stream) i
Page 384

k
i
= overall stop weighting on link (or traffic stream) i
s
i
= number of stops on link (or traffic stream) i
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.
Choosing the monetary value of stops and delay 22.1.1
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 W and K that they judge are most appropriate. The values of W
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 (W) 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 the link-specific coefficient w
i
to correct the
estimates of the delay costs on links where, for example, there is a high proportion of goods
vehicles.
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 W 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 W 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
and K (Robertson et al, 1980, also describes how W and K may be chosen to minimise the overall
fuel consumption).


Stop and delay weightings 22.1.2
The link or TS stop weighting is a number representing the percentage of the stop valuation used
when calculating the links (or TS) contribution to the Performance Index The stop valuation is set
in Traffic Options > Economics data > 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 (or TS) 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 (or TS).
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 14.
Specifying traffic stream weightings 22.1.2.1

When using a link structure, buses and trams are naturally separated onto their individual links
(normally as part of a link share) and therefore delay and stop weightings can be easily applied
directly to them. However, the stop and delay weightings that can be applied to traffic streams
will apply the weightings to all vehicles using that traffic stream, and unless it happens to be a
normal-only, bus-only or tram-only traffic stream, the weightings will be applied to the full mix
of vehicle types which will not allow weightings to be applied to favour normal traffic, buses or
trams.
Page 386


Figure 22-1 Vehicle weightings per path and traffic stream
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%.
Furthermore, TRANSYT provides a Per Path facility where weightings can be applied to each
traffic type using a particular TRANSYT path. This provides the required flexibility to favour
particular vehicle types using a particular traffic stream or using a particular path on a particular
traffic stream.
Optimisation selection 22.2
TRANSYT 14 offers a choice of optimisation processes Hill-climb, Shotgun Hillclimb, Simulated
Annealing, and of course None, for when you simply wish to evaluate an existing set of timings.

Figure 22-2 Choice of Optimisation Process
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.
The following sections describe each of the processes in turn.
Hill-climb optimisation process 22.2.1
First, 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. 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 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). 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.
Page 388

Green times can be optimised by selecting the optimisation Level Offsets And Green Splits
introducing 1 increments into the list, in which case each stage change time at a controller
stream is altered by one second at a time, whilst the remaining stage change times stay fixed.
This has the effect of varying the durations of the green times. The recommended (and default)
values for use on Hill climb increments for offsets and Green Splits optimisation are:
15 40 -1 15 40 1 -1 1
A fourth level of hill-climb optimisation (Extended - Offsets And Green Splits) is provided which
introduces larger negative increments into the list (see Figure 22-3)., 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.

Figure 22-3 Optimisation levels
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.
Shotgun hillclimb process 22.2.2
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 22-4 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 22.2.1 on the
Hillclimb Optimisation Process.
Simulated Annealing process 22.2.3
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

Page 390

constraints, such as minimum green requirements and are capable of handling the traffic are
suitable.

Figure 22-5 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.
Optimisation when using time-varying flows 22.2.4
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.
Optimisation of green times 22.3
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.
TRANSYT is also 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.

Locked Green Splits 22.3.1
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. A comma-separated list

is provided to allow the locked controllers to be set (Data Outline: Network Options >
Optimisation Options). N.B. if all controllers streams were to be added to this list it would be
equivalent to setting the global optimisation level to Offset only and de-selecting the
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.
Initial signal settings 22.4
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.
A previous method of calculating initial timings, called EQUISAT, is no longer used routinely as a
signals option, but has been retained for backward compatibility reasons. EQUISAT timings can
still be set via a Tool on the Timings Diagram. EQUISAT timings can be set for the current
controller stream or for all controller streams in the network.
EQUISAT calculates the green times for the various stages at a controller stream, so that the
degrees of saturation on the critical conflicting links are equal. The initial offsets for the change
times of stage 1 are assumed to be zero.
Queue-length reductions
3
22.5
The user may have particular situations where it is necessary to prevent a queue from reaching
back from one junction to another, thereby blocking the upstream junction. This complex effect is
not modelled when using the traditional PDM model in TRANSYT which assumes that all vehicles
queue at the stop line. (See section 20.2 on CPDM and section 20.4 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 links (or TS) 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 Links > Link n > Modelling (or the Queue Limits tab,
within the Links Data screen) or Traffic Streams > Traffic Stream 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

3
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 15.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 22.2.1.
Page 392

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.
Setting limit queues 22.5.1
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.
Maximum Queue Storage 22.5.2
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 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.

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.

Degree of Saturation limits 22.6
The ability to control the optimisation process in order to achieve a particular outcome is very
useful. To this end, TRANSYT 14 has introduced a the ability to control the resulting Degree of
Saturation on any link or TS 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 22-6 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.
Controller Stream groups (Node Groups) 22.7
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 a controller
stream list of (10 -11 -6 21) will result in controller streams 11, 6 and 21 being grouped and
optimised together.

Page 394

Offsets can be optimised in this way but optimisation of green times will not be performed on
negative controller stream groups. The green times at controller streams included in a
controller stream group will, however, be altered by the Auto Distribute routine if this option is
selected to give initial signal settings.
Grouping controller streams, so that their offsets are altered together and not individually, can be
used when an area is too large to optimise in one computer run and the area must be broken
down into sub-areas. Controller streams on the boundaries between sub-areas can be optimised
initially as part of one sub-area and then included as a group (keeping their relative offsets
unaltered) in the optimisation of an adjacent sub-area. Controller streams grouped in this way
are unaffected when TRANSYT optimises the green time distribution between stages.
TRANSYT provides the option to include a controller stream more than once in the optimisation
sequence. Thus, the offsets and green times for an individual controller stream can be optimised
as well as the offsets only for a group which includes that controller stream. This facility may be
useful when two or more controller stream are constrained, usually by being close together, to a
rather limited range of acceptable signal timings; the ability of the optimiser to minimise the
network Performance Index is likely to be enhanced by this process.
Cycle time selection 22.8
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 22.9)
provides information for a wide range of cycle times for each controller stream; 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 21.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.
Cycle Time Optimiser 22.9
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 at each controller stream; 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 graph option.
The calculations are based on full runs of TRANSYT, i.e. all nodes 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 Controller Stream Table indicates which controller streams are currently single, double, triple,
or quadruple cycled. The controller stream table can be hidden using the Hide Controller Streams
button.

Page 396


Figure 22-7 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. 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 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 link (or TS) data
will be changed. It is usually wise to backup 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.
The Min Practical Cycle Time is defined as the lowest cycle time which will result in no links (or
TS) exceeding the DoS threshold, i.e. an all green bar chart.

Multiple cycling and repeated greens 22.10
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.
Multiple cycling 22.10.1
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.
Multiple cycling can also be of use when attempting to model specific stages that come in only
every second, third, or fourth cycle (e.g. a pedestrian stage). In order to model this effect you will
of course need to double, triple or quadruple the cycling on all the controller streams which are
running during EVERY cycle while leaving those not coming in every cycle as single-cycled.
Equal-length and unequal-length multiple-cycling 22.10.2
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, (Outline: TRANSYT Network > Network Options > Signals Options).
Page 398


Figure 22-8 Base stages

The original stages (which are repeated) are called Base Stages in order to differentiate them
from the virtual copies of these stages.
Unlike versions prior to TRANSYT 13, which converted unequal-cycled repeat
stages into real TRANSYT stages, TRANSYT re-creates these virtual repeat stages
every time TRANSYT is run. On the Links 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.
Repeated greens 22.10.3
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 easily investigated using TRANSYT 14s
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.

Considering the effect of small changes 22.11
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.
Small changes to flows 22.11.1
A flow scaling factor can be applied to all links in the network in Common Data or to individual
links using the Link Sensitivity Multiplier.
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 200%. Flows for
individual links can be scaled within the range 5% to 2000%.
The global flow scaling factor and the local Link Sensitivity Multiplier effects are added together.
Small changes to cruise times and cruise speeds 22.11.2
A cruise time / cruise speed scaling factor can be applied to all links (and traffic streams) in the
network in Network Options > Traffic Options or to individual links in Links > Link n > Link Flows
or traffic streams in Traffic Steam > Traffic Stream n > Flows.
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 links (or TS) 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. This
differs from versions prior to TRANSYT 13, where the use of a local scaling factor would override
the global value.
Small changes to stop and delay weightings 22.11.3
The Links (and TS) 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 can be used to negate the effect of any weightings
specified. Thus, it is possible to investigate the effects of changes to these weightings upon
the Performance Index and timings.
The P.I. results are presented with and without the effects of all of the different types of
weightings, so that the true P.I. is always available. This avoids the need to carry out non-
optimised runs with the weightings cancelled in order to produce a P.I. for, say, cost-benefit
use.

Page 400


Modelling Examples Page 401

Modelling Examples 23
This chapter describes a number of example files 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 examples described in this chapter make use of the PDM. For CTM
examples see chapter 24, Modelling Signalised Roundabouts.
The Chapter 24 examples also include the use of the Flow Allocation Tool 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.

Supplied Data Files 23.1
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. Accompanying explanatory notes may be included with the files as text
documents in the same folder, or in the Description field of the File Description data item.
For further examples and documentation that may be added following product release, please
see the TRANSYT 14 section of our website at www.trlsoftware.co.uk. (Select Products from
the top menu and then select TRANSYT 14.) The More Information button links to product
sub-pages that may be of interest.

Figure 23-1 Additional website examples and advice

Page 402

A small network (Example 1) 23.2
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 23.2.16. The example is designed to demonstrate several of the
facilities in TRANSYT, while NOT suggesting normal values for any of the parameters used.
Explanation of certain aspects of the TRANSYT model, data and results is made while the data
file (containing results) is supplied with the software (TRL1 optimised LANES.T14, a link
equivalent file TRL1 optimised LINKS and also a variation using a Wide-Area OD Matrix
(TRL1 optimised LANES with ASSIGNMENT.T14 ).

Figure 23-2 A small network build with lanes
(TRL1 Optimised LANES .T14)

Controller Streams and Traffic Nodes 23.2.1
Unlike previous versions of TRANSYT, signal controlled junctions are controlled explicitly by the
Controller Stream NetCon 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 13).
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)
Give-way control 23.2.2
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.
You may notice that there is a right-turn movement out of the side road. This movement, in this
example does not exist, but the Priority Object adds this movement automatically. This is not an
issue, as the flows on that movement are set to zero and will have no influence on the results.
At node 1, right-turning traffic from the South (TS 17/2) is given a green signal during stage 2
but must also give way to opposing flow (TS 13/1) from the North. During stage 3 an unopposed
right-turn for TS 17/2 traffic is provided.
Arms, Traffic Streams and Lanes 23.2.3
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.4.
There are 20 arms, 21 traffic streams and a total of 26 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.
Page 404

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.
Buses and pedestrians 23.2.4
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.
Links P31 and P32 represent pedestrians using the crossing at node 3 - Traffic streams are
unnecessary for modelling pedestrians and are therefore disallowed. As there are pedestrians
crossing in both directions this representation, using two links, is the technically correct one.
The links have been placed either side of the junction to represent the true location of pedestrians
waiting to cross the road.
However if you do not plan to model the effects of pedestrian movements within your model and
only wish to visualise the existence of the crossing, a single link would suffice. It is common
practice to place the link straddling the conflicting link when not explicitly modelling pedestrians.
In recognition of this there is a NetCon right-click option to turn the link into a double-headed link.
This is purely a graphical change and does not influence the model.
Queue Limits 23.2.5
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.
Flared approach 23.2.6
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 defined as CPDM links in order to model any blocking
that may occur due to one or the other lanes filling up.
Average flows 23.2.7
The inflows to each traffic stream and the total flows are shown on the diagram in units of
PCU/hour. Flow consistency is provided by the compulsory use of the Flow Allocation Tool.
Discrepancies due to missing paths are quickly identified by examining the Resultant Flows.

Flow Allocation Tool 23.2.8
The flow allocation simplifies assigning traffic flows to traffic streams (and links) 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.
Saturation flows 23.2.9
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 assumed to be 8000 persons/hour of green.
Link length and speeds 23.2.10
Link 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.
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.
Delay and stop valuation 23.2.11
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).
On the pedestrian links (Links P31 and P32) delay and stops weightings are set to 60% as no
vehicle costs are involved and a smaller proportion of pedestrians than vehicle occupants are
assumed to be working: pedestrian stops will, in any case, be given a low valuation as this
depends on the cruise speed given to traffic using the link, as explained in section 21.3.
Cycle selection 23.2.12
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.

Page 406

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.
Optimisation 23.2.13
A standard sequence of change increments is used to optimise offsets and green durations as
specified in the Network Options > Optimisation Options. 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.
Final settings 23.2.14
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.
Graph plots 23.2.15
A number of graph plots of cyclic flow patterns (as described in section 15.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 option, it can be seen that the peak outflow from the give-way is during low-flow periods on the main
controlling link 2. You will also notice the capacity of the give-way does not dip low enough to affect the traffic on the
give-way. Any queueing on the give-way is due to random traffic behaviour predicted by TRANSYT.

Note how the saturation flow is shared with the buses on links 21 and 22, hence why the flow rate during the first part of
each green is not quite at the full 3600 saturation flow rate, i.e. the usual flat OUT-profile plateau is not present.

The yellow annotation highlights spare capacity during green

Page 408


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.
Link equivalent of the same small network 23.2.16

Figure 23-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.3.
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.6) 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.

Equivalent small network with Wide-Area Assignment 23.2.17

Figure 23-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. Three 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 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 the complete network or one per
junction. It all depends on what flow data you have and how you wish to assign traffic to the
network. Of course, the use of a wide-area matrix is also purely optional.
Page 410

You may also notice that there are two entry points to the network that are not included in the
wide-area these are the pedestrian links at Traffic Node 3. It is up to you whether or not you
wish to include them. However, in this situation there is no reason or benefit of doing so, as the
pedestrians links are not part of a larger network and so there is no network choice of routes for
the pedestrians to make.
Although the flows specified in the wide-area matrix are the same as those in the one local OD
matrix of the TRL1 example files. The wide-area assignment process has resulted in different
flows through each junction (local OD matrices). Therefore, TRANSYT results are also different.
However the general performance is similar due to the limited choice of routes that exist within
the network.

Modelling Signalised Roundabouts Page 411

Modelling Signalised Roundabouts 24
About this chapter 24.1
This chapter incorporates all of the advice previously given in RR274 (Lines and
Crabtree, 1990) and further updated in AG48 (Binning et al, 2003) and AG63 (Binning
et al, 2008). The advice and guidance has been updated to reflect the changes that
have taken place in modern junction design and in the way TRANSYT 14 works.
One significant change that makes life much easier in building a model is the direct
representation of lanes in 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 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 14 to
understand the way in which previous models have been built.
Introduction 24.2
At roundabouts, it is common practice to signalise one or more entry arms in an effort
to reduce delay and increase capacity. TRANSYT 14 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
TRANSYT such as link weighting, the shared link facility, and queue penalties, the
program can be used to model traffic behaviour on the roundabout, control queue
Page 412

lengths, and find signal timings such that queues do not form to block upstream
junctions. Modelling using either CTM or CPDM can also aid 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.
The TRANSYT program 24.3
Several features of TRANSYT 14 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 24.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 20.4).
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.
Modelling a roundabout (Example 2) 24.4
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
24-1. Further examples based on real-life sites are described in section 24.6 and
section 24.7.
The units used throughout the report are passenger car units (PCU).
Other units may be substituted (vehicles for example) with the
qualification that flow and saturation flow should be in the same units
for a given link or traffic stream.



Figure 24-1 Site diagram of a four-arm roundabout

Cycle time 24.4.1
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. The default range is 30 to 180 seconds,
with an increment of 1 second. It is advisable to change the range to avoid making
too many runs, many of which will be unnecessary.
Traffic stream structure 24.4.2
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 414

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 24-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.
Prior to TRANSYT 14, the model consisted of links. A link-share (i.e. a major link and
set of associated minor links) is directly equivalent to a traffic stream introduced in
TRANSYT 14. Because there will be many existing TRANSYT network models,
TRANSYT 14 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 24-2 and
Figure 24-4)
Modelling using links 24.4.3
The link diagram in Figure 24-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 24-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 21.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 416

Figure 24-1, Figure 24-2 and Figure 24-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 (f
13
and f
14
) and a proportion of this (f
13
) 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 24-3
(a). Of the two platoons only the proportion which entered at node 1 and continuing
to node 4 (f
14
) will continue to stop line Y--Y. This traffic alone should flow into the
downstream link 32.
It is possible to model two entry flows separately using the shared link facility in
TRANSYT. If vehicles that are turning out of the roundabout before the next node
(f
43
) are modelled as a minor shared link, then the fixed proportional reduction for
circulating traffic can be applied to the newly entered traffic only (f
13
and f
14
). 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 24-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 f
43
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
+ f
14
+ f
43
) -
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 24.6.


Figure 24-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 418

Modelling using traffic streams 24.4.4
From (Figure 24-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 14, and is largely
hidden from the user.
The model using links above (Figure 24-2) has not included the modelling of exit
traffic. With the advent of TRANSYT 13 and its more graphical presentation, the
modelling of exiting traffic became more relevant. It is likely that modelling of exit
traffic will become even more of an expectation, and it is required if the OD matrix
flow entry method is to be used. Exit arms are demonstrated in Figure 24-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 24-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 24-4 Traffic stream diagram for four-arm roundabout


Figure 24-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.
Flared Approaches 24.4.5
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 sections 8.5, 21.7, 21.8 and 21.9 can be represented. The CPDM 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
Page 420

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
24-4). The blocking of the short lanes at the stop line is modelled and traffic
upstream of the flare is restricted from reaching the short lanes once the latter are
full. CTM can be used for the same purpose. CPDM is generally for use only when the
short lanes are short (i.e. under 30 metres).
Saturation flows 24.4.6
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.
Entry arms 24.4.6.1
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.
Circulating arms 24.4.6.2
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.
Measuring saturation flows 24.4.6.3
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 24.4.6.2.
Blocking back 24.4.7
As already discussed, it is important that queues on circulating 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 24.4.1. The use of
the limit-queue facility and the effect of increased demand are discussed below.
Page 422

Limit queues 24.4.7.1
One method of discouraging the formation of queues on circulating links is to use the
limit queue facility under Arm > 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 22.5.1) are often appropriate.
There may be occasions when, despite a high penalty, the limit queue on circulating
links is still exceeded. This can occur because in order to reduce queues on a given
link, TRANSYT must increase the green time for the stage in which the circulating link
receives green. This can only be at the expense of entry link(s) that run in the other
stage, and some of these entry links 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 links
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 link 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 might still be useful for this. It is more
important to ensure they are applied selectively and the consequences understood.

Excess Demand 24.4.7.2
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 links
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 links.
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 links 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 link in the network. It then multiplies these by the value of
delay and the cost of stops for each link to produce an overall Performance Index for
the optimiser to minimise. Unless specific action is taken to weight particular arms,
this process treats them all as being equally important and, for individual nodes, will
distribute spare green time between arms.
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 links. 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
arms run at between the desired 85 to 95 per cent saturation, leaving any spare
capacity to the circulating arms. Adjust the values if necessary.
This low weighting factor may not be appropriate where the entry arm 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 arms, 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 arms 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 links, with degrees of saturation below 90% ideally, so that blocking back to
upstream nodes is unlikely to occur. To do this in TRANSYT, after completing the
optimisation runs, simply switch the optimisation to none, 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
links.
Blocked Links 24.4.7.3
When optimising the signal timings and, in particular, the node offsets, the PDM does
not take into consideration whether any links are blocked or not. This means that
situations can arise when TRANSYT produces signal timings that would discharge
traffic from an upstream link straight into a queue on a short downstream link.
Page 424

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 link. The model can
then release traffic into a blocked link 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 links can therefore be poorly
co-ordinated. In such situations signal timing offsets between adjacent signals may
have to be adjusted manually. The use of low limit-queue values and high queue
penalties will generally keep queues shorter and prevent this happening (see section
24.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 and CPDM models should
ensure that the signal timings minimise problems with unsuitable offsets.

Checking co-ordination 24.5
Once the final timings have been derived, it is usually worthwhile to obtain Cyclic Flow
Profile (CFP) or CTM 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 link, round the roundabout, to final
exit to see where red signals are encountered. Graphs are also useful to check links
which require special co-ordination.
If using the 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.


Example 3 a signalised motorway roundabout 24.6
The example roundabout shown in Figure 24-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 24-7.
This diagram gives 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
CPDM in order to model the junction portrayed in the most accurate manner.
Modelling the junction 24.6.1
Traffic stream structure 24.6.1.1
As discussed in section 24.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 CPDM 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 426


Figure 24-6 Site diagram of a signalised motorway roundabout



Figure 24-7 NetCon diagram for a signalised motorway roundabout

Flows 24.6.1.2
The Origin/Destination flow matrix is given in Table 24-1. This shows the flow from
each entry to each exit during the period under consideration.
Page 428

Table 24-1 Origin-destination matrix for signalised roundabout

To Node

From
Node
1 2 3 4 5 6 Total
1 - 220 100 46 124 166 656
2 38 - 132 149 197 146 662
3 231 197 - 132 134 148 842
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

The Flow Allocation Tool in TRANSYT 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.
Weighting factors 24.6.1.3
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.
Limit queues and queue penalties 24.6.1.4
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.
Cycle time 24.6.1.5
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 links. Use
the various graphs and the animation facilities to examine platoon progression.
Please note that because the 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.
The TRANSYT output 24.6.2
Normal flows 24.6.2.1
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 60% to 73%. Ideally, it would be better if 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 45% for 10/1, 81% for TS/2, 60% for 62/1 and 38%
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.
Excess demand flows 24.6.2.2
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%. The roundabout has survived this test with no obvious
problems; except for motorway-fed traffic stream 10/2 which is oversaturated and
has a mean queue of 20 PCU is predicted for the one hour period. A quick
examination of the advanced result Max End of Red Queue EoTS (End of time
segment) shows that a queue at the end of the hour could be reach approximately 29
PCU in two lanes (i.e. approx. 15 per lane). Depending on how long the slip road
might be, this could be longer than that and may need further attention. The other
motorway entry slip road, link 40, is not as oversaturated.
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 430

Graphical outputs 24.6.3
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 NetCon representation of the network. In
explaining the TRANSYT output for this particular example, most of these have their
part to play.
NetCon output 24.6.3.1
The following figures are generated using TRANSYTs Network Construction Editor
(NetCon). 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 24-8 Network diagram showing Mean Max Queues

NetCon 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 24-8 uses
NetCon to show mean maximum queues (in orange) as a proportion of the link 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 half of the time.

Figure 24-9 Links on green/red
Figure 24-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 running at node 2.
Page 432


Figure 24-10 Value Comparison Tool

Figure 24-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
NetCons 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.
Traffic Model considerations 24.6.4
The motorway roundabout example described above has been modelled using
primarily the Cell-Transmission Model (CTM). The flared approaches are modelled
explicitly, using the CPDM 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 24-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 24-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 type 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 links (or TS) 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 434

Example 4 an urban signalised roundabout 24.7
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.
Description of the roundabout 24.7.1
The roundabout is triangular in shape (see Figure 24-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 24-12 Site diagram of the Walton Street roundabout, Aylesbury

Modelling the junction 24.7.2
The diagram in Figure 24-13 and the TRANSYT input data (see TRANSYT file TRL4 -
Walton Street - AM peak.t14) show how the roundabout has been modelled. The
O-D option 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 24-13 Link diagram for the Walton Street roundabout

Saturation flows 24.7.2.1
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
Page 436

represents the single-lane part of the approach; then to model the two lane portion
with a standard (signal controlled) lanes. The method is more appropriate for
situations where the lanes at the stop line do not share a common movement; hence
the use of the two lanes is likely to be uneven. The CTM will automatically deal with
the uneven use, even when the lanes run in different phases (which is not the case
here).
Choice of cycle-time 24.7.2.2
Finding the most appropriate cycle-time is an important factor in a roundabout type
network. The Cycle Time Optimiser (Section 22.9) 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 links
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
Weighting factors 24.7.2.3
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 24.4.7.1). In this example, some of 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.
Limit queues and queue penalties 24.7.2.4
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 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 link 21.
Note that blanket application of limit-queues in not recommended. Simply applying
them to all circulating links would be expected to fail to work at some links. It is
better to find out where the problems exist and apply limit-queues sparingly until
queues form where they cause minimal problems.
TRANSYT output 24.7.3
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
link shows that the aim of giving spare green to circulating links has been achieved.
If any internal traffic streams had been over-saturated it would have been necessary
to put this oversaturation onto the entry links 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.
Excess demand flows 24.7.4
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 27 and 37 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.
Predictability of traffic flows 24.7.4.1
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 links, 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
Page 438

arms all had long queues during at least some part of the peak period. On the
oversaturated links, the flow into the roundabout was controlled by the green-time. If
the green-time had been too long, too much traffic would have entered the
roundabout, probably leading to locking-up.
Recommendations 24.8

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-
360
O
rotations (if they not expected to be used). The OD Matrix options 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 CPDM to model flared approaches, but watch out for modelling
inaccuracies.

- Use CTM 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 NetCon to check co-
ordination and queueing behaviour.

- Compare flow patterns, degrees of saturation and cyclic flow patterns with the
on-street behaviour (and re-model the junction if necessary).

Definitions / Glossary Page 439

Definitions / Glossary 25
TRANSYT 14 GUI Terms 25.1
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 NetCon on Link 1, for example, will make Link 1 the Active Data Item in TRANSYT.
The link will be highlighted in NetCon, 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 14 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 NetCon.
Several Library building block files are supplied with TRANSYT. See Library Files for
more details.

Page 440

LTS
An abbreviation for the phrase Link and/or Traffic Stream. 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.8 for more details.
TS
An abbreviation for Traffic Stream. Used as short-hand in both TRANSYT and the
User Guide.

Modelling and Traffic Engineering Terms 25.2
Please also see section 25.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.
A
1
and A
2
coefficients
No longer used in TRANSYT 14. 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 14 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 NetCon.
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.
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
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.
Page 442

Common cycle time
This value is the 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).
(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 14. 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 TS movements) form part of the give-way model in
TRANSYT. They are the traffic streams (or TS 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 the 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 link (or TS) 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 link or TS as a result of them having to queue
up and stop because of the signals at the junction at the downstream end of the link
or TS, or because of having to give-way at a priority junction.
Delay weighting (link or traffic stream)
This is a weighting given to delays for a link. It is used to deter the optimiser from
producing signal timings which give unduly high delays for selected links. Conversely,
it may be used to encourage the optimiser to increase delays.
Displacement - Relative Start Displacement
This is a local (link or TS) 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.
Page 444

Displacement - Relative End Displacement
This is a local (link or TS) 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 14.
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 leaving
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.
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.

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, but has been retained as a Timings
Diagram option, for backwards compatibility
(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 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 link (or TS),
the arrival and departure flow at the stop line for each step of the cycle.
Give-way bottleneck
A give-way link or TS 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 446

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 time
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 and
each link references up to two controlling phases, the TRANSYT-specific Link
intergreen term used in earlier versions, 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 (Link) start lag
This is used to model the lag between the TRANSYT stage change time and the start
of green on a link (also known as the intergreen). The Start Lag affects the modelled
actual green time and NOT the effective green. To model link effective green times
see Relative Start Displacement.
Lag (Link) end lag
This is used to model the lag between the TRANSYT stage ending and the end of
green on the link, e.g. it is used to model phase lags. The End Lag affects the
modelled actual green time and NOT the effective green. To model link effective
green times see Relative End Displacement
In versions prior to TRANSYT 13, before the creation of separate link
effective greens (i.e. relative green displacements) and actual greens
(start and end lags), this value was used for both actual and effective
greens. It was most commonly used to modelling effective green
extensions, e.g. clearance of right-turners during the intergreen. These
should now be explicitly modelled using CPDM traffic streams or
specified as relative green displacements.
Lane
New to TRANSYT 14, 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 (or TS). 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

Page 448

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 using the Flow Allocation Tool. 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 Flow Allocation Tool. At least two WIDE-AREA locations
will normally be required.
(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 17.2.3.
Mean maximum queue
The average position of the stationary vehicle furthest from the stop line each cycle,
measured in number of PCUs 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.

(Traffic) Node
This TRANSYT graphical representation of an intersection. In modelling terms it
largely irrelevant now in TRANSYT 14. However it is still useful in identifying the
physical junction that traffic passes through, allowing the junction to be
manipulated more easily in NetCon, and provides a mechanism to get TRANSYT to
produce results for each junction.
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 450

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
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.
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.
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 optionally be excluded from contributing to the Performance Index
calculations. They can also be explicitly identified in TRANSYT, e.g. drawn differently
in NetCon.
Performance Index
This value represents the overall costs incurred by vehicles on links (or TS). 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
link (or TS). In reality, some traffic travels faster, some slower, than this average.
To take account of this, the TRANSYT model takes flow entering a link or TS and
disperses the platoon as it travels down the link or TS. This models the variation in
vehicle cruise speeds as they progress down the link or TS.
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 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.
Page 452

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.
No longer needed when using the new TRANSYT 14 link blocking model or CTM model
- Retained for backward compatibility purposes only.
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 link (or TS). 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 link or TS. 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 link (or TS).
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
new TRANSYT 14 term Link Share.
Shotgun Hill climb
Shotgun hill climbing in TRANSYT is an optimisation technique where different initial
signal timings are selected more-or-less randomly and run one after the other, using
the standard hill-climbing process. Any run that improved the objective (P.I.) will
automatically replace the existing one. This is an effective way to improve the overall
optimisation process, as in many cases, the extra time required to carry out multiple
runs is repaid in significantly better results. It is essentially a trade-off between
speed and performance the more runs you do, the better potentially are the results.
The benefits are largely file-specific as there is no guarantee that different starting
points will produce significantly better results.
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.
Page 454

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.
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 results report 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.
Page 456

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

References Page 457

References 26

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, 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 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.
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.
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.
Page 458

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 Page 459

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.

Page 460

Appendix A Import TRANSYT 13 files 27
Import files from TRANSYT 13 by selecting File>Import>From TRANSYT13 and then
browsing to the .T13 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 NetCon in TRANSYT 13 and
TRANSYT 14, the network may not appear exactly as it did in TRANSYT 13.
- There is no longer a T12Mode in TRANSYT 14, 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 14
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 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 14 cell saturation flow is set to the highest value
of the TRANSYT 14 default (for the cell satflow) and the imported maximum
flow value.
- Due to the extended options that TRANSYT 14 now offers you may wish to
review/examine your imported file to ensure that you making best use of
TRANSYT 14 and that you are modelling your network in the best way possible.

Appendix B Export to TRANSYT 13 Page 461

Appendix B Export to TRANSYT 13 28
Exporting a TRANSYT 14 file to TRANSYT 13 format is possible by selecting
File>Export>To TRANSYT 13. After generating the export file (.T13 format), you
may be shown warning and/or information associated with the conversion process
that you need to be made aware of.

TRANSYT 14 contains new data items compared to TRANSYT 13 and so clearly not all
data can be successfully exported to TRANSYT 13, e.g. traffic streams; shared links
that have different give-way data.

Some data items that are represented differently in TRANSYT 13 will be automatically
converted on export to the equivalent representation, e.g. links that do not have a
restricted flow and are not a give-way (i.e. unrestricted links) are translated into
bottlenecks with a saturation flow of 9999, as this is how such links would have been
set up in TRANSYT 13. Controller stream data will be moved to the traffic node.

If you know in advance that you will be exporting a file to TRANSYT 13 it is
recommended that you use the Quick PDM traffic model in TRANSYT 14, as this
represents the nearest equivalent to the model used in TRANSYT 13 and should
ensure consistency of the TRANSYT results, assuming the same signal timings are
used in both products and the latest releases of both products are used. Quick
Flares should also be used to model flares because the more modern method, which
uses the CPDM model, cannot be exported back to TRANSYT 13.

Page 462

Appendix C - Importing from TRANSYT 29
7-SET/10/11/12
Import files from TRANSYT 7-SET, 10, 11 or TRANSYT 12 by selecting
File>Import>From TRANSYT 7-SET/10/11/12.. and then browsing to the .DAT file.
During the import process you may be shown one or more warning messages or given
options about how to import certain items.
If the TRANSYT 12 file has an associated TRANSYT 12 NetCon (.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 NetCon (.nce) file was supplied, then TRANSYT 14 will load this in
and position nodes and links according to this file. Given the difference in appearance
between NetCon in TRANSYT 12 and TRANSYT 14 however, the network may not
appear exactly as it did in TRANSYT 12.
If no NetCon file was supplied, then showing a NetCon window in TRANSYT 14 will
auto-arrange the network into a circular shape.
Check the Task List after importing, as there may be warnings and errors that would
not have shown up in TRANSYT 14. In general, TRANSYT 14 checks for more
problems than does TRANSYT 12, therefore a file that ran in TRANSYT 12 may show
errors or warnings in TRANSYT 14.
N.B. Data items that are represented differently in TRANSYT 14 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 14 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 14. If in doubt, please send your data file(s) to TRL for comment.
By changing the Files of type: from TRANSYT 12 (*.dat) to
TRANSYT 7-SET you can use this facility to import Dutch .IN files.
Appendix C - Importing from TRANSYT 7-SET/10/11/12 Page 463

Page 464

Appendix D Importing from 30
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 14 checks for more and different problems than does TRANSYT-7F.
Furthermore, due to differences in the two products, TRANSYT 14 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 14.
A summary of, to what extent data is imported from each TRANSYT-7F Record Type is
as follows:
Imported? Record Type Record Description
Fully

2 Optimisation Node List
7 Shared Lanes
1X Controller Timing
18 Controller Timing
2Y Phasing Data
*

2Z Phasing Data Continuation
28 Link Data
30 Performance Index (PI) weighting
34 Queueing Capacity Modifier
35 Cruise speed multiplier
36 Volume Multiplier
37 Delay Weight Multiplier
38 Stop Weight Multiplier
39 Platoon Dispersion Factors
40 Flow Profile Diagrams
42 Arterial Routes
Route Title Card
61 Route Link
70 Node Coordinates
Intersection Name Record
Appendix D Importing from TRANSYT-7F Page 465

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 14 will load in and position nodes and links according to this file.
TRANSYT 14 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 14, 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 14.
Network-wide start-up lost time is rounded to the nearest second when
imported as the network-wide Start Displacement. Similarly, the default
Page 466

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 NetCon. This can be due to the following:
o NetCon 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 NetCon.
There are no arterials in TRANSYT 14 both arterials and routes are
imported as TRANSYT 14 routes.
The direction of routes (forward/back) is not specifically recorded in
TRANSYT 14 Therefore, the direction of imported reverse routes are
retained by recording the direction in the TRANSYT 14 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 14 stage due the difference in how
TRANSYT-7F phases and TRANSYT 14 stages are defined - TRANSYT
stages include the preceding interstage.
Because the opposed right-turn model in TRANSYT 14 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.
Finally, there are many modelling options that are in one product but not the
other, e.g. the Cell Transmission Model in TRANSYT 14 and the various permitted-
Appendix D Importing from TRANSYT-7F Page 467

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.

Page 468

Appendix E Importing SCOOT data 31
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 14 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 31-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 31-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 vehicles per hour; hence you should
also define your Saturation Flows in TRANSYT using the same units.

Appendix E Importing SCOOT data Page 469


Figure 31-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 470


Figure 31-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 31-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 Netcon Flow consistency overlay) will clearly
show where source flows (i.e. turning proportions) are required.

Appendix F Importing SCATS data Page 471

Appendix F Importing SCATS data 32
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 14 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 32-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.
Page 472


Figure 32-2 Associating TRANSYT Links with SCATS Detectors
On selecting Tools>SCATS>Import SCATS Volume flows the following dialog box is
displayed, that allows the Peak Start time, Peak Length and which folder contains the
SCATS flow data (i.e. the File Directory) to be entered.
Additionally the format of the filenames of the files containing the required flow data
must also be entered. TRANSYT will search all files with a filename matching the
defined format in the specified folder, e.g. Using the format Set {0}.txt will search
for data within Set 057.txt, Set 164.txt, etc.

Figure 32-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 32.1.
Appendix F Importing SCATS data Page 473


Figure 32-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 Netcon Flow consistency overlay) will clearly
show where source flows (i.e. turning proportions) are required.
Creating data files from SCATS data 32.1
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.

Page 474

The output file should look like this:

TRANSYT 14 User Guide PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TRANSYT 14 User Guide PDF

Загружено:

Авторское право:

Доступные форматы

TRL

APPLICATION GUIDE 65 (Issue J)

Вам также может понравиться