Professional Documents
Culture Documents
TRANSYT 15
USER GUIDE
by James C Binning
TRL Software
Crowthorne House
Nine Mile Ride
Wokingham Berkshire
RG40 3GA United Kingdom
Software manufactured
under an ISO 9001 Tel: +44 (0)1344 770758
registered quality Fax: +44 (0)1344 770356
management system E-mail: software@trl.co.uk
www.trlsoftware.co.uk
The information contained herein is the property of TRL. Whilst every effort has been
made to ensure that the matter presented in this document is relevant, accurate and up-
to-date at the time of publication, TRL cannot accept any liability for any error or
omission.
The copyright in this material is held by TRL Limited and cannot be used for commercial gain or
reproduced unless authorised/licensed by TRL Limited.
ISSN 1365-6929
The pedestrian behaviour at traffic signals modelling algorithm used within this program is used
under licence from Transport for London.
SCOOT is co-owned by TRL Limited, Imtech Traffic & Infra UK Ltd and Siemens Traffic Controls
Ltd.
SCATS is a registered trade mark of the Roads and Traffic Authority of New South Wales in
Australia and other countries
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.
Other products and company names mentioned herein may be the trademarks of their respective
owners.
This Application Guide provides a comprehensive users guide to the latest version
of TRANSYT software (TRANSYT 15) issued by TRL. It has been updated to include
details of the changes made since TRANSYT 14; in particular the addition of a
pedestrian crossing model which is capable of modelling the walk-on-red behaviour
of pedestrians, enhanced modelling of time-varying traffic conditions, and other
extensive enhancements to both the traffic model and the fully-interactive graphical
interface.
E-mail: software@trl.co.uk
--------------------------------------------------------------------
Webinars: www.trlsoftware.co.uk/webinars
Videos : www.youtube.com/TRLSoftwareChannel
--------------------------------------------------------------------
E-mail: traffic@trl.co.uk
12 Working with Analysis Sets, Demand Sets and Time Segments ........... 177
10.8 Viewing and visualising data in the network diagram ...................... 148
12 Working with Analysis Sets, Demand Sets and Time Segments ........... 177
17.4 Using an Arm, Traffic Stream and Lane Structure ........................... 297
17.5 Steps required using arms, traffic streams and lanes ...................... 297
24.5 Differences between the Flare models (CPDM and CTM) ............... 416
1 Introduction
The timings of signals at road junctions have an important effect on the levels of traffic congestion
not only at the junction itself but at surrounding junctions which may or may not have signals
themselves. Often the junctions in urban areas form part of a network of co-ordinated signalised
junctions. By co-ordinating groups of signals within a network, substantial reductions can be
made to queues and delays. Each group of signals are operated on a common cycle time. Their
relative green times are set so that known average volumes of traffic can travel through the urban
area with as little delay and as few stops as possible.
Please note that the term traffic mentioned above should be regarded as including non-vehicular
movements through the network such as those of pedestrians, who can also benefit from good co-
ordination and also from thoughtful provision of pedestrian facilities in general.
The main TRANSYT method has, as shown in Figure 1-1, two main elements; the traffic model and
the signal optimiser.
The model represents traffic behaviour in a network of streets in which one or more junctions are
controlled by traffic light signals. The model predicts the value of a Performance Index for the
network, for any fixed-time plan and set of average flows that is of interest. The Performance
Index is a measure of the overall cost of traffic congestion and is usually a weighted combination
of the total amount of delay and the number of stops experienced by traffic.
The optimisation process adjusts the signal timings and checks, using the model, whether the
adjustments reduce the Performance Index or not. By adopting only those adjustments which
reduce the Performance Index, subject to a number of constraints, such as minimum green,
signal timings are successively improved. The model also provides for give-way priority control
possibilities, including the modelling of opposed offside-turn traffic within signalled junctions and
fully unsignalised junctions which are influenced by nearby signals.
Signalised and partially-signalised roundabouts can be modelled and their delay minimised by
calculating timings which reduce blocking-back by keeping the circulating carriageway free
flowing.
The delays to pedestrian traffic at signals are also modelled, including their gap-accepting
behaviour when the signals presented to them are red.
TRANSYT, at the time of writing, can model up to 200 nodes and 1000 links within a network.
TRANSYT is suitable for both drive-on-the-left and drive-on-the-right operation.
Many of the principles behind TRANSYT 15 are essentially the same as those at the heart of
previous versions of the program. However, TRANSYT 15 brings with it a number of significant
modelling changes as well. All of these changes are described in detail in other chapters.
Although existing users of previous versions will identify many modelling changes, concessions
have also been made to those familiar with previous versions of TRANSYT, where we thought it is
useful to do so.
For those wishing to evaluate the differences between TRANSYT 15 and earlier versions, such as
TRANSYT 12, we recommend you contact TRL who will be more than happy to explain whatever
features you are most interested in.
Please browse through this User Guide for information about the
many new features in TRANSYT 15, looking for the following symbol:
To achieve these aims, this user guide describes, in separate chapters, how to get started
quickly with TRANSYT 15, all graphical interface features, the theory and research incorporated
in TRANSYT and how a TRANSYT model should be specified (including guidance on how to
measure data). Also described is the output and how it should be interpreted. A number of
examples have been included to aid in the understanding of individual junctions and the
modelling problems they pose.
Whilst it is desirable to read as much of each chapter as possible, it is accepted that sufficient
time will not always be available. Hence the earlier chapters concentrate on all the essentials
needed to get started with TRANSYT, with reference within these earlier chapters to other
sections of the guide where more detailed information is provided.
The following icons are used throughout to highlight relevant points about the topics being
covered.
In many places it is inevitable that jargon will have been used, which include general traffic
engineering terms, specific TRANSYT terms and terms relating to features of the graphical
interface. To help avoid repeated explanation of such words and phrases a glossary of terms is
included (see Chapter 29).
The graphics within this document assume drive-on-the-left situations. However, the terms
nearside and offside have been used throughout, instead of left or right to allow
understanding for both drive-on-the-left and drive-on-the-right situations.
1.4 Training
TRANSYT, by its very nature, is a complex software product. Although we try to make our
product as easy to use as possible, and also provide this comprehensive user guide, we
acknowledge the demand that will exist for training courses and the benefits that training can
provide to both those totally new to TRANSYT and also existing users.
TRL run training courses for many of the software products it sells, including hands-on courses
on TRANSYT. We use the most recent releases of our products and we use only experience
trainers usually TRL members of staff who have many years of experience. As the developers
of TRANSYT we can offer unrivalled training in its use.
Several screens are watermarked to identify it as a student edition. The reports are also
watermarked and its header also indicates the report has been produced with a student edition.
Details on availability and pricing can be obtained from TRL Software Sales or your local
distributor.
1.6 Languages
The standard version of TRANSYT is produced in English. However other language versions have
been developed or are in the process of being developed. If you wish to find out what language
versions may be available, or you are interested in assisting/collaborating with our translation
program, please contact TRL Software.
TRANSYT Online
TRANSYT Online extends TRANSYT's functionality and allows optimised Signal Plans to be sent
directly to on-street controllers to allow frequent retiming without the need to go out on the
street in response to events. TRANSYT Online hosts a range of features, including the import of
live flow data into your TRANSYT network, regular scheduled signal optimisation, plan
deployment (automatic, timetabled or manual), and a variety of powerful features to support
plan creation, selection, deployment and monitoring.
and edit signal plans for an Aimsun network. Versions are available for TRANSYT 14 (Version 1)
and TRANSYT 15 (Version 2).
PICADY is for predicting capacities, queue lengths and delays (both queueing and
geometric) at unsignalised major/minor priority junctions. It is an aid in designing new
junctions as well as assessing the effects of modifying existing designs. PICADY includes
accident prediction.
and
ARCADY is for predicting capacities, queue lengths and delays (both queueing and
geometric) at roundabouts. It is an aid in designing new junctions as well as assessing
the effects of modifying existing designs. ARCADY includes accident prediction.
For further details of all these programs, and for latest news, current pricelists and purchasing
information, please visit www.trlsoftware.co.uk.
TRANSYT has continued to be developed by TRL ever since its first release. TRANSYT 15
represents another significant advancement of the product in terms of its traffic models, its
features, and its presentation.
TRANSYT 15.0 (released in September 2013) is the first release of TRANSYT 15.
It is useful to the user of any product to know whether or not the particular release they are
using is the most up-to-date available. In order to provide this information automatically, on
launching TRANSYT, it will try to connect to the TRL Update Information Server. If this
connection is achieved and/or permitted by the user (permanently or as a once-off), the bottom
horizontal status bar will display news concerning TRANSYT such as NEW TRANSYT 15.0.0.99
Version Available (as shown below) or No Update Information Available
The displayed text is simply the title of the full information available on our server. Clicking on
the link will bring up the full message.
If having read about a new release you wish to download it, current maintenance holders can go
to the TRL download system at http://www.trlsoftware.co.uk/downloads and follow the
instructions on the web page.
1.9 Acknowledgements
The work described in this report was carried out in the Transportation Division of the Transport
Research Laboratory. The authors are grateful to all those who carried out the development,
technical reviews, auditing and testing of this software product. The authors are also grateful for
the documentation associated with earlier versions of TRANSYT and to their authors.
The authors also thank the Department for Transport, Energy and Infrastructure, South Australia
for providing advice on creating the required data files from SCATS for subsequent import to
TRANSYT.
We would also like to thank Transport for London (TfL), UK who commissioned and funded the
original research and initial product implementation of the pedestrian behaviour at signals
model. The pedestrian behaviour at traffic signals modelling algorithm used within TRANSYT 15
is used under licence from Transport for London.
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.
6 GB RAM
TRANSYT 15 may run on versions of Windows other than Windows 8/ 7/ Vista and XP but this is
not guaranteed and is not formally supported.
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.
There are currently three states of TRANSYTs copy protection system stand-alone copy-
protection, network copy-protection (concurrent licence version) and Demo/Viewer. Usually,
versions are licensed on a per-site basis. Licences may also be time-limited, i.e. a Leased or
Evaluation licence.
Both the stand-alone and network copy-protection states are contained within the same
installation package, and the selection of which type to register (Network or Stand-alone) is part
of the registration process - Your selection must match the licence type you have
purchased.
ARCADY and PICADY and the TRANSYT LINKS can be registered from within
TRANSYT using the main menu option Help > Manage Licences. Please note
that when checking or changing the status of network versions of any of the
listed products, TRANSYT may take a few extra seconds to respond as it
awaits confirmation of the licence state.
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
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.
Note: It is assumed that the reader is familiar with traffic engineering terms such as phase,
stage and stage sequence. For those new to the subject, or wishing to clarify, please see
section 29.
1. There is a cyclical nature to the traffic flows in the areas of the network where
there are traffic signals. (Unsignalled junctions can be set to assume random
arrival patterns).
2. All coordinated signals have a common cycle time or a cycle time a half, third or
quarter of this value; details of all signal stages and their minimum periods are
known. Different (non-multiple) cycle times can be defined within the one
network but no coordination is assumed at any boundaries between the parts of
the network that are running on different cycle times.
A TRANSYT traffic stream is made up of one or more TRANSYT lanes. TRANSYT lanes will in
general have a one-to-one relationship with real lanes on-street. However, TRANSYT links do
not have a one-to-one relationship with real lanes on-street, and generally represent particular
movements of traffic and/or types of traffic.
Each traffic streams and link has a number of properties that define their behaviour (and their
effect on traffic). For example, a signalled traffic stream will have the properties Has Restricted
1
time varying traffic conditions can also be modelled in TRANSYT
Flow and Is Signal Controlled set to true. Has Restricted Flow allows a saturation flow rate
to be specified (see section 3.5.5). Unsignalled restrictions within the network such as a
bottleneck can be modelled by setting Has Restricted Flow but set as unsignalled. A
description of how each of these types of traffic stream and links is represented graphically in
TRANSYT is in section 10.5.
When using both traffic stream representations and link representations within the same
network, each differently-represented part of the network must be connected with a simple
one link into one stream or one stream into one link. That is the only restriction. You
can have as many discrete sections of the network build with the two structures as you like.
In general, one traffic stream is required to represent each distinct queueing situation that occurs.
Thus, trivial queues may not warrant representation by a separate traffic stream. However, a
separately-signalled offside turn traffic stream, with a significant flow, should be represented by a
TRANSYT traffic stream which is separate from the traffic stream representing straight ahead
traffic. One traffic stream may represent two or more lanes, provided that traffic is equally likely to
join the queue in any of the lanes and that identical signal indications are shown to these lanes.
This traffic stream representation suggests that a detailed knowledge of traffic routing through a
network is necessary to prepare the link diagram. In practice, it is usually sufficient for the traffic
engineer to use his judgement to decide whether traffic entering a section of road during a
particular stage green chooses preferentially a particular direction on passing through the next
signal and, if so, the proportions of various turning flows to assign to each traffic stream.
The relationship between lanes on the road and the way these lanes are grouped together to form
TRANSYT traffic streams is illustrated in Figure 3-1 and Figure 3-2. Figure 3-1 shows a simple
triangular road network. Figure 3-2 shows the corresponding diagram of nodes, traffic streams
and lanes. Traffic on the southern approach to Node 1 is represented by two separate traffic
streams because nearside turning traffic (traffic stream 13/1) receives a different green time
(because of a filter signal) to the other traffic (traffic stream 13/2) on the approach. On the
northern approach to Node 3 traffic is also represented by two separate traffic streams (32/1 and
32/2). This gives a more realistic picture of traffic movements, since offside turning traffic from
link 21 is unlikely to turn right again at Node 3. Finally the westbound traffic arriving from location
3 is represented by one two-lane traffic stream as the queueing situation is likely to be even since
the straight ahead traffic (a major movement) can utilise both lanes.
In general, one link is required to represent each distinct queueing situation that occurs. Thus,
trivial queues may not warrant representation by a separate link. However, a separately-signalled
offside turn traffic stream, with a significant flow, should be represented by a link which is separate
from the link representing straight ahead traffic. One link may represent two or more lanes,
provided that traffic is equally likely to join the queue in any of the lanes and that identical signal
indications are shown to these lanes.
Just like the alternative TRANSYT traffic stream representation, the link representation suggests
that a detailed knowledge of traffic routing through a network is necessary to prepare the link
diagram. Again, in practice, it is usually sufficient for the traffic engineer to use his judgement to
decide whether traffic entering a section of road during a particular stage green chooses
preferentially a particular direction on passing through the next signal and, if so, the proportions of
various turning flows to assign to each link.
The relationship between lanes on the road and the way they are modelled as links is illustrated in
Figure 3-3 and Figure 3-4. Figure 3-1 shows a simple triangular road network. Figure 3-4
shows the corresponding diagram of nodes and links. Traffic on the southern approach to Node 1
is represented by two separate links because nearside turning traffic (link 13) receives a different
green time (because of a filter signal) to the other traffic (link 12) on the approach. On the
northern approach to Node 3 traffic is also represented by two links (31 and 32). This gives a
more realistic picture of traffic movements, since offside turning traffic from link 21 is unlikely to
turn right again at Node 3 and will chose the nearside lane catering for traffic that is turning left or
going straight on.
700
800 650
(J.T. = 30 sec)
300
700
200
N
J.T. = Average journey time
* All flow units in pcu/hour
All saturation. flows = 1800 pcu/hour
700
22
11 350 21 400
600 1 2
50 300
(left filter) 50
300
350 450 31 32
13
350
50
12
400
33
250 3 700
100
2 Intersection
or node
22
Link (No. 22)
3.5.1 Lengths
Traffic Stream (or Link length) is the distance between the upstream and downstream stop lines.
For traffic streams (or links) which do not come from an upstream node, e.g. entry traffic stream
(or link) on the perimeter of the network, it is normal to use a length such as 100m or 200m.
Although a zero value may be used, it is not recommended as some TRANSYT results will make
use of this value for their derivation and this can result in some artificially high or low outputs.
Lengths are specified using either the data editor (Data Outline: Arm n > Traffic Streams > Traffic
Stream m) or the (Traffic) Streams data screen (See Figure 3-5).
The Auto Length option allows you to let TRANSYT work out the length of any
traffic stream (or link) automatically for you from the distances between items in
the network diagram. If this useful feature is used, your network diagram should
be scaled to ensure that distances correctly reflect real on-street distances.
Traffic flows are either specified directly using the method described below or are assigned via
OD Matrices. See Chapter 13 for full details of how to allocate flows to the network using OD
Matrices. A mixture of these options is allowed if using a link structure, so parts of the network
can have assigned flows and others flows entered directly. However any parts of a network
structure defined using arms and traffic streams must use OD Matrices to calculate the traffic
flows.
Where an OD Matrix is used, its data options (traffic flows; allocation mode and allocation type
selections) is used to calculate and automatically assign values to the Total Flows and Source
Flows within that part of the network covered by that particular OD-Matrix.
How flows are assigned directly to links is described in the following section.
3.5.2.1 Links
Link flows are specified in the Links Data screen (Outline: Links > Link n > Flows). Flows are
normally specified in PCUs or vehicles per hour. For each link the user must specify the average
total flow along the link.
Each link may have associated with it a uniform flow source (see Figure 3-7). This is a flow
source which enters the link at a uniform rate throughout the cycle. Thus, there is no
platooning. It can be used to represent, for example, uncontrolled flow from a car park. Links
feeding into the network from outside also carry uniform flow but these flow levels are set using
the Source Flow and associated Total Flow for the link. The Uniform Flow Source is used only
when there are other upstream flow sources. The uniform flow source contributes along with the
upstream sources to give the total flow, but need not sum exactly (see compatibility of link
flows, section 3.5.4).
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 are the un-delayed times (or speeds) for traffic travelling from
each upstream stop line (for each source traffic stream or link) to the stop line on the currently
selected traffic stream (or link). The values used should be those which correspond to actual
traffic behaviour and not an ideal value intended to give good progression; they should
represent the time taken to travel from upstream to downstream stop line, under prevailing
traffic conditions, when the signal aspects at both ends of the stream (or link) are green. It is
possibly better to measure cruise time (as opposed to cruise speed) because it ignores any error
in traffic stream (or link) length measurement, and by measuring over the whole traffic stream
(or link) it automatically takes into account skin-friction, curves, bottlenecks etc.
3.5.4 Compatibility of link and traffic stream entry and exit flows
The sum of inflows to link need not equal the total flow. This facility is provided because in
practice the flow values will often be obtained from on-street measurements made at different
times. TRANSYT automatically increases or decreases by the same proportion all upstream flow
values so that the total flow is maintained. If the proportional correction is large a message is
printed as a warning but the run of the model still proceeds. The flow consistency diagram that
is integrated in both the traffic stream data and link data screens can be used to investigate the
source of any unacceptable inconsistencies.
The calculation of the proportions of traffic leaving upstream links (or streams) and entering
downstream links (or streams) are made before the traffic modelling and signal optimisation
calculations. If, in the traffic modelling process, a link (or stream) is oversaturated so that less
traffic leaves than enters, then the downstream volumes are reduced accordingly and the flows
specified as the Total Flow will not be maintained.
Saturation flow is the maximum rate of discharge across a stop line during green while a queue
remains. At existing sites the saturation flow can be measured. On the other hand, when
planning a new junction or major alterations, the saturation flows have to be predicted from
other known quantities such as stop line lane widths and other site factors.
The prediction of saturation flows is covered in TRL Report RR67 (Kimber et al, 1986) which
describes large scale studies into saturation flow carried out between 1982 and 1986. From
these studies, empirical formulae have been derived from which it is possible to predict
saturation flow for a given set of junction parameters.
Saturation flows need to be specified for most traffic streams (or lanes) and links. It is not
required where all traffic makes use of the give-way max flow throughout the cycle does the
TRANSYT model not use the saturation flows value, i.e. a pure give-way with all traffic opposed.
It is also not required for unrestricted traffic streams and links, which are used where no
restriction to traffic is present, such as those exiting the network.
TRANSYT applies these formulae when using the Use RR67 option either in traffic stream Lane
data (Outline: Arm n > Traffic Stream m > Lanes > Lane p) or major link data (Outline: Link n).
When calculating the saturation flow for a major link (link share), the number of lanes it is
representing is needed, so that there is somewhere to specify the lane-specific data required for
the RR67 calculations. Minor links do not require any RR67 data.
Site Quality Factor: This can be set to Definitely Poor, Average or Clearly
Good. For more detail on this factor see RR67. N.B. Used by traffic streams
only.
(Road) Surface Condition: This can be set to either wet or n/a. n/a is the
default and indicates that this parameter is ignored within the model This is not
quite the same as saying the road surface condition is dry. N.B. Used by traffic
streams only.
Proportion That Turn (%): This is the percentage of traffic on the lane that
makes any turning movement (left or right). If the turning proportions change,
say, due to changes you make to the O-D Matrix, you should also update these
values.
Turning Radius (m): The radius of turn is the approximate radius of the circle
described by vehicles as they make a turn, and should be left blank for straight
ahead movements. If there is both a left and right movement on the lane, enter
the smallest (tightest) radius.
Nearside Lane: Tick this box if the lane is regarded as a nearside lane.
The Use Connector Turning Radius option allows you to let TRANSYT work out for
you both the proportion that turn and the turning radius automatically for you from
the network diagram. This option has a particular advantage over specifying the
values directly, as it will ensure that the values will always reflect the allocated
traffic flows in the network whenever these change.
If this useful feature is used, your network diagram should be scaled to ensure that
distances correctly reflect real on-street distances.
For entry traffic streams (and links) on the perimeter of the network, having no upstream links
(or streams) but merely a total flow it is recommended, in order to maintain a reasonable
estimate of time spent within the network, to input a cruise time (or speed) for travel over the
Length of link (or stream) specified in the Sources Data screen (Outline: Links > Link n >
Sources or Traffic Streams > Traffic Stream n > Sources. No source traffic stream (or link)
should be defined. The use of the Cell transmission Model (CTM) on entry traffic streams (and
links) offers no advantages and will slow down runs of TRANSYT so it is best to use PDM for such
items.
Exit links are not required by TRANSYT unless using OD Matrices to allocate flows to it,
but can be useful if the direction of traffic exiting the network is to be shown graphically. If
using traffic streams, exit traffic streams are compulsory. In order to maintain a reasonable
estimate of time spent within the network, a cruise time (or speed) associated with the travel
time along the link is required. If you wish the exit link to have no influence on either the signal
optimisation or on the queue and delay calculations the Link Data screen option Exclude from
Results Calculation can be set. This effectively ensures that the PI for the link is always zero
and that output results, such as the Network Totals, are not affected by it.
If you do not want any queues to appear on exit links (or streams), both the Has Restricted
Flow and Is Signal Controlled options should be de-selected. This ensures an infinite capacity
(unless using CTM) and indicates to anyone looking at the network that the traffic stream (or
link) is being used in such a way that it does not act as any form of restriction to traffic flow, or
you dont care about what is happening at the downstream end of it. If using CTM, the cell
saturation flow can still affect traffic flow, so should be set to an appropriate value (see section
18.3).
Bottleneck traffic streams (or links) are unsignalled links which do not give way to other traffic, but
are restricted in some way. They are treated as if they are controlled by a 100 per cent green
signal at which a fixed saturation flow is defined. A bottleneck traffic stream (or link) is treated in
a similar way to other traffic streams (or links) it is usually associated with a traffic node for
display and reporting purposes (either as a true bottleneck or as part of a priority junction), but no
controller stream is specified as it is not controlled by traffic signals.
Shared links which are bottlenecks are specified in the Shared Stoplines tab of the Links Data
screen (Outline: Links > Link n), in a similar way to signalised links, but the main link still has
only a traffic node and no associated controller stream.
Delays and stops are calculated for bottleneck traffic streams (or links) exactly as for other traffic
streams (or links, except that the flow leaving the traffic stream (or link) is controlled only by the
saturation flow. Thus, uniform delay and stops will occur only if the flow during parts of the
IN-profile exceed the saturation flow. Random-plus-oversaturation delay and stops are calculated
in the normal way (see section 25.2).
TRANSYT models the operation of the signal control at each controller stream by reference to its
own stage change times. A TRANSYT stage change time is a time at which the green signal on
one stage is terminated and the change to the next stage green period is initiated; the next stage
green usually commences a few seconds later, following an interstage period. The green time
displayed to traffic on any one link may be initiated by any stage change and terminated by any
other stage change.
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.
Distance
Change to Change to
stage 1 stage 2
Change to Change to
stage 1 stage 2
Time
Arbitary zero for time
If the offset value at one node is subtracted from that at an adjacent node, the difference in
offset defines the start of the cycle at one node relative to that at the other and hence defines
the co-ordination along any links connecting the two nodes.
TRANSYT models the response of traffic to the actual signal changes by using effective green
times as opposed to the actual stage greens as explained later (see section 3.5).
The values which must be specified to define the signal timings at each controller stream in the
network are defined either for the whole network or for each individual controller stream as
follows:
These values are specified in the Main (Common) Data Screen (Outline: Network Options).
The network cycle time for the whole network is specified in seconds (Outline: Network Options
> Network Timings).
The effective green displacements (start and end), to be applied to the whole network, are
specified in seconds (Outline: Network Options > Signals Options). Both the start and end of
effective green used in the model may be made to occur a few seconds after the actual signal
stage change by specifying displacements of fixed duration. These displacements apply to all
traffic streams and links in the network. Figure 3-9 illustrates this concept.
The intention is that the displacements specified in the Main (Common) Data represent the inertia
of drivers and vehicles in responding to signal indications, compared with TRANSYTs
instantaneous stop/starts. The start displacement corrects for the time lost accelerating from rest
up to cruise speed. In the UK this value is typically 2 seconds, but a larger value would be
appropriate where the before green (starting) red-with-amber period is omitted.
D1 D2
Red/Amber Amber
The global end displacement corrects for traffic continuing to flow during the end-of-green amber
period as though the signal were effectively green. In the UK this value is typically 3 seconds
(equal to the full duration of the amber period). TRANSYT models traffic behaviour using effective
green periods which are typically 1 second longer than, and displaced relative to, the actual green
signal.
Additional relative displacements may be specified for individual phases - See section 3.6.3.5.
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.
Traditionally TRANSYT stage change times have been defined as the times at which a change of
signal aspect is initiated, as opposed to the genuine start of stage which starts only when the
last phase running in that stage, starts. TRANSYT now uses the later genuine definition;
however, it can (optionally) report some resultant timings using the older definition. These are
always in addition to the genuine times and are prefixed with the word TRANSYT, e.g. TRANSYT
Stage minimum.
The calculated stage minimum, plus the phase minimums and phase maximums all act as
constraints used by the TRANSYT signal timing routines, to prevent a stage or a phase having an
unduly short or long green time. A combined value in the range of 10 to 15 seconds is normal for
vehicular traffic but pedestrian crossing needs may dictate longer times.
For a pedestrian stage, the minimum green period is the time from the end of the interstage
period to the end of the green man indication, or the end of the pedestrian black-out if this
exists. For pedestrian-only stages, the TRANSYT optimiser will typically choose the minimum
stage length unless the pedestrian costs are set to contribute to the Performance Index. This is
because no vehicular traffic flows during the pedestrian stage so there is usually no dis-benefit
seen by the optimiser when the stage length is reduced.
Interstages need not be specified as these are derived from the phase intergreens
and phase gaining and losing delays. The interstage is specified in seconds and is
defined as starting from the termination of the first phase to lose green when a
stage change is made (it also signals the end of the stage) to the commencement
of the green for the last phase to receive green in the next stage. TRANSYT
produces an interstage matrix that allows every possible interstage to be viewed,
and also edited via the Timings Diagram, if required.
Minimum and maximum green times can also be specified on each individual phase in order to
constrain phase lengths to what is required.
Traffic stream (or links) may receive green for all or part of one or more stages. The time at
which the actual green begins is determined purely by when the phases actually run, and these
are determined by the user by specifying which stages they run, and whether or not there are
any phase delays. Phase delays alter when a phase will start or end relative to the stage it is
running in This could result in the phase starting early or ending late. N.B. a phase starting
later than any other phase, or finishing earlier than other phase defines the actual
start and end of the stage.
Internally, various parameters are derived from the user specified information and used
internally by the TRANSYT model. A network option can be set that reveals some of these
parameters in the Resultant Stages Data. Generally, they are only of interest to those
previously familiar with these parameters. Details of these parameters are in the TRANSYT 15
Outputs section 21.2.9
Should the traffic stream (or link) have a second green, the corresponding values detailed above
for the first green will also be derived by TRANSYT for the second one.
Figure 3-10 Absolute phase gaining delay and phase losing delay
The displacements in the Main (Common) Data and the relative displacements are added
together in the program to give the effective green times before the queue calculations are
carried out. For example, if the global network start displacement (see section 15.8) is 2 seconds,
and it is known that for the phase being considered, the effective green displacement is one
second longer than the overall value, then the required relative start displacement is simply 1
second.
However, all effective displacements are subtracted from the calculated green times before these
are output in the results (see section 21.2) so that the traffic engineer can easily compare
TRANSYT values with observations of actual green times.
Furthermore, a negative relative start displacement (say -2 seconds) could be used to justifiably
remove or reduce the standard start displacement in situations where good coordination has
resulted in the front of a platoon of traffic arriving during a green signal.
To model traffic behaviour within the network using these models, the common cycle time is
divided into a number of intervals called steps. For convenience, a step is typically set to be one
second long. How these steps are used depends on the model used.
With the PDM model TRANSYTs calculations are made on the basis of the average values of traffic
demand and queues for each step of a typical cycle. The resultant histograms of traffic arrivals
per step are termed cyclic flow profiles.
The profile of traffic entering a link will be displaced in time and modified during the journey along
the link due to the different speeds of the individual vehicles. Thus, platoons of vehicles will be
partly dispersed. The amount of dispersion can be modified for individual links.
By selecting the PDM model, TRANSYT automatically takes into account the importance of having
good progression on short links.
The CTM model also uses steps but is it also discrete in space as well as in time. As a result the
CTM cyclic flow profiles are different and are differently presented. The representation of traffic is
therefore different to the PDM model.
The CPDM model has an additional blocking capability that allows it to be used to model situations
flared situations. It can be considered as a superior replacement for the Flare model that was in
previous versions of TRANSYT. See section 3.12.
The CPDM model is NOT directly user-selected within the program instead the components of a
flare (the short lanes) are defined as flares and the program will use the most appropriate blocking
model that is required this will either be CTM or CPDM. Overall flare results are then reported on
the feeding traffic stream or link.
All the models use a simplification of real traffic behaviour, and do not model individual vehicles.
Despite this, TRANSYT is able to predict good estimation of traffic delay.
Full details of the data required for these models are given in chapter 24.
When considering the growth and decay of queues, the fact that individual vehicles arrive at
random, and that average arrival rates may vary over the modelled period, means the accurate
modelling of queues is complicated. The problem was studied comprehensively by TRRL (Kimber
and Hollis, 1979) and a time dependent method of predicting queues and delays was developed.
The method considers the probability distribution of queue lengths as a function of time.
Queue lengths are derived from cyclic flow profiles during each step of the typical cycle. As well as
this uniform component of queue, additional elements associated with random and oversaturated
effects are added to these. Full details of queue length derivation are described in Section 25.2.1.
TRANSYT also calculates the total rate at which vehicles are forced to stop on a link. This too, is
made up of a uniform component and a random-plus-oversaturation component. As for delay,
the uniform component is obtained from the cyclic flow profiles and the
random-plus-oversaturation component is calculated from simple equations.
It is generally a good idea to attempt to remove or reduce blocking before trying to model these
blocking effects themselves.
TRANSYT computes a mean maximum queue (PCU); this value is estimated from two
components as follows. During the typical cycle (see section 3.7) modelled in TRANSYT, a check
is kept on the position of vehicles adding onto a queue (measured in numbers of PCU back from
the stop line rather than in distance units). During a green period, traffic discharges from the
front of the queue but further traffic may join the back of the queue. The maximum back of
queue is the position (in PCU) reached by the back of the queue just as the queue empties (see
Figure 3-11). This value is an average obtained assuming that arrivals each cycle are identical
to that modelled during the typical cycle and is known as UMMQ, uniform component of the
MMQ. The second component is the average random-plus-oversaturation queue (numerically
equal to the random-plus-oversaturation delay on the link), which is added to the maximum
back of queue to give the reported value.
Stop line
0 4 8 12 16
time
The second component is a correction to the maximum back of queue value which makes some
allowance for variations in queue size from cycle to cycle. It may be thought of as the average
number of vehicles which fail to discharge at the end of the cycle, although, in reality, this may
be zero or a larger number during individual cycles.
The mean maximum queue (PCU) is only an approximate average of the maximum queues likely
to be encountered, and it will therefore be exceeded a sizable proportion of the time.
In TRANSYT there are three types of priority situations that may need to be modelled. The first
situation is a give-way junction (priority intersection) located somewhere between the signal
controlled junctions. This can include unsignalised approaches to partially signalised
roundabouts.
The second situation occurs is a give-way junction (priority intersection) located downstream of
a nearby signal controlled junction that affects the drivers behaviour at the give-way due to their
knowledge of the signal states. A clear example of this is a nearside filter lane that allows traffic
to bypass the signalled junction and then has to give way to traffic fed from that same junction.
The third situation occurs within a signal-controlled junction i.e. traffic on a link which, although
signal controlled, must also give way to an opposing flow. Such situations occur frequently at
signalled junctions where the offside traffic turns without a separate signal indication.
In all of these situations TRANSYT is able to take account of the varying opposing (controlling)
traffic conditions that the opposed (give-way) traffic has to yield to, and calculate the required
queue, delay, stop, and other performance information.
Additionally, when using the CTM traffic model, congested give-way situations can also be taken
account of.
Full details on how to model these give-way situations are in the chapter 17 and section 25.5.
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).
The user of the program must decide how many classes of vehicles are necessary to represent
the conditions being studied. Each class of vehicle at a common stop line is represented by a
separate shared link. For vehicles in a given class at the shared stop line, TRANSYT calculates
the delay for that class taking into account delay caused by the interaction between all vehicles
using the shared stop line.
Shared stop lines can be applied to both signalled links and give-way links.
When representing your network using traffic streams and lanes instead of links, you should use
the facility within the OD Matrices to specify buses or trams separate from normal traffic.
1. One way is to use a traffic model that can model the blocking back effects associated with a
flare. Flares are modelled by setting the relevant traffic streams (or links) to use the
Flare traffic model. TRANSYT will then use the most appropriate traffic model that has
the required blocking capabilities, i.e. either the congested platoon dispersion model
(CPDM) or cell transmission model (CTM). A Flare traffic stream (or link) is, in essence,
something that has the ability to fill-up with traffic, and block upstream traffic entering it
due to its restricted length.
2. The second method is one which has been traditionally used in TRANSYT, but which has
limited capabilities This involves the explicit creation of Quick flares to model flared
approaches. Using Quick flares, provides the mechanism to model the extra capacity
available from flared approaches, i.e. have an extra lane or lanes at the stop line. The
non-linear saturation flow is of the stepped form shown in Figure 3-12. It contrasts with
the constant, single valued, saturation flow for non-flared links or traffic streams.
sat.
flow
0 green time
For further details on modelling flares see chapter 16. This includes examples of the various
cases where flares are used. The custom screens used for data-entry of flare data are shown in
section 8.3 and 8.4.
4 Optimisation Basics
This is only a brief overview of the TRANSYT optimiser. Details have been kept to a minimum in
order to keep the emphasis on getting to know how to use TRANSYT quickly, providing just
enough background prior to using TRANSYT. However, TRANSYT is a complex program, so there
are references to other chapters. These chapters will still need to be read in order to know how
to use all the optimisation facilities correctly.
It works by applying a cost to the amount of delays, stops and excess queues on each link which
is summed to provide an overall cost of the network for a particular set of timings. These
timings are then manipulated bit-by-bit in search of timings giving a lower overall cost.
Although TRANSYT offers a choice of a number of different optimisation techniques the objective,
described above, is still the same. One of the techniques that can be employed is called hill-
climbing because the set of solutions, if plotted, could be thought of as a series of hills and
valleys in a multiple-dimensional world. The solution found will be at the bottom of one of the
valleys. Full details of the calculation of Performance Index (P.I.) and the hill-climbing process
are explained in chapter 26
Before optimisation, TRANSYT must have a starting Performance Index calculated from an initial
set of signal timings. A feature called Auto Redistribute creates an initial set of stage timings
that will be valid, which can be run to produce the starting Performance Index.
The controller streams which are to be optimised are listed in the advanced item Optimisation
Order (Outline: Network Options > Optimisation Options > Advanced > Optimisation Order). By
default, this list is automatically populated with all controllers within the network, but this can be
overruled. If a controller stream is omitted from the list its initial settings will not be altered
Irrespective of any local controller settings.
Thus, a network can be studied in which one or more controller streams within the network do
not have their initial settings altered and act as a constraint on the optimisation of the remaining
controller streams.
Alternatively, within the controller data ((Outline: Controller Stream n > Optimisation) both
offset and green split optimisation can be disallowed. Therefore, the green times can be locked
while still allowing the offset (start of stage 1) to be optimised for that controller. This will usually
be the easiest place to set such constraints on the optimiser, (see section 26.3 for more detail).
Furthermore, optimisation can be switched off entirely so that TRANSYT can simply run an
existing set of timings in order to evaluate the performance of the network for these timings. A
main menu run evaluation button is provided for this purpose in addition to the Run
TRANSYT (optimisation) button.
Note: the following is only a very brief overview. See chapter 6 for a general description of the
GUI and details of the menus and toolbar buttons. You are also likely to need to reference
various other chapters while working through this one, e.g. chapters 7 (TRANSYT 15 Input
Data),) 9 (Data Grids), and 10 (Network Diagram). For details of further program functionality
please browse through the rest of this User Guide.
There is no fixed route through TRANSYT, and as such it offers a high degree of flexibility when
creating a new network. In general, data can be entered in any order and changed at any time:
the graphical user interface (GUI) is highly dynamic and any dependent data and screens are
automatically updated.
it is recommended that you first start the program with Advanced Mode turned off (see section
6.5). This will hide some features of TRANSYT making it easier to get to grips with the reduced
number of inputs, outputs and features. This option is set when you run the program for the
first time, and can be subsequently changed via File Preferences or, for the current file, via the
Data menu. You will also find that, by default, a number of network options are switched off by
default. Leaving those items switched off until you want them will also make it easier to learn
TRANSYT.
Even with many features switched off or hidden, the open-ended nature of the TRANSYT GUI
may leave you wondering where to start so below is one suggested way to build a new file.
Please note that this is only a suggestion, and with experience, you will find your own
preferences and may well find yourself building files in a completely different order.
If in doubt, the Task List (see Task List) always shows any current problems with the
file. For example, if you show the Task List immediately after starting a brand new file, it will
show a list of errors and warnings similar to the screenshot below, which should give you an idea
of what needs to be done. Double clicking on a row in the Task List will often take you to an
appropriate screen.
When the program first starts, or you click File>New, a list of library files will be presented to
you. Simply select the one you wish to use as a starting point for your own network, or use the
browse button to select your own non-library file. If you press Start a New File, TRANSYT will
start off with a minimalist network, while Cancel will simply close the window without doing
anything at all.
Use the Data Outline (Data Outline), data editor and the toolbar icons to access each data area
and perform operations.
ALTERNATIVE: Custom screens (see vertical toolbar) can be used instead to enter almost all
data items and often make the data-entry process quicker and easier.
Although the Data Editor and/or custom screens can be used to enter most data it will often be
easiest to use the Network Diagram to build your network of traffic nodes, lanes (or links),
controller streams and O-D matrices, and then populate these with the required data. If you
make a mistake at any point, use the Undo/Redo buttons.
Therefore, assuming the use of the network diagram, a suggested order of data entry is as
follows:
1. In the File Description Area (via the Data Outline and Data Editor), Enter the project title,
location etc. and set the driving side.
Network Options
2. Use the View tab of the Main Data screen (or Outline: Network Options>) to select which
items you want hidden or shown in your file. TRANSYT files need a lot of data and present
a lot of results and therefore it is useful to be able to hide items you have no interest in.
3. Optionally, use the network diagrams Add a newJunction button to merge more
junctions into your network Thus saving you time (section 7.2).
4. Having merged all the files you wish to bring into your network, now connect the relevant
links and traffic streams.
5. For areas of the network that you wish to build without the help of the Library System, it
is suggested that you add all traffic nodes first (10.7.6), renumbering them and locating
them into their approximate position as required. Technically, traffic nodes are not always
required but do help when identifying junctions, can help when adjusting items within the
network diagram and can affect how many paths an OD Matrix generates. Traffic Nodes
have a visual representation dependent upon whether or not anything connected to it is
signalised.
N.B. you have a choice of constructing your network using arms, traffic streams and lanes,
using links, or a combination of both. Lanes are easier and more intuitive to use, require
the use of OD Matrices to assign flows to the network, and also hide the underlying
structure of the network.
If using traffic streams and lanes carry out steps 6 to 13 and if using links carry out steps
14 - 19.
6. Add all arms, locating them in the appropriate location between the relevant nodes as you
create them. N.B. Arms are really only containers for traffic streams, so have very few
properties. They are created with one traffic stream and one lane within that. Extra lanes
can be added by using the appropriate right-click menu item. TIP: New traffic streams
are always created on the offside of any existing traffic streams on an Arm. Similarly new
lanes are created on the offside of any exiting lanes - Use the Move Lanes mode to change
the order if necessary.
7. Add the required number of additional traffic streams and number of lanes within each
stream. Normally you will be specifying as many lanes as you have actual lanes on street.
In general, one traffic stream is required to represent each distinct queueing situation that
occurs. N.B. Using one traffic stream for every lane can often result in pessimistic results,
i.e. longer queues and higher delays. Lanes are a means to calculate saturation flows and it
is the traffic streams that are the most significant items. (If you are more familiar with
TRANSYT link structures, a Traffic Streams equivalent is a major link).
8. The traffic stream control type (e.g. signalled/unsignalled and whether or not it is a give-
way, etc.) can either be set using the appropriate toolbox tool, or, you can right-click on
the traffic stream after having adding it, to set the control type, etc. Traffic streams
leaving the network can be set as have unrestricted flow and not signalled.
9. Attach each Arm to its traffic Node using the ManipulateConnect tool on the diagram
bottom toolbar. These associations are shown with the blue cones; moving each traffic
node will now move all attached arms as well.
10. Create one controller stream for each genuine controller stream, and attach each
signalised traffic stream to the relevant controller stream using the ManipulateConnect
tool. This tells TRANSYT which controller stream controls the traffic for each signalised
traffic stream. These associations are shown with the green cones. By default, traffic
streams are connected to the nearest controller stream (if one exists) and to nothing
otherwise. The connector tool can be used to redirect connection to the right controller
stream.
11. Attach each traffic stream to its downstream traffic streams by using the connector tool in
the network diagram.
12. Either double-click on the traffic-stream to use the Traffic Stream Data Window to set up
any required properties such as give-way properties, lengths, and so on. Lengths can
either be entered manually or set to be calculated from the diagram. (For saturation flows
see the next step.) Alternatively, you can right-click on a lane (or traffic stream) and
select one of the Traffic Stream Properties. This will select the chosen data in the Data
Editor. N.B. If you choose the option to calculate Lengths automatically, you MUST scale
the diagram for these values to be accurate see 10.8.1.1 on how to do this.
13. Decide whether or not you wish to enter saturation flows directly for the traffic stream or
get them from the sum of the lane values. If you decide to derive them from the lane
values you now need to add saturation flows for each lane. For each lane, either enter
them directly or estimate from RR67 data.
At this point the Task List will still show a large number of errors but these should all be to
do with signals rather than network connectivity.
14. Add all links, locating them in the appropriate location between the relevant nodes as you
create them. To set the link control type (e.g. signalised/unsignalised) and whether or not
it is a give-way, pedestrian link etc.), you can either use the appropriate toolbox tool, or,
you can right-click on the link after adding it and then set the control type, etc.
15. Attach each Arm to its traffic Node using the connector tool in the network diagram.
These associations are shown with the blue cones; moving each traffic node will now move
all attached arms as well.
16. Create one controller stream for each genuine controller stream, and attach each link to
its controlling controller stream by using the connector tool in the network diagram. This
tells TRANSYT which controller stream controls the traffic for signalised links. These
associations are shown with the green cones; moving each node will now move all
attached links as well.
17. Attach each link to its downstream link(s) by using the connector tool in the network
diagram.
18. Set up any shared stop lines by using the shared stop line tool in the network diagram.
19. Double click on links and use the Data Outline and Data Editor to set up any required
properties such as give-way properties, lengths, saturation flows and so on.
At this point the Task List will still show a large number of errors but these should all be to do
with signals rather than network connectivity.
20. ALTERNATIVE: Use one or more Data Grid screens to rapidly enter data for all traffic
streams, links, etc. in one go (see chapter 9). This saves having to click on each item in
turn, especially if you have all data to hand in a tabular form. Tip: You can use the Shift
or Ctrl keys to make multiple selections in the same column and then right-click to change
all selected items to the same value (see screen capture below).
Traffic Flows
You have a choice to enter traffic flows directly or to use OD Matrices to assign flows to the
traffic-carrying items in the network. N.B. if using a link structure using an OD-Matrix is
optional, but it must be used if using a lane structure. It is recommended that each separate
OD Matrix should only be used to assign flows to one, two or three junctions (a signalised
roundabout counts as one junction) as otherwise the underlying structure within TRANSYT can
become very large (slowing TRANSYT down appreciably) and may then require route choice
decisions.
21. Use the network diagram to add an OD-Matrix (section 13.4) and then add the required
number of locations. (Locations are where traffic both enters and leaves the network.)
Using the Connect tool, attach each location to the traffic stream (or link) to which the
traffic will be entering the network and also attach the traffic stream (or link) to the
location which is flowing to that location, making sure to connect the locations in the right
order, i.e. location to entry, and exit to location.
22. Enter your flow data to the OD-Matrix and ensure that auto calculate is selected.
23. Check that the paths created by the OD Matrix are valid paths. If not, disable those that
are not, using the Allocation Type. Tip: You can use the filtering system to examine
just the paths to or from one particular location. This makes it a lot easier to
systematically check of any path are missing or need to be disabled.
24. Optionally set the Allocation Type to Fixed or Percentage in order to specify how much
traffic uses a particular path if appropriate for the model you are creating.
TIP: Use the Flow Consistency Diagram built into the Traffic Streams Data screen to check the
consistency of traffic crossing from one OD Matrix to another.
25. You can enter traffic flows and set up cruise times etc. by clicking on each link and source
in the network diagram and then entering the appropriate numbers in the Data Editor.
(Sources were referred to as upstreams in TRANSYT 12). Click on a link to view and
edit its main flow and uniform flow; click on a connector between links to set up the flows
between links.
26. ALTERNATIVE: Use the Links Data screen to view and edit sources for each link and all
flows for links. This screen incorporates a link consistency tool that allows you to identify
where discrepancies in your flows exist.
27. ALTERNATIVE: Use one or more Data Grids to view and edit all flows for all links (and
similarly for all sources).
Signals
You have previously created your controller streams and associated each signalled traffic stream
and link with the right one. You now need to define the signal data (phases, stages, sequences).
There are various ways of entering signals data - Some suggested methods are given below:
28. Add the number of phases you want using the Data Outline or open the Signals Data
screen, select the Phases tab, and click the Create New Phases button. Specify how
many you want, accepting that any existing ones will be removed. N.B. phases can be
added individually on this screen by right-clicking on the left-most column of any existing
phase.
29. Optionally, set the Phase Type. This makes it easier for others to interpret your signal
data and allows the colour coded timings diagram to display what type of phase it is. If
set, warning messages will also tell you if the phase is subsequently used inappropriately.
30. On the same tab, set any minimum greens or maximum greens you wish to define.
31. For each traffic stream (or link) use the network diagram (Right-click on controller
stream), Link Data Screen, Traffic Stream Data screen or Data Editor to set the Signal
Phases which define the signal conditions given to each traffic stream (or link). Up to two
phases can be associated with each traffic stream or link, which allows filters and turn
indicative arrows to be modelled. Note: the network diagram can only be used to set up
the first phase.
32. Use the Intergreen Matrix (Matrices on the vertical button bar) to specify which phases
conflict with each other this is done by entering intergreens. Note how the reciprocal
intergreens will auto-populate with zero intergreens as you type to ensure a conflict
always operates in both directions. A pale yellow background colour is used to indicate
where conflicts might exist, based on the existing signal timings.
33. Optionally, you can calculate an initial set of conflicts and intergreen values from the
network diagram geometry. If you do this, you must ensure that the diagram has been
scaled. It is also advisable to curve all connectors within the junction. On-street
observations should be used to ensure that the intergreen values specified are suitable.
34. Using the Signals Data screen, select the Stage Library Tab and click the Auto Generate
Library Stages button. This will automatically create in the Stage Library a collection of
all possible stages a stage for each valid combination of phases that can run together (
Outline: Controller Stream n>Stage Library). E.g. For the above example two Library
Stages would be created one with phase A and C running together and the other with
phase B and D.
35. 1st ALTERNATIVE: Using the Signals Data screen, select the Stage Library Tab. You
can use the Create New Library Stages button to specify how many stages you wish, and
then simply type your comma-separated list of phases you wish to run in each stage.
36. 2nd ALTERNATIVE: Open the Timings Diagram for the controller stream you wish to edit.
Within the Timings Diagram, click Tools>Reset and Create New Stages and enter the
number of required stages, or use the Auto Generate Library Stages option.
37. Using the Signals Data screen, select the Delays Tab. Click the Create New Delays
button to add any phase delays (gaining or losing) you wish to specify. Delays can be
specified for any stage transitions you like; hence why they can be defined before the
stage sequence is chosen. You may wish, however, to come back to this screen if you
only wish to define phase delays for your chosen stage sequence.
38. Select the Stage Sequences Tab. Either click the Auto Generate Sequences button to
tell TRANSYT to create a number of valid stage sequences. TRANSYT will populate the
data outline Stage Sequences with up to ten of the simplest staging arrangements. The
first in the list is selected automatically as the current sequence (i.e. the one referenced in
the traffic stream data).
39. ALTERNATIVE: Select the Stage Sequences Tab. Manually create the stage sequences:
One sequence is created automatically. Click on the column titles Stage IDs and enter
the stages in the order you wish to have them running in the sequence. To add more
sequences right-click on the left most column of the existing stage sequence and select
Add a copy of Stage Sequence 1 or Add a new Stage Sequence.
40. 2nd ALTERNATIVE: Select the Stage Sequences Tab. Click the Edit Stage Sequence
button. This launches the Stage Sequence Diagram. Drag and drop the stages within the
diagram to change the order of the stages to what you want. N.B. You can also re-define
the library stages used in the shown sequence by double-clicking on the red and green
phase arrows. (You can watch the effect in the Stage Library shown in the Data Outline.)
Right-click on any stage to add a new stage immediately before the one you clicked on.
41. 3rd ALTERNATIVE: Select the Stage Sequences Tab. Click the Edit Signal Timings
button. This launches the Timings Diagram. Right-click on each item in the diagram
(stages and green periods) and use the pop-up menu to add/delete stages or to redefine
which phases run in which library stage.
42. Set initial stage and phase times by dragging stages and phases with the mouse within
the Timings Diagram. Select either Stage Mode (the default) or Phase Mode to do this.
In Stage mode, stages are NOT automatically created, destroyed or redefined within the
diagram.
43. Optionally, Right-click on a controller stream to display a Timing Wheel for that
controller. You can check and edit stage change times from within the Network Diagram
by using Timing Wheels.
Network properties (NB you may prefer to set these at the beginning)
44. Use the Main Data screen (or Outline: Network Options>Network Timings) to select the
traffic model to use (PDM, CTM, etc.). A description of each of these is explained in
chapter 24.
45. Use the Main Data screen (or Outline: Network Options>Optimisation Options) to choose
which optimisation level you would like to use. Also select whether to apply the auto-
distribute (stage timings) routine as part of the optimisation process This is essential if
existing timings are not already valid.
46. Save the file and then press the Run button. If there are any errors in the data file, you
will be directed to the Task List to try to fix those errors before running the file.
Otherwise, TRANSYT will start to run and the Running Calculation screen will keep you
informed of progress by showing a status bar and the best P.I. found so far. Note: For
small networks and un-optimised runs, this screen may only appear for the briefest of
moments. Using the Stop button will stop the calculations and produce results for the
best P.I. discovered so far.
47. On completing the calculations the Summary Results screen will appear. This provides a
summary of the network operation, given the network flows, current options and
optimised signal timings (unless the Optimisation Level = None - evaluation mode in
effect). The Network PI (Performance Index) provides an index, in monetary terms, of
the entire network.
48. Inspect network results by locating Network Results in the Data Outline and then
expanding the relevant section.
49. Inspect individual results by expanding the Results section of each item in the Data
Outline.
51. To analyse any subset of controller streams, traffic nodes, traffic streams or links, define a
collection (Outline: Collections).
52. Generate Flow Graphs (such Cyclic Flow Profile Graphs) and Spatial Graphs (such as
Traffic and Flow graphs using the two Graph buttons on the vertical toolbar.
53. Open the Report Configurator and select which top-level sections and what sub-items you
want in your report.
55. View the optimised signal timings via the Timings Diagram.
56. Compare files using the main menu tool Compare Files
57. View animations of signals, effective greens, queues and traffic flows in the
network diagram by showing the Animation Controls screen and then selecting from
various options within the network diagram.
58. Add a backdrop to your diagram and then switch to 3D Mode to more easily
find the best viewing angle and to present your findings in a more meaningful setting.
59. Add 3D (.DAE) models to your network to help make your network easily identifiable.
60. Generate Time Distance Diagrams using the Graphs button, in order to observe and check
coordination along links.
There are a few exceptions to the above, where a screen must be explicitly 'exited from' before
changes are saved e.g. options > preferences screens. In addition some screens have an
optional mode where you can work with the data in the screen in isolation to the rest of the
program, for speed and convenience.
In general you can show a screen and then show another screen of the same type for example
you can show several Intergreen Matrix screens, each showing the data for a different controller
stream. See Padlock System (section 6.9). Pressing the mouse wheel to select items on a
particular screen will prevent the selected screen from being brought to the front useful when
screens are overlapping and you wish the screen front-to-back order to remain the same.
At any time there is one active item, such as a link, node or location. The current item is
highlighted in the data outline and other screens. If the data editor is visible, then the
properties for the current item will be displayed and should be editable. The data outline is used
to add/delete items.
Double clicking or right-clicking on an item will often show the item's properties, or bring up an
appropriate screen.
Some items are shown in dedicated screens: icons to access these are shown in the vertical
toolbar.
The undo/redo buttons allow any change made to the file to be undone at any time.
Note that TRANSYT does not save a separate output file; instead, basic results are saved within
the input file, and the date/time of the run also recorded. Optionally, you can also include
detailed animation and graphs data within the input file, although this will result in increased file
sizes. You can send such a file to a client or colleague who can view the file, including
animations and graphs, in the demo version of TRANSYT 15. When a HTML report is generated,
the report is saved to a default location and from there can be archived if needed. Optionally it
can be saved as a Word or PDF file. The generated PDF files are fully paginated.
If you cannot find an answer to your question, check the TRL software website first for
knowledge-base articles, latest news items, or contact us directly at TRL.
6.3 Accessibility
A program such as TRANSYT inevitably has to use colours such as red and green to represent
different signal states. In recognition of the fact that some users may prefer to use a different
colour scheme, and to make black and white printing more flexible, most of the colours used in
TRANSYT can be customised via the user Preferences screen. Select File>Preferences, and then
adjust the options in the Colours section.
A number of network diagram colours can also be changed via the network diagram options
screen.
If you have obtained an evaluation version of the software, this will run in unrestricted mode for
a certain number of days, and then revert to demo mode. You must then purchase an unlock
key as above to unlock the full version of the software.
The current security status of the program is shown in the splash screen, which is available from
within the program by selecting Help>About.
Because TRANSYT 15 files include results from running the program, the demo
version of TRANSYT 15 can be used by anyone to view both the input and output
from TRANSYT 15 files. This includes animations and graphs, once an evaluation
run is carried out.
Furthermore, there are many features and data items that will not be required for some
networks, i.e. they are file-specific. Therefore a file-based solution under the sub-heading
Network Options is provided. See section 6.5.2.
In order to make it easier for those unfamiliar with this version of TRANSYT an Advanced Mode
mode of operation (Data>Show Advanced/Detailed data items) is provided. While Advanced
Mode is off a number of features and output results are hidden, making it easier to get to grips
with TRANSYT.
It is recommended that anyone totally unfamiliar with TRANSYT should leave this mode switched
off while they learn the basic operation of TRANSYT, i.e. work in Basic Mode.
Some input values that are hidden when not in Advanced Mode are still
used by TRANSYT. In order to prevent these values being changed while in
Advanced Mode and subsequently hidden in Basic Mode, which clearly
would be dangerous, TRANSYT prevents advanced files from being set to
Basic Mode Once a file is in Advanced Mode it will always remain so.
When merging either a user file or library file into your network, if it
contains advanced features (i.e. it is in advanced mode) TRANSYT will
change your network to advanced mode prior to merging. You will be given
the option of cancelling the operation if you do not wish this to happen.
Network Options is a high level section of a data files outline - Use the Data Outline to
navigate to TRANSYT Network > Network Options.
Network Options consist of a substantial list of individual features or data items, most of which
will be switched off by default. This helps significantly in keeping the graphical interface free of
items you do not need nor want see within your network file.
It is recommended that when creating a new network, you simply scan the list of items and only
switch on those you wish to use or see in your file. Unlike Advanced/Basic Mode, You can go
back and switch off or on any these items at any time. If an item is not selected it will not
appear in any of the data entry screens or in any of the results screens. However, these
hidden items can still be found using the Data Field Finder (see section 7.8)
Some items such as those relating to their display in Data Outline are only hidden while none
of that category of item exists within a file. Most of the remaining options are used to suppress
potentially unnecessary results outputs.
If you have lots of windows open, they will often update themselves. Try closing down
any unnecessary windows, or display one window at a time.
Some windows (e.g. Data Grids) have an Edit In Window mode: in this mode, the rest of
the application is suspended until you click a Done or OK button. Use this mode if you
need to edit a large amount of data in one go.
If Auto-Run is turned on, the file will carry out an evaluation run every time you make a
change. Turn it off to make changes before manually re-running the file.
Close the Data Outline and Data Editor if you are not using them.
Run times increase with the size and complexity of the network, the number of time-
steps and the number of time segments
The Cell Transmission (CTM) traffic model is significantly slower than the platoon
dispersion model (PDM). Use PDM to model links and traffic streams that cause no
blocking back problems. Only use CTM when blocking needs to be modelled.
If using 3-D models within the 3-D Network Diagram, hide the 3-D models until you need
to display them. There is an option to do this.
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.
This menu gives easy access to common data items and takes you to the first item of the
appropriate kind in the Data Outline and Data Editor. It does NOT open any other specific
screens use the View menu or the toolbar icons for this.
Use the Go To Controller Stream Go To Link and Go To Traffic Stream options to go straight
to a specific controller/link/traffic stream if you know the ID of the node/link.
New File
Open File Managing files
Save File
Copy to clipboard
Clipboard
Paste
Print
Printing
Print Preview
Undo
Undo/redo
Redo
Show Data Outline Data outline
Show Data Editor Data editor
Show Data Grid Data grids
Show Task List Task list
Show Audi Trail Audit Trail
Show Windows Manager Windows Manager
Back
Forwards
Changing the active data item
Previous
Next
Toggle Auto-Run
Evaluation-only Run Running files
Run File
Configure Report Configure Reports
Generate Report Reports
Icon
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)
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.
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.
These move the Active Data Item to the next/previous data item that is of the same type as the
current data item. E.g., when on Traffic Stream 1: Modelling, the Next button will move to
Traffic Stream 2: Modelling, and so on. This allows you to quickly move between all items of the
same type without having to find them in the Data Outline.
If you want to prevent such screens from automatically updating, you can lock them to the item
that they are currently displaying. Do this by clicking on the padlock icon shown in the top-left
corner to toggle between locked and unlocked modes, as shown in the screenshots below.
In the lower screenshot, the screen is locked to Controller Stream 1. The data in the screen will
continue to update if the timings for Controller Stream 1 are changed, but the screen will only
show data for Controller Stream 1 (not Controller Stream 2 or 3 etc.), until you unlock it. Once
unlocked, the screen will show data for any controller stream clicked on in the Data Outline etc.
Continuing with the Timings Diagram example, you can show any number of Controller Stream
Timings diagrams at once (just press the button on the vertical toolbar several times), and lock
each one after selecting a different controller stream via the Data Outline. In this way you can
show data for several items simultaneously, as in the screenshot below. This applies to most
screens that have a padlock icon.
Some screens (in particular, the Data Editor and Data Grid) have a special padlock that cycle
through three modes as you click on it:
1. Normal mode: the screen updates as usual whenever you click on an item in the Data Outline
(or the network diagram or any other appropriate screen). Sometimes this may be
inconvenient, in which case use one of the modes below.
2. Lock to type of item mode. The screen stays fixed to the current type of item (for example
Link Modelling), but will update to show e.g. Modelling for Link 1, Link 2, Link 3, etc., as you
select different links. You dont need to click on Modelling for each link in the Data Outline:
clicking on any part of a link, or the link itself in the network diagram, is sufficient.
With Data Grids, this mode locks the rows in the grid to the currently selected type of row
and/or filter, but does not prevent the rows themselves from updating. For example, if you
show a data grid of links, choose the Filter to Bus Links Only filter and then use this locking
mode, then the data grid will only ever show bus links, whatever you click on in the Data Editor.
Changing a normal traffic link to be a bus link would then cause an extra row to appear in the
grid.
3. Lock to specific items mode. The screen stays fixed to the current item, no matter where
you click in the Data Outline. E.g. it shows Modelling data for Link 1, and will not show data for
Link 2 or Link 3 until you unlock it.
With Data Grids, this mode locks the specific rows in the grid. For example, if you show a data
grid of links, choose the Filter to Bus Links Only filter and then use this locking mode, then the
data grid will only ever that particular set of bus links. Changing a normal traffic link to be a bus
link would have no effect on the grid until you unlock it.
To exit from this mode and return to the rest of the application, you must press either the
Done/OK or Cancel buttons.
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.
Some normally editable items may be disabled and are shown with a grey background,
although, it is more common for such items to simply be hidden. There are several
reasons why items may be disabled/hidden:
o It may be a data item that is shown for information only and is always calculated
by the program (i.e. never editable)
o It may be directly inapplicable (e.g. give-way data for a non give-way link)
If a data item is a result, i.e., an output from TRANSYT, it is shown with a light green
background:
When looking at results, some items may appear as N/A. This is usually because you
are looking at results for the whole network or for the summary time segment and the
particular data item is inapplicable e.g. there is a mean max queue (MMQ) for each link
and traffic stream, but not for the entire network; there is a calculated saturation flow for
each link for each time segment, but not for the summary time segment. You can check
this by showing the Help>Glossary screen.
Not all data can be edited directly. For example intermediate results such as Resultant
Stages data and green period data are not editable and are shown with a light green
background. Other data may be greyed out depending on the particular mode of
operation of the software.
6.11.1 Units
TRANSYT expresses some data items in monetary terms. The currency symbol used is arbitrary
as long as all economic input data (monetary value of stops/delays) are entered using the same
currency. The default unit is (sterling), but you can change this to any other symbol via
Options>Units>cost Units in the Data Outline.
In the screenshot below, Australia Dollars has been set as the currency unit, and this is reflected
in all input and output screens and reports. (NB the monetary values in the screenshot are
illustrative only. The actual values used will depend on the country in question. No currency
conversion is carried out; the unit of cost is purely a symbol.)
TRANSYT also provides several options for the units for speed and distance items. Wherever
possible, data items in TRANSYT are always shown with their units, to avoid any potential
confusion. Changing units will automatically update all relevant data items.
Traffic units (input and output) can be changed from PCU to Veh (short for vehicle). The
input and output units are set separately allowing, for example input in vehicles, and output in
PCU. Please see section 13.4.12 for details of how to add new traffic types, and how to define
PCU factors for each traffic type (section 13.4.13).
Flow units can be changed from per hour to per minute particularly useful if you wish to
compare TRANSYT to other products that have traditionally presented results in minutes, such as
ARCADY and PICADY.
Note that all unit options are saved as part of the file (as opposed to user Preferences).
TRANSYT works with controller streams, nodes, arms, lanes, traffic streams, links, pedestrian
crossings, collections, locations and paths, all of which have IDs. IDs can contain any mixture
of numbers and letters, although there is a maximum length of 10 characters. You cannot have
two traffic streams with the same ID, and similarly with the other items.
In TRANSYT you can use very flexible naming conventions, for example using your own set of
prefixes/suffixes when naming traffic nodes or links. E.g. you could name all priority nodes with
an initial P, entry links with an initial E, and so on.
Optionally, you can also enter a longer name and description for most items.
When adding a new traffic stream or other item via the Data Outline or the network diagram,
TRANSYT will automatically assign the ID as the next available number, but you can
subsequently change it using the Data Editor.
When you change an items ID (via the Data Editor) any other data that references the original
ID will be automatically updated. For example, if you load an existing file and then decide
that Traffic Stream 112 should be named Traffic Stream X120, you can make the change using
the Data Editor: any part of the file that referred to Traffic Stream 112 (e.g. Traffic Stream
sources/upstreams, give-ways, and so on), will automatically be changed to refer to the new ID,
and so the file will remain self-consistent.
Identifying and referring to traffic streams is simple. The presence of a / indicates a stream is
being referred to. The format is of the form X/Y. Where X is the Arm ID and the Y is the Traffic
Stream ID. So 7/1 as shown in screenshot is referring to first Traffic Stream on Arm 7. In the
network diagram the traffic streams are drawn in order, with the first traffic stream located
nearest the arm name.
Traffic Stream IDs are not unique, but the combination of arm (which is unique) and traffic
stream is.
Links are referred to simply by referring to their ID which is unique within the file. Obviously,
link IDs should not use the / character in them otherwise they may be wrongly identified as a
traffic stream instead.
As explained above, TRANSYT works with many network items, such as traffic streams, each of
which has an ID. Many screens show lists of such items, as do generated reports and as does
the Data Outline itself. You can control the sorting of these lists via the Options>Sorting section
of the Data Outline.
Note that the Data Grid screen also lets you sort by any column simply by clicking on the column
header.
To see the effect of these different sorting options, show a Data Grid of links, lock it, and then
try each sorting option using the Data Editor. You will also see the order of traffic streams,
links, controller streams and collections in the Data Outline change.
The Ignore Prefixes When Sorting option can be useful if using a naming convention. For
example if you have named priority nodes with a P prefix, the default sorting may list nodes in
your file as follows:
Turning on the Ignore Prefixes When Sorting option would change the order to the below:
Returning to normal mode but then changing Sorting Type to Alphabetical instead of Numerical
would change the order to the below (Node 11 now comes before Node 2)
Note that all sorting options are saved as part of the file (as opposed to user preferences). You
will therefore see the same sorting of controller streams/traffic streams/links/collections and
routes every time you load the file.
Click this run button (or press F5) to carry out a run of TRANSYT based on the
optimisation level and optimisation options you have set. The analysis program is run
using the current data file and the corresponding results are displayed.
Click this evaluation run button to carry out a run of TRANSYT using the existing signal
timings. I.e. no optimisation or redistribution of signal timings is carried out.
Click this auto-run button to toggle the Auto-Run feature off and on. When Auto-Run is
turned on, TRANSYT will carry out an evaluation run and screens will automatically
update to reflect the results from any change to any part of the data. This ensures the
results always match the current signal timings.
Run times in TRANSYT are heavily dependent on the size of the network and the choice
of traffic models used. We recommend leaving Auto-Run switched off unless working
with a network with short evaluation run times. You may also want to turn off Auto-Run
when you want the results screens to stay static.
The time taken to run a file depends greatly on the size of the network, the chosen optimisation
options and the traffic models you are using. If using a PC with reasonable specifications, most
networks using a PDM model should run almost instantly and Auto-Run can be used without any
problems. If there are a large number of lanes, links or controller streams, run-times can
increase to noticeable levels, and it may be advisable to turn Auto-Run off. We also recommend
leaving Auto-Run switched off when using the CTM traffic model, since this is inherently slower
than PDM.
The status bar at the bottom of the main screen shows what TRANSYT is doing at any time.
Files can be created, opened and saved via the standard New, Open, Save and Save As options
in the File menu. You can also open or import a file by dragging and dropping from Windows
Explorer into the main TRANSYT screen.
Several files can be opened at once. The names of any open files are shown in buttons in the
blue bar at the bottom of the screen: this is the file selector bar.
TRANSYT files can also be saved as Library Files, which can then be easily merged into networks
from within the network diagram or using the Merge Network facility. See section 23.2 for
details on this.
To switch between files, click on the appropriate button in the file selector bar.
The ability to open and view several files in this way is invaluable when comparing different
versions of the file, for example to study the effect of a small alteration to the junction.
Alternatively Tools>Compare Files can be used.
To close a file, use the File>Close menu option, or right-click on file in the file selector bar. To
close all open files use the File>Close All menu option.
TRANSYT 15 can import data from TRANSYT 14, TRANSYT 13, TRANSYT 12, TRANSYT 11 and
TRANSYT 10 by simply using the standard File > Open menu or the Open icon and selecting the
relevant file extension from the bottom right-hand corner of the Open dialog box.
filename.T15, .T14 and .T13 for TRANSYT 15, 14, and 13 respectively.
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.
If a TRANSYT 15 file that is opened has been generated with a different release of TRANSYT to
the one currently being used, a message may report this and provide an option to examine a
report detailing any differences made to the file as it is opened. This only happens when the
changes are substantial. This information may be of interest to some users if they wish to know
what kinds of changes are taking place, e.g. new data items being created and old ones removed
or changed.
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.
Click on the File>Open Containing Folder to open the folder where the file is located in Windows
Explorer.
When you save a file, you save all the input data. If the file has been run, then you also save
the results for each link and the whole network, i.e. the results are embedded in the data file. If
you subsequently load this file back into TRANSYT, you can jump straight to the results without
having to re-run TRANSYT. This is useful if it is a large network or is otherwise slow to run.
If a file contains multiple analysis sets, the results in the file will be those
associated with the last-run set if you change sets, you should press the
Run Evaluation button to repopulate the results with those for your newly
selected set. Running an evaluation run after switching sets will also
prevent the Report ever presenting the results of one analysis set alongside
the input data of another.
When you run a file, TRANSYT also produces a large quantity of data that is used to generate
graphs and animations. This data is not stored with the file, so an un-optimised run of any
newly opened files will be required to show this information.
If you wish to send a file to a client or colleague so that they can see your results, simply send
them your saved TRANSYT file. If they wish to see the animations they will need to carry out an
un-optimised run of TRANSYT to generate the required data. They will require either the
demonstration version of TRANSYT 15, or a registered OR unregistered version of the full
product if a demo or unregistered version is used, the file can still be loaded, viewed, animated
and run with the current (un-editable) data. A demo version of TRANSYT 15 can be downloaded
from www.trlsoftware.co.uk.
6.14 Undo/Redo
The Undo and Redo buttons on the main toolbar allow you to step back through recent changes,
and then re-do these changes if necessary. Each click of the Undo button will go back one step
in the 'history' of the file, and will automatically update all open windows and re-run the file if
necessary. However, due to anticipated memory constraints, the UNDO record is cleared when
switching to another file.
Use the drop-down menus on the Undo/Redo buttons to show a list of recent changes and jump
straight to a particular change.
Note: hovering over the Undo/Redo buttons, or using the Edit menu to access the options, will
show the action that will be undone/redone, e.g. "Undo Change Saturation Flow".
The Undo facility is useful for reversing accidental mistakes, or for 'rewinding' the file after
deciding that a series of changes is unwanted. For more complex, intentional changes (when
you wish to compare one version of a network to another), consider using the File>Copy Into
New File option (see section 6.13.4).
The Undo/Redo buttons are also very useful for studying the effect of a change to a data item,
especially when the file is automatically re-run (i.e. the Auto-run option is switched on). For
example you can run a file, display the Summary Results screen, then adjust a data item field,
then flick back and forth between the before and after results via the Undo/Redo buttons.
Also see section 6.18 on user preferences regarding reducing the number of Undo points to
reduce the memory requirements of TRANSYT.
An extra item in the main Edit menu is Edit>Save Diagram State. This will add an extra item to
the Undo history which represents the current network diagram layout. Subsequently you can
revert back to the diagram layout as it was at this point by clicking on the Undo drop-down
menu and then selecting the Saved Layout entry. This saves you having to click the Undo
button multiple times to revert back to this point, and acts as a kind of network diagram save
option.
The Copy button on the main toolbar will, where appropriate, copy data from the currently active
screen (the screen last clicked on) to the Windows clipboard. The data can then be pasted into a
word processor, spreadsheet etc. (Some screens also have their own Copy buttons for specific
purposes, or you can right-click in individual windows/screens.) To copy the network diagram,
for example, click in the network diagram so that it is active and then click the Copy button on
the main TRANSYT toolbar.
The format of the data depends on the screen but columns and rows are generally separated by
tabs and new lines. In some cases, the Paste Special option in the word processor/spreadsheet
can be used to select between options of pasting text or a picture.
In many cases you can also use the CTRL+C shortcut, or, right-click and choose Copy, but note
than in some situations this will copy only the current line of text rather than the entire table.
6.16 Printing
The Print and Print Preview buttons on the main toolbar will, where appropriate, print or show a
print preview screen for the currently active screen (the screen last clicked on). This applies to
the network diagram, the Report Viewer, and also various other screens such as graphs and the
Timings Diagram.
There is a standard Window menu on the main toolbar which will show a list of all currently open
windows and allow selection from this list. It also contains a Close All option which will close all
open windows.
TRANSYT allows you to store custom window layouts. This allows you 'save' the layout of all the
TRANSYT windows as they currently appear, and quickly select the same layout the next time
you use the program. Click Window Layouts>Store Current Window Layout to assign a name
to the current window layout (i.e. the position and size of all windows as they currently appear).
The layout will then appear in the menu whenever you use TRANSYT. Layouts are saved as part
of your user preferences, not in the data file.
Use the menu option Window Layouts>Window Manager option to display the
Window Manager. Alternatively, use the Windows Manager icon on the main toolbar
(see section 6.17.1).
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.
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.
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.
This screen also provides a number of utility options at the bottom-left of the screen. In
particular, click Reset suppressed messages to restore any message boxes where you have
previously clicked Do not show this message again.
Some options are explained in this User Guide in the relevant section, but brief descriptions of
some items are also given below for reference.
To reset all options to factory defaults, press the Defaults button. You can also use File>First
time use wizard to set certain common preferences.
General:
Allow Window Minimise & Maximise: This option shows or hides the maximise and
minimise buttons on every screen.
Default Editor and Default Editor in NetCon: Use these two options to change what
data-entry screen is displayed when you double-click in the Data Editor and Network
Diagram (NetCon). You can choose between the data editor, custom screens or data
grid. Where a custom screen does not exist for the item that is double-clicked, the data
editor is displayed instead. This option allows you to favour your preferred method of
data-entry.
Library File folder path: Use this option to change the location where TRANSYT expects
to find the Library Files. This option could be used, say, to choose a central location for
company-approved Library Files.
Log everything in Audit Trail for new files: The equivalent of this option is saved with
the file, but this allows the Audit Trail to be switched on by default for new files.
Number of Undo points: Use this option to set the number of undo points. These allow
you to reverse changes you make to your file. Each undo point uses up memory so if you
are modelling very large networks and start to experience any memory shortage issues
(e.g. unable to allocate sufficient storage messages) then reducing this number (all the
way to zero if necessary) is a very effective in reducing the memory requirements of
TRANSYT.
Prompt to save Audit Trail status for new files: The equivalent of this option is saved
with the file, but this allows, for new files, the user to be prompted to save a status entry
each time a file is saved.
Use Advanced Mode by default for new files: Set this option to force all new files and
Library Files to start off in Advanced Mode, i.e. all data items and features will be
accessible. N.B. Library files will start off in Basic Mode only if they have been originally
saved as Basic Library files.
Window Font Scheme: Select from either Medium or Small. This allows you select
a text size that matches the size of your display and your personal requirements.
Localisation:
Default driving side: Use this option to set which driving side of the road you wish use
for new files. TRANSYT files can also be switched at any time using the Mirror File tool.
Phase/Stage Display Names: The UK terminology used to refer to stages and phases
is not used globally, e.g. common alternatives are to use phase to refer to a UK stage
and Signal group to refer to a UK phase. Use this option to choose one of the
alternative terminologies.
Please note that although most of the relevant labels within the GUI will change as soon
as you switch to a different set of Phase/Stage display names, you must close TRANSYT
and reopen it to fully complete the change.
SCATS split time: Use this option if you wish TRANSYT to display Australian stage split
percentages (i.e. percentage of the cycle time taken up each stage. The split (%) times
are reported in the Resultant Stages table. Note that the split times can also directly
editable. Changes to the split percentages will indirectly change the stage duration and
stage end times. The Timings Wheels will also show split times as a percentage if this
option is selected.
Reports:
(Import Settings) From External File. If set, the user-definable External Settings
File is used instead of the default local user.config file. This allows, say, a read-only
preferences file to be saved to an accessible network location, and hence the same
preferences can be centrally defined for all users within an organisation. See section
6.18.1 on how to transfer the preferences file, rather than share it.
Reports Location Mode. If the latter is set to use same location as input file, then all
reports will be saved to a folder with the same name and location as the main TRANSYT
data file. Otherwise, if use specified folder is selected, you can nominate a Reports
Folder, which will be used for all generated reports.
Junction/Network Diagram:
3D models folder: Select a specific folder in which you keep your collection of 3D
models. This should be the master folder in which each model has its own folder. This is
because each Collada model is made up of multiple files, and as such each should be kept
separate from other models by using its own folder.
Safe Mode: Turn this on if you experience any problems with text rendering in the
network diagram.
Start network diagram (Netcon) Inside Application Window: Turn this on if you
wish to have the network diagram opening in its own Window on a permanent basis. This
option is useful when using multiple monitors, and wishes consistently to use the network
diagram on its own monitor. This option can also be set within the network diagram on
temporary basis.
Colours: Use these options to adjust the default colour scheme for various items.
In addition to their use by the Task List, the Error, Warning and Good colours are
also used for various network diagram overlays in order to identify the various levels.
Blue pedestrian
Grey dummy
Signals:
Format of Phase ID: Auto-generated phases can be set to produce either Numbers or
Letters
Format of Stage ID: Auto-generated stages can be set to produce either Numbers or
Letters
Show TxC values: This preference tells TRANSYT to generate TxC values for each
phase, which are of use with Dutch halfstarre applications.
Diagrams:
Depiction of Links on Red: controls how links that are red during a particular stage are
depicted in the Stage Sequence Diagrams.
Flow units for Flow graphs: Selects how the vertical axis of flow profile graphs should
be scaled - PCU/hr or PCU/step. Although the most useful is usually PCU/hr, it is
sometimes preferable to show PCU/step when trying to examine traffic behaviour on a
step-by-step basis over a small time period.
Flow units for Spatial graphs: Either the distance upstream from the stop line (in
metres) or the number of PCUs can be displayed on the y-axis of these graphs. The
ability to switch units is sometimes handy as it allows different graph types to be
displayed with the same y-axis units.
Link Connector Arrow Type: controls how arrow directions are automatically calculated
in the network diagram and also in Stage Sequence diagrams
Use Effective Greens in Graphs: this option is also available via the main Graphs
button on the application vertical toolbar. If this is turned off, then actual greens are
used.
Comparison Tool:
nth File Colour: Use each the colour options to set the specific colour you wish to use
when comparing multiple files.
Aimsun Plug-In: See TRANSYT-Aimsun User Guide for details on this option.
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:
TRANSYT does not save a separate output file. Instead, results can be embedded in the data file
and saved along with input data. See saving results (section 6.13) for more details.
Please note that a number of input data items are only accessible when TRANSYTs Advanced
Mode is set. See section 6.5 for details. Furthermore, many items can be switch-off using the
Network options list. See section 6.5.26.5 for details.
Output can be saved permanently in the form of Reports, which are generated by the Report
Generator. Reports are produced in the form of HTML documents, and so can be viewed in any
web browser (and most word processors), as well as the viewer built into TRANSYT and can also
be converted to Word and PDF documents. The generated PDF files are fully paginated.
Any TRANSYT files can be saved as a Library File (File > Save As Library File), which can be
easily merged into future networks from within the network diagram or using the Merge Network
facility. See section 23.2 (Adding a Junction (Merging Networks) for details on this. When
Library files are saved, a snapshot image of the network diagram is stored with the file so that a
preview screen can be provided when selecting the library files.
Once a library file is loaded into TRANSYT it can be manipulated like any other file. Saving the
file will save it as an ordinary TRANSYT file, but it can also be saved as a new library file if you
wish.
The only differences between a Library File and a normal TRANSYT file are that the
Library File contains a preview image AND it is stored in a specific Library Folder.
If you open a Library File directly from this special Library Folder (<Install
Folder>TRANSYT 15/Library) please note that when you come to save it, any
changes will be naturally saved to the Library File itself. For this reason, only
browse to and open files directly from this folder, if you intend to edit the Library
itself. At all other times, use the New File button, Merge Network option or the
network diagram button.
In addition to the ordinary Library Files, some of the pre-supplied Library Files are deemed to be
sacrosanct and cannot be altered or deleted. These files do not show up in the Library File
folder, but do appear in the Library List.
You can also use the Main Data, Nodes Data, Links Data and Streams Data screens to access
commonly used data items.
Data in any part of the Data Outline can be accessed and edited in any order - there is no need
to fill in data in a specific order.
The screenshot below shows the general form of the data structure. Each entry in the tree-view
is a data item, and if the entry is shown in bold, then it has associated data item fields that can
be edited using the Data Editor Screen (7.5).
The first line in the tree-view shows the filename for the file being edited. (To change this, you
need to use the File>Save As menu option.)
File Description contains a number of data item fields for describing the file, such as a title,
site (reference) number, job number, driving side, etc.
Analysis Sets and Demand Sets contain definitions of analysis and demand sets, which
allow you to set up data for e.g. different periods of day, or different signal plans.
TRANSYT Network contains the bulk of data and defines the network being modelled
Options contain a number of additional, advanced options, which are saved with the file.
The screenshot below shows the basic hierarchy expanded by one level, and shows that, for
example, TRANSYT Network contains Network Options, Controller Streams, Arms, and
Local (OD) Matrices. This list reflects the items that exist within the chosen file. Other
networks will display a number of other items.
The following screenshot shows the hierarchy expanded to a deeper level, and shows the
individual controller Streams within the Controller Streams section, and so on. To take this
screen shot TRANSYTs Advanced/Detailed data items option has been switched on, revealing
the Advanced items such as Analysis Sets and Demand Sets.
The Data Outline is used to access all data items within the TRANSYT file. Items in bold have
associated data fields that you can view and edit in the Data Editor (see 7.5). Items that are
not in bold do not have any associated data item fields. Double click on any item to show the
Data Editor (or chosen screen type see File>Preferences) which will show any data fields for
that item.
The Data Outline presents all data within the current TRANSYT file in a 'tree-view' format, where
each item 'belongs' to a parent item.
See section 6.8 for more details about the Active Data Item
and how to use to set it using the main toolbar's
back/forwards/up/down buttons.
The Data Outline is also used to add new data items such as
new controller streams and arms, and to remove existing
ones. For example, to add a new arm, firstly select any of
the existing arms (or the Arm item), and then click the Add
button. You can also right-click on any valid item in the Data
Outline for similar options. You can also add/delete items via
buttons in various other screens, including the network
diagram.
Notes:
In some cases, TRANSYT will prevent you from deleting an item if it is the last item in the
group.
When adding a new item, the new item's data fields are copied from the Active Data
Item. For example, if you select traffic stream 2 and then click Add, then the new traffic
stream will be added to the end of the list and the values of its data fields (including its
control type and all signal timings) will be the same as those for traffic stream 2. This
means that you can easily make copies of existing items. To reset data fields to their
default values, simply use the Default values button on the Data Editor. However, if you
select Links and then click Add, then a new traffic stream with default properties will be
added.
If using the Data Outline to add a new Analysis Set or Demand Set, the new set will
contain a copy of all data for the current analysis/demand set.
The Data Editor is used to edit data item fields for the Active
Data Item.
As the Active Data Item is changed (either via the Data Outline
or from other screens such as the network diagram), the Data
Editor changes to show all the data fields for that item. The
top of the Data Outline shows the item that is being edited in
the screenshot, a traffic stream is being edited, specifically,
Stream 1 on Arm 2.
See section 6.8 for more details about the Active Data Item
and how to use to set it using the main toolbar's
back/forwards/up/down buttons.
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.
The Task List shows any warnings or errors in the current file. TRANSYT checks the data file
every time a change is made, and automatically updates the Task List. As soon as you 'fix' a
problem, the Task List will update and the error/warning should disappear. The Task List acts as
a central checklist that at any time shows you what needs to be done in order to run the file.
The background colour of the task list button changes colour to indicate the presence of
warnings or errors amber if there are any warnings; and red if there are any errors.
Checks are made for logic and self-consistency within the file.
Note that the Task List shows problems associated with the data file before it is run in the
optimiser. Occasionally, errors may only come to light when you try to run the file, and these
will be shown as message boxes.
For each row in the grid, the Severity column will display either 'Warning', 'Error' or 'Info'.
Errors prevent the file from running, whereas warnings serve as reminders that you may want to
double check something, but will not prevent runs. Info items are simply for confirmation
purposes. The Area, Item and Problem columns indicate the exact nature of the problem. In
most cases, double clicking in the row will open the appropriate screen (or item in the Data
Outline) where you can fix the problem.
You can choose whether to display errors, warnings or info items by toggling the three buttons
at the top of the screen. By default, all three types of item are shown, but you may wish to hide
the Info items.
Clicking in any column in the header row will sort the grid by that column. This allows you to
choose to sort the problems by Severity (so that errors appear first; this is the default) or by
Area.
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.)
The Data Field Finder acts as a simple index to all data items in the program. It is useful when
you are not sure where a particular data item is located in the Data Outline. Enter a word or
phrase to search for and any data items that contain the word will be listed. Select an item from
the list and then double click the row or click Go to selected item to jump to the first occurrence
of that item in the Data Outline. Note that it is only the names of items that are searched for,
not the actual values of the data items.
As an example, if you have forgotten how to set the driving side (left/right), you can enter
"Driving Side" here to reveal that the driving side is located in the File Description part of the
Data Outline.
Select Show hidden items option to reveal any items that are currently hidden. Hidden items
can be hidden from view in the GUI either because they are an Advanced item and the file
happens to be in Basic Mode, or because none of that particular item is present in the current
data file, e.g. if there are no traffic signals in the file, there will be no saturation flow data
items present. The Description indicates why it is hidden.
Clicking Search help file will open the application User Guide and perform an automatic search.
You can thus search the User Guide for further information on any topic.
Note: to search the help file for a phrase (as opposed to a single word), use the search system
built into the help file, i.e. press F1 from anywhere in TRANSYT to show the help file, then use
the help file's search system.
In common with the rest of TRANSYT, bold items have associated data fields, and light green
items are results as opposed to input data items.
The data on these screens works in exactly the same way as the Data Editor, can be left visible,
and also synchronise with other TRANSYT screens. You can also lock the screen to a particular
item.
There are two user preferences that allow you change which editor screen is
displayed when you double-click either within Netcon (File>Preferences>1. Default
Editor in NetCon) or in the Data Outline (File>Preferences>1. Default Editor). In
this way you can select which screens you would prefer to use, including a mix of
the two You may find the Data Editor which is compact, is better if you are using
a small monitor, and the dedicated screens, which are wider, will be ideal if using
larger or multiple screens. There is also the option of defaulting to a data grid.
The monetary values of vehicular and pedestrian delay are now separated.
However, by default, the values are the same.
The Fuel tab will be hidden unless it is enabled via the Network Options.
There are buttons offering the option to create a completely new set of fuel parameters, or to
create an extrapolated set (from WebTag data). The Generate Extrapolated Fuel Parameters
button is used to populate the fuel parameters data grid with values appropriate for a specified
year - extrapolated from WebTag data stored within TRANSYT. Full details on how to use this is
available in section 25.10.
Network Summary results are given for the complete network and also separated into vehicular
and pedestrian results.
Apart from the Controller Stream Tab, the data within each tab is shown in form of a data grid.
These data grids work in exactly the same as any other Data Grid, including the ability to
add/delete columns and rows.
Some of the tabs have additional buttons which carry out useful actions such as Create New
Phases and Auto Generate Library Stages.
Details of how this screen fits into the overall data-entry process for traffic signal data is given in
section 8.2.7, while a full description of the contents of each tab is given here in the following
sections:
The Controller stream tab shows the basic controller stream data such as its ID, name and
description. From this tab you can also change controller-specific optimisation options.
When changing the optimisation option, such as switching off Allow Green Split
Optimisation. This affects only this particular controller stream. The reported
optimisation level reports the combined effect of the controller-specific settings
and the network-wide (common) settings are, e.g. if at the network level the
optimisation is set to offsets only then this will be reflected in the optimisation
level shown here. For the situation described, the disallowing of green split
optimisation will have no effect as it is in effect banned already.
Cycle time options are also accessed from this tab. By default, the cycle time used by the
controller stream will be NetworkDefault which is whatever the network-wide value is (Outline:
Network options > Optimisation Options.) For convenience the cycle time used is reported on
this tab. Change the Cycle Time Source to Manual to set its own cycle time, or
alternatively set it to Controller Stream in order to reference another controller, from which it
will get its cycle time from. In this way you can set up multiple sub-networks each running on a
single cycle time.
Generate optimal sequence: Use this option when you wish TRANSYT to provide you with
an optimal (isolated) set of timings (i.e. phase optimisation).
When using this option, there is no need to define stages, stage sequences and
phase delays as all of these are calculated for you. Any existing data will be
replaced.
Pedestrian flows are not taken account of during phase optimisation. Suitable
phase minimums and maximums can be set to influence the results for phases
controlling pedestrian crossings.
Since the optimisation is based on the junction performance in isolation to the rest
of the network, no blocking back effects will be taken account of.
Having obtained this solution, a run of TRANSYT will then provide a good solution within the
context of the wider network, in terms of optimised green splits and offsets.
Run Phase Optimiser with current sequence: Use this option if you wish to use your own
stage sequence, but wish to optimise the phase lengths associated with this particular sequence.
Phase delays will be automatically added or removed in order to optimise the timings. Having
obtained a solution, a run of TRANSYT will then provide a good solution within the context of the
wider network, in terms of optimised green splits and offsets.
8.2.2 Phases
The Phases tab shows a grid of each Phase for the current controller stream. By default the
controller stream will be populated with two phases A and B. To add or remove phases use
the two buttons provided. Alternatively you can right-click on a row-header (the grey area on
the left of any row) of either of the phases. The pop-up menu offers the options to either delete
the phase you are on, add a copy of it, or add a new phase.
You can change the phase properties, such as minimum green time, maximum green time,
relative start displacement, relative end displacement, by clicking on individual grid items.
The phase type can be left as not specified or set to the most relevant type.
Generally, the phase type does not affect model behaviour. Some phase types
also allow extra phase data to be specified, however only the blackout period for
pedestrian phases affects the model. Amber times are for visual purposes only.
Phase types also allow you to more easily identify what the phase is for, or what it
is controlling. Different phase types are shown in different colours in the Timing
Diagram if the user preference Use phase colours in timings diagram is selected.
Additionally, some warning messages depend on the use of the phase, e.g. if a
pedestrian phase is set to control vehicular traffic a warning will be displayed in
the task list.
After setting the number of phases you will often want to set up the conflicts between phases.
The Intergreen Matrix button conveniently opens the intergreen matrix screen for you.
The Stage Library tab shows a grid of each library stage for the current controller stream. By
default the controller stream will be populated with two library stages Stage 1 and Stage 2.
By default the stages, will be all-red i.e. no phases are running in them. To add or remove
stages use the two buttons provided. Newly created stages will by default have no phases
running in them. Alternatively you can add more stages by right-clicking on a row-header (the
grey area on the left of any row) of either of the stages. The pop-up menu offers the option to
either delete the stage you are on, add a copy of it, or add a new stage.
To define which phases run in each stage, click on the Phases In Stages grid cells and enter a
comma-separated list of phases. N.B. you can add phases that currently do not exist, but in
order to run TRANSYT you will also need, at some point, to create these phases.
The Auto Generate Library Stages button will automatically create in the Stage Library a
collection of all possible stages a stage for each valid combination of all the phases that can
run together ( Outline: Controller Stream n>Stage Library). E.g. if you have four phases
defined, where phase A and C conflict and B and D conflict (as defined by your intergreen
matrix), the stage library generated for you will contain two stages - a stage 1 (phases A and C
running) and a stage 2 (phase B and D running).
The fourth button, Interstages opens the interstage tab of the Intergreen Matrix screen, to
let you see the derived interstages.
The Phase Delays tab shows a grid of phase delays for the current controller stream. By default
the grid is empty. To add or delete phase delays use the buttons provided. Alternatively you
can add, delete or copy them by right-clicking on a row-header (the grey area on the left of any
row) of any of the phase delays.
Having added a phase delay you need to specify whether or not it is a losing or gaining
delay. A gaining delay is one which delays the start of the phase relative the start of the stage,
while a losing delay is one which extends how long the phase runs after the end of the stage.
A phase gaining delay value (in seconds) can either be set to be an absolute delay, which is set
relative to the end of the previous stage or as a relative delay which is set relative to where it
would have started if the phase did not exist, i.e. as soon as possible after all intergreens have
been satisfied.
N.B. Phase delays can also be created and deleted directly on the timings diagram. See
chapter 15.
The Stage Sequences tab shows a grid of all the stage sequences associated with the current
controller stream. By default Stage Sequence 1 will already exist, which runs stages 1 and 2.
By default, this is also the currently selected sequence which the controller stream will be set to
run - indicated by an asterisk in the Timings diagram and the Data Outline. Change the Use
Sequence value to change which sequence TRANSYT will use.
To add or remove sequences use the buttons provided. Alternatively right-click on a row-header
(the grey area on the left of any row) of either of the stages. The pop-up menu offers the
options to delete, copy and add a new sequence.
To define which stages run in each sequence, click on the Stage IDs grid cells and enter a
comma-separated list of stages in the order in which you wish them to run. N.B. you can add
stages that currently do not exist TRANSYT will automatically add them to your Stage Library.
Note however that, you will need to re-visit the new stages to define which phases run in them
by default they will be blank i.e. all red stages.
An addition three buttons are also provided, in order to make it quick and easy to set up your
sequences. The Auto Generate Sequences button will automatically create the 10 simplest
Stage Sequences possible (given the already defined stages and conflicting and non-conflicting
phases ). If none of these are what you wish to use, you can simply edit the one closest to your
requirements and reset the controller data to use that sequence.
The other two buttons Timings Diagram and Stage Sequence Diagram are simply short-
cuts to open the Timings Diagram and Stage Sequence Diagram respectively.
This tab provides easy access to all the resultant stages and green period data which has been
derived from the other data you have specified such as intergreens and stage definitions.
Stage start, stage end and split times can be directly entered using this screen.
The TRANSYT Stage start times (as used in TRANSYT 12 and earlier to define
when the call for the next stage occurs) can also be edited here.
The reporting of relative offsets (positive and negative) can be set up from the Offsets tab. See
section 21.1 on how these appear in the TRANSYT output.
Various screens are provided to allow signal data to entered, and subsequently edited. The
Signals Data Screen is particularly useful for when you want to enter all the signal data for a
controller stream from scratch, as it brings together in one screen all the facilities to set up your
signal timings. As a result it may well become your preferred method of entering such data. It
not the only way however - Details of the other signal data screens is detailed in chapter 15
Working with Signals.
To make life easier when setting up standard junctions in a standard way, the following method
is suggested.
This method primarily uses the Signals Data Screen (as well as the intergreen matrix
and the network diagram):
1. Create your new controller stream, if needed, either in the network diagram or via the
Add a new Controller Stream button on the data outline.
2. In the network diagram associate the traffic streams with the new controller using the
connector tool.
3. Open the Signals Data Screen and select the controller stream you wish to edit.
4. Select the Phases tab and click on Create New Phases and specify the number of
phases you need. Tip: If you are not sure how many you may need it is not a problem
you can add more or remove unused phases easily. Guessing high is marginally easier as
unused ones can be easily ignored or deleted at the end.
5. Select the controller stream in the network diagram. At this point the phases controlling
each traffic stream will be displayed. By default they will all be set to Phase A. Simply
right-click on each traffic stream or link to select the right phase.
6. Return to the Signals Data Screen and open the Intergreen Matrix screen by clicking the
intergreen matrix. Fill in the intergreens (first tab of the intergreen screen) in order to
define which phases conflict with each other, or use the provided tool to auto-generate
both conflicts and intergreens. (If you use the auto-generate option you should
always use a network diagram that is properly scaled, use curved connectors
and check the conflicts and values that have been derived. These can be
adjusted manually.) You only really need to add the intergreens for the phase
transitions you wish to use, but entering them all is advisable if you are unsure of what
your final stage sequence will be.
7. Select the Stage Library tab. Click Auto Generate Stages. This will generate a set of
valid library stages, each of which maximise the number of phases that can run in them.
8. Next, you can add phase delays at this point by using the Delays tab, but this tab is best
used in conjunction with the Timings Diagram, and you may often want to skip this stage
until you have a valid stage sequence.
9. Select the Stage Sequences Tab and click Auto Generate Stages. This will create up to
10 of the simplest (smallest number of stages) stage sequences possible. Open the
Timings Diagram to see a graphical representation of each of them - Either click in the
boxes to the left of the Controller Stream column or use the data outline to select each
sequence.
10. Enter the sequence you wish to use in the Use Sequence box.
11. Now open the Task List to check that your network does not have any errors. As long as
there are no errors you can now run your file with your chosen optimisation options set.
Select the link to view using the list on the left hand side, or via the Data Outline, or via the
network diagram. The list of links is visible from all tabs. Links and quick flares can be added,
deleted and modified via this screen.
There are no particular differences between using this screen or the data editor to enter and edit
data. However, you may find is easier to specify data using this screen. Please read Chapter 3
to find out how to construct a network using links in TRANSYT.
Details of the data items accessed via these tabs are not described here as this is already
covered in various other chapters.
The Link tab allows the Link ID, name, description and traffic node to be set. It also
allows you to set the link length, traffic type, whether or not it has a restricted flow (i.e. a
saturation flow) and whether or not it is signalled and/or a give way. (see screen shot)
The Modelling tab: Due to the amount of modelling data required, this is split between tow sub-
tabs The first sub-tab is primarily traffic related, i.e. the traffic model used can be selected as
well as queue storage values and various traffic model parameters. The second tab allows
optimiser weighting factors and queue limit and DoS penalties to be set, (see screen shots).
The Flows tab is split into a number of tabs. The first allows the link total flow to be defined. A
link consistency tool is also built into this tab to allow you to identify and investigate where any
flow discrepancies exist. How to use this feature is described in section 13.3.
The Upstream tab shows a grid of each Source for the current link. If the link is an entry link,
then the grid will have a single row requiring either the cruise time or speed, otherwise it will
haver/need as many rows as there are upstream (source) links. Add new sources by right-
clicking on the row header and selecting Add New Source.
The Downstream tab is only there for convenience i.e. it allows the source data for any
downstream links to be edited so that if any changes are made to the current link the required
knock-on changes can be easily carried out. Of course, the use of this tab is optional as the
same data can be edited in the upstream tab of each of the downstream links.
The Advanced tab allows the specialist flow detector data and link sensitively values to be set.
Because of the amount of give-way data and the hierarchy of movements and the conflicts
associated with them, the give-way data is split between two tabs General and Conflicts.
The General tab allows data associated with the opposed traffic flow to be defined, as
determining whether or not you wish to use the step-wise opposed turn model.
The Conflicts tab allows each conflicting (controlling) movement to be defined in terms of the
type of opposing item (i.e. is it a link or link share) and how much to its traffic is opposing. You
also need to define here the give-way parameters needed for the chosen give-way model.
The Signals tab allows you to set what controller stream and phase controls a signalled link.
The Flares tab allows access to quick flares. Use the buttons at the bottom of the tab to add or
delete quick flares for the current link.
Results for each individual link can also be examined using the Results tab. Blue shortcuts are
provided to give easy access to the remaining link results.
Select the traffic stream to view using the list on the left hand side, or via the Data Outline, or
network diagram. The list of traffic streams is visible from all tabs. Arms, traffic streams and
lanes can be added, deleted and modified via this screen.
Some of the tabs have additional features which carry out useful actions such as the traffic flow
consistency diagram on the Flows tab.
There are no particular differences between using this screen or the data editor to enter and edit
data. However, you may find is easier to specify data using this screen. Please read Chapter 3
to find out how to construct a network using traffic streams in TRANSYT.
Details of the data items accessed via these tabs are not described here as this is already
covered in various other chapters.
The Arm tab allows the Arm ID, name, description and traffic node to be set.
The Traffic Streams tab allows the traffic stream length, traffic type, whether or not it has
a restricted flow (i.e. a saturation flow) and whether or not it is signalled and/or a give
way. (see screen shot)
The Lanes tab allows the number of lanes represented by each traffic stream to be set. It
is also used to determine how the lane saturation flow values are derived. (see screen
shot)
The Modelling tab: Due to the amount of modelling data required, this is split between
tow sub-tabs The first sub-tab is primarily traffic related, i.e. the traffic model used can
be selected as well as queue storage values and various traffic model parameters. The
second tab allows optimiser weighting factors and queue limit and DoS penalties to be
set, (see screen shots).
The Signals tab allows the controlling phase and its controller stream to set. N.B. This
tab is only visible if the traffic stream is signalled, (see screen shot). The Signals Tab
View Signals button takes you to the data for the referenced controller stream so that it
is easy to make changes to it, if needed.
The Flows tab allows the total flow to be checked. The Upstream tab is used to specify
the cruise speed/time of the sources of the selected controller stream. For convenience
access is given to downstream data. A flow consistency diagram is also provided to help
you resolve any flow consistency issues, (see screen shot).
The Give-way tab allows the conflicts between the selected traffic stream and other
opposing (controlling) traffic streams to be set. This is also split into two sub-tabs. N.B.
This tab is only visible if the traffic stream is a give-way, (see screen shot).
The Normal, Bus and Trams tabs allow optimiser delay and stop weightings to be applied.
Which of these tabs are visible is determined by the traffic stream traffic type, (see
screen shot).
The Results tab summaries the results for each controller stream, (see screen shot). The
Results tabs show the summary data, with convenient links to the remaining traffic
stream results (using the data editor).
Some of the tabs have additional buttons which carry out useful actions such as Add new
Conflict and View Signals.
There are no particular differences between using this screen or the data editor to enter and edit
pedestrian crossing data. However, you may find is easier to specify data using this screen.
Some elements such as connectors between crossings are best added and deleted via the
Network Diagram. Please read Chapter 14 to find out how to model pedestrians in TRANSYT.
This chapter includes a full description of all the data items required by the pedestrian model.
The Crossing tab accesses data that is common to the whole crossing (see screen shot)
The two Side tabs accesses the data that is specific to the two sides of the crossing
The Signals tab allows the controller stream controlling the crossing to be set
The Conflicts tab allows the conflicts between pedestrians and vehicular traffic to be
defined.
The two Side Results tabs covering the results for each side of the crossing
The All Connectors tab accesses the data for all connectors between crossings within the
network.
Details of the data items accessed via these tabs are not described here as this is already
covered in Chapter 14, but there are a few points worth mentioning here:
All connectors throughout the network are displayed on the All Connectors tab not just
the ones relevant to the selected crossing.
Although it possible to add new connectors via this custom screen, it is recommended
that connectors are established by connecting crossings via the network diagram. This
removes the need to know the specific format required to reference the pedestrian
crossing sides (see the screen shot below for an example).
In this example, side 1 of crossing 10 is connected to side 1 of crossing 11, and side 2 of
crossing 11 is connected to side 1 of crossing 12.
The Signals Tab View Signals button takes you to the data for the referenced controller
stream so that it is easy to make changes to it, if needed.
The Conflicts Tab displays the data in the form of a rotated data grid. If you have not
already specified any conflicts with vehicular traffic, by default, an incomplete (blank)
conflict will already be created for you, ready for you to amend. Additional conflicts can
be added using the button provided.
The Results tabs show the summary pedestrian data, with convenient links to the
remaining pedestrian results (using the data editor).
9 Data Grids
Data Grids provide a convenient way of viewing and editing several rows of data at one time.
They also allow you to manage large amounts of data in a concise and customisable manner.
You can display any number of data grid windows at one time, and the data you edit via Data
Grids will update and synchronise with all other appropriate screens. Data grids can be used to
change multiple items to the same value at the same time. Data Grids can even be used to add
and delete items from the TRANSYT network.
The data shown in each Data Grid corresponds to the type of the current Active Item, and the
columns correspond to the items you would see in the Data Editor for that data item. For
example if you click in the Data Outline on any Traffic Stream (or click on a Traffic Stream in the
network diagram, or any other screen), then any Data Grid screens will show all link properties
(ID, Name, Description, Saturation Flow, etc.) as well which Arm it belongs to, for ALL traffic
streams in the file. The Data Grid screen therefore gives you a convenient way to view and edit
all items of any particular type in the entire network.
If, on the Data Outline, you click on the Modelling subsection of a Traffic Stream, then any Data
Grid screens will change to show all Modelling properties for all Traffic Streams.
If you click on any Controller Stream (via any appropriate screen), then any Data Grid screens
will show all Controller Streams in the file.
The same applies to any other item of data that can be selected. Note however that you can
only show one type of data at any one time and you cannot, e.g. show controller streams and
links at the same time. You can however customise the columns shown, as explained further
below.
By using the padlock system (see section 6.9), you can show several Data Grids at once. This is
a convenient way to view both inputs and results simultaneously. The ability to customise the
contents of grids means that TRANSYT offers considerable flexibility for both data entry and
results viewing.
Click the Full-size button to toggle the top and bottom parts of the Data Grid screen on/off.
Turning them off can be useful if you are familiar with the data and want to save space on the
screen.
If working with for example a Data Grid showing all Links, you can make any Link the current
Active Item by clicking on the row header (the grey section at the far left of the row). Any other
windows showing links data will update accordingly.
You can make multiple selections by using the CTRL and/or SHIFT keys. When a row is
highlighted, the item is selected, and any other screens such as the network diagram will show
the same highlighting. E.g. in the screenshot below, some links in the Data Grid have been
selected by clicking in their row headers; the network diagram shows the same links highlighted
in orange. This also works the other way round click on items in the network diagram to see
them highlighted in the Data Grid.
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.
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.
Some fields will be greyed out and disabled (and/or may show N/A). In general these will
mirror the Data Editor, although the appearance may seem different in Data Grids. E.g.
Saturation Flow is greyed out if Has Restricted Flow is not ticked; several columns including
Saturation Flow will be greyed out if a link is a minor shared link.
Not all data can be edited using Data Grids. For example intermediate data such as most of the
resultant stages data and link green period data is shown in green to reflect the fact they are, in
effect results derived from other editable data, and cannot be changed directly, e.g. If Auto
Length is ticked, then the length of the traffic stream (or link) will be in green. Other items may
be greyed out or hidden entirely depending on the state of other data values, or on the mode of
operation TRANSYT is in.
As you enter data, the data and whole file are continuously validated and updated, and this can
result in other rows/columns in each Data Grid from disabling/enabling or changing, as you enter
data. Sometimes this is useful but if you wish to enter a large amount of data without
continual validation, press the Edit in Window button. The Data Grid will then switch to an
exclusive data-entry mode and validation will be delayed until you press the Done button.
Note that with some items such as checkboxes you may need to move to a different row before
the change is updated.
Occasionally you also may want to update multiple entries of the same data item with the same
value, e.g. you may wish to set all entry traffic streams to be the 200 metres long instead of
100. Simply hold down the CTRL key while selecting what entries you wish to change (all of the
same type, i.e. column). Now right-click to select the option Edit All. Type the new value and
press OK. Please note that there may be slight delay before the values are updated if changing
a large number of entries.
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.
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.
To add/delete rows, right-click on any row header. This will show a sub-menu where you can
choose to delete the current row or add a copy of the current row. You can also a new row,
which will use default values for all fields as opposed to copying the current row. For example if
showing a Data Grid of traffic streams, you can use this menu to add new traffic streams to the
network and to delete existing ones.
In some cases this menu contains an extra option: for example if you click on Sources on the
Data Outline and then right-click on a row-header, you can then select Add a New Source. This
will add a new source to the chosen traffic stream or link. These extra options are also useful for
any situation where none of the chosen item exists for the selected traffic stream etc.
You can swap columns by dragging column headers with the mouse.
Right-click on any column header to delete that column or to add any other column from the
drop-down menu of available items. Note that the available items include any data fields of the
current active data item plus any sub-items; e.g. if the Data Grid is showing Links, then you can
add any field from Links, Link Modelling, Link Flows, Give Way Data and so on. (You cannot
however go the other way round; if the data grid is showing Link Give Way Data then you cannot
add fields from Link Modelling).
You can also add fields by clicking Column Layouts>Add Columns From Data Editor; as you click
on fields in the Data Editor, they will be added as columns to the Data Grid, until you turn off
this mode.
For example to set up a Data Grid to show the ID, Saturation Flow and Length for all traffic
streams, follow these steps:
- Press the Data Grid button on the main toolbar to show a new Data Grid
- Click on any traffic stream in the Data Outline or in the network diagram. The Data Grid should
show all main fields for all traffic streams
- In the Data Grid, right-click on a column header and use the drop-down menu to select the
fields to add:
In this example Saturation Flow and Traffic Stream Length have been selected.
You can save data grid layouts by selecting Customise>Store Current Layout as a Custom
Grid. This will prompt you to enter a name, and this layout will then be available in the
Customise menu every time you run the program. Note that the layout will only be applicable to
the appropriate data type (e.g. Traffic Streams, not Links), and will only be visible in the menu
when the data grid is showing this data type. The saved column layout does not store the fact
that it applies to Traffic Streams and not Links; you must select a Traffic Streams data grid
before selecting a Traffic Streams layout. Data Grid Layouts are saved to your user preferences;
not in the file.
Select Customise >Custom Grids Manager access a screen where you can see all saved layouts
and rename/delete them. You can store multiple layouts for the same data item (e.g. Traffic
Streams). If you tick the IsDefault column then this layout becomes the default layout for that
data item and will be chosen automatically every time you show an appropriate Data Grid in
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.
TRANSYT grids offer the ability to mix both input and output data in a Data Grid. This allows you
to create exactly what output tables you want.
When adding columns to Data Grids, you can only add items that are at the same level or at a
higher level of hierarchy in the tree as displayed in the Data Outline. You cannot add items that
are nested further into the hierarchy. The easiest way to understand this is to experiment with
columns, but, it means that if you want to mix inputs and outputs, you must start with a Data
Grid of results, and then add the inputs (not the other way round).
As an example, the steps below show how to set up a Data Grid to show a simple selection of
inputs and outputs:
Show a Data Grid and click on Total Results>Vehicle Summary for any traffic stream in
the Data Outline. The Data Grid will show summary results for all traffic streams.
In the Data Grid, click the padlock icon once so that the grid will not change when you
click elsewhere in the Data Outline or other screens
Show the Data Editor if its not already shown and click on Degree of Saturation (click the
label, not the text box). The Data Grid should add this column. In the Data Outline click
Results>Queues and Blocking and click on Mean Max Queue.
In the Data Outline select any traffic stream and then in the Data Editor select Length.
Then select Is Signal Controlled.
You can rearrange columns by dragging the headers with the mouse.
The custom grid can be included in reports by using the options to store and manage layouts in
the Customise menu. (See Section 20.1.3)
You can view Data Grids of results just as with any other data item. There are a couple of
special considerations:
To show results for all traffic streams, show a Data Grid and then click on the Results section of
any traffic stream in the Data Outline. (The screenshot below shows the Results>Vehicle
Summary section. You can build any combination of columns as explained above.) For these
Data Grids, TRANSYT adds a special extra row at the bottom of the grid that shows the total of
all results for the traffic streams in the data grid. By default, these will therefore be network
totals, but, if you have filtered the grid to show only those items selected in the network
diagram, then the totals will be for these items only. In this way the totals row serves as a
useful mechanism for totalling any set of results.
You cannot show results for all time segments for all traffic streams (or links) but, this
information is available in generated reports.
The Filters menu provides a way to restrict the Data Grid to show only those items you have
specifically selected. This applies to any type of item. We recommend using the padlock system
to prevent Data Grids from switching to showing other data as you change screen see section
6.9.
To remove the filter, click Filters>No Filter or simply close down the Data Grid and open a new
one.
In the screenshot below, a Links Data Grid has the Show Only Items in Current Selection mode
enabled. A rectangular selection has been made in the network diagram to select everything on
the west side of the network, so the Data Grid shows only these links. If there is no
selection, then the Data Grid will be empty.
10 Network Diagram
In TRANSYT you can show one or more Network Diagram, each of which shows a graphical
representation of the current TRANSYT Network. It shows a depiction of all controller streams,
traffic nodes, links, lanes and traffic streams, indicates their types and various other parameters,
and can be overlaid with a wide variety of extra data, such as queue animations and CTM cell
occupancy animations. Launch a new Network diagram by clicking the Diagram button on the
main vertical toolbar.
The network diagram can be used to build a network from scratch because it lets you
add, delete and connect traffic nodes, links and other items.
The network diagram layout is saved automatically as part of the main data file - there is no
need to manage separate files.2
Much of the diagram is self-explanatory and we recommend that you experiment with the
various features in the toolbars and in the various context-specific menus available by right-
clicking on each of the different items in the diagram.
In general, clicking on a controller stream, traffic node, arm, link, lane, traffic stream, source,
OD Matrix or Location will make that item become the current Active Item, and any other
windows will update to show data for that network item e.g. the Timings Diagram, Data Editor,
Stage Sequence screen, Data Grids, and so on. Double-clicking on an item will often bring up an
appropriate data entry screen.
The icons along the top horizontal toolbar control the view of the network and turn on and off
various overlay tools and other features. The icons in the bottom toolbar represent a set of tools
which you can use to add and connect network items. Each icon is accompanied by a brief text
description, in order to assist with identifying its purpose.
Traffic Streams and links are both colour-coded to allow quick identification of their type, while
shared minor links are shown with dashed lines; bus and tram links are shown with dotted lines.
Pedestrian crossing objects are described in section 14.6. The blue cones around traffic nodes
indicate which traffic streams (or links) are providing the traffic that travels through the traffic
node. The green cones around controller streams indicate which traffic stream (or link) it is
controlling. Automatically, traffic nodes that are signalised have a solid outline, while
unsignalled junctions have a dotted outline.
By default, each traffic stream (or link) also shows a set of text information. This default text
set can be redefined by the user, but will initially show total flow and degree of saturation
(assuming that the file has been run at least once).
2
The only exceptions to this are when you reference backdrops and 3D Models.
There is also a safe mode that turns off certain features; select this via the main menu
File>Preferences.
In terms of general usage, you may find that the diagram is more responsive if you close down
any other screens that you are not using, including the Data Editor.
Use your mouse wheel to Zoom in and out and Zoom to Rectangle modes to zoom in and out.
(With the latter, drag a rectangle on the diagram to zoom to.) You can also zoom in/out by
using the mouse centre wheel.
Use your mouse wheel to zoom in/out, or alternatively use View > Zoom and Zoom to Rectangle
modes to zoom in and out. (With the latter, drag a rectangle on the diagram to zoom to.)
Hold down your mouse wheel while moving your mouse around to pan around your network.
Alternatively you can switch to View > Pan mode, or use the scroll bars and/or arrow keys on
your keyboard.
It is often convenient to keep the network diagram focused on the current item
you are working on. To do this, select the top toolbar option View > Always
centre on current data item. While switched on, the diagram will automatically
centre on whatever item you select, say, via the data outline.
The menu option View > Saved views allows you to select one of your stored views.
Views are fully compatible with the diagrams 3D mode, so that stored views
retain whether or not you were in 2D or 3D mode when you save it, as well as
storing your exact viewpoint.
The menu option Manage saved views brings up a screen which allows you to individually set
views to be included in TRANSYTs report.
The Is Default option allows one particular view to be defined as the view which is displayed
when the network diagram is opened. The Landscape option can be ignored as it is currently
not used by TRANSYT.
You can also copy the diagram to the clipboard by using the usual Copy button the main
application toolbar or by using the right-click menu in a blank part of the network.
The right-click menu also gives access to an Export menu, where you can choose to export the
diagram in various formats, including AutoCAD (DXF) format and Scalable Vector Graphics
(SVG).
See section 10.3 on how multiple views of your network can be stored, selected and also
included in a TRANSYT report.
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.
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:
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.
Sometimes it will be necessary to redefine which lanes are within which traffic streams, e.g. new
traffic streams are always created on the offside of any existing traffic streams this may not be
what is desired.
Use the Move lanes mode to move lanes between different traffic streams, on the same arm or
to a different arm. Also use it to change the order of lanes.
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.
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.
The green circles at the ends on each link or arm are called bend-handles, which serve as
points which you can grab with the mouse to move either end. You can add additional bend-
handles along the length of a link or arm in order to provide a point at which it can be bent.
Additional bend-handles are a consequence of splitting the link or traffic stream into multiple
Sections. To create an new Section right-click on the link and select Add new Link Section
or Add new Arm section. There is no limit to the number of sections/bend points you can add,
so links and arms can be made to curve along as detailed a path as you required. Use the same
right-click menu to remove sections or to straighten the link or arm.
Bend handles can be shown or hidden using the menu option Show > Bend Handles.
Like other objects, Controller Streams have their own right-click menu. These
menu options allow controller streams to be copied, added or deleted as well as offering a quick
way to launch a variety of related screens, such as the Timings Diagram. Timing Wheels can
also be displayed via this menu.
Timing Wheels allow stage timings to be displayed and edited directly from
within the Network Diagram. They are particularly useful for making manual
tweaks to the timings. An example of one is shown below:
The features and use of Timing Wheels are fully described in section 15.4
Simply click on any item in the diagram (traffic nodes, traffic streams, links, source connectors,
etc.) to select it. It will be shown with orange highlighting and any other relevant data screens
(e.g. Data Editor, Data Grids) will update to show data for this item, if appropriate.
To select a rectangular selection of items, use the top toolbar option Select > Rectangular
Selection and drag a rectangle on the diagram.
To move an item in the diagram, simply click on it and drag with the mouse.
The green circles at the ends on each link or arm are default bend-handles, which serve as
points which you can grab with the mouse to move either end. Similar handles also appear on
the Network Diagram Timing Wheels.
As you move a traffic node, you will notice that all connecting items also move with the node.
To avoid this happening, hold down the SHIFT key as you drag the node; the node will then
move in isolation. This method works whenever you dont want attached items to move as well.
Similarly, as you move entry traffic streams (or links) via their outermost bend-handle, you will
notice that they pivot around the traffic node they are attached to. To avoid this happening,
hold down the SHIFT key as you drag the bend-handle; the link will then move in isolation.
Note that you can move stop lines, which has the effect of moving all links that share the stop
line.
If several items are selected, then moving any of the selected items will move the entire group.
You can rotate an item, or a group of items, by firstly selecting them and then using the Rotate
Selection mode. The easiest way to do this is to use Select > Rectangular selection. The Rotate
mode is chosen by right-clicking in the selected area (N.B. watch the mouse cursor to ensure it
is still in this area) and choosing the menu option Tools> Rotate Selected items. The rotation is
carried out around the first point that you click on in this mode; drag the mouse in a circle to
control the amount of rotation.
To revert to a previous layout, use the Undo/Redo buttons together with the Save the network
diagram state in the main application Edit menu or toolbar.
Turn on the Show Grid mode (Top Toolbar > Show > Grid) to show a grid that items will snap to
as you move them. You can also align everything to the grid by right-clicking in an empty part
of the diagram and selecting Tools>Align all items to grid.
The spacing between all network items can be adjusted by right-clicking in a blank area and
selecting Tools>Adjust network spacing. Enter a number representing a percentage by which
you wish to increase/decrease the spacing e.g. 120% to slightly increase the spacing between
everything.
Similarly, the lateral spacing between links and arms can be adjusted - right-click in a blank area
and select Tools>Adjust link/arm spacing.
Right-clicking on any item will show a menu appropriate to that item, from where you can access
all its properties (this will show the Data Editor screen), and also certain commonly used items,
such as a links control type.
Uniquely, the right-click menu for Lanes also incorporates the right-click menu for traffic
streams. This is in order to make it easier to access traffic stream data.
Note that in some cases you will need to use the Data Outline to access exactly the item or sub-
item that you need.
Some screens, such as the Traffic Stream Data, Links Data and Signals Data screens, will update
to show data for the currently selected item, as does the Data Editor.
If the diagram already contains items, you can delete, make copies and add new items by right-
clicking on any existing item and choosing the appropriate Add or Delete options. Multiple item
deletions are also possible by selecting all the items you wish to remove and then pressing the
Delete key.
Individual Timing Wheels can be added by using the right-click menu of a controller stream.
You can also add items by using the toolbox at the bottom of the network diagram. There are
various alternative ways to do this; some are described below. In general, to exit a mode, right-
click in a blank part of the diagram, or click on the arrow button in the main toolbar.
Click on the traffic node item and then click anywhere in the diagram to add the node to
the network.
Drag the traffic node icon onto the diagram to add a traffic node
Click on the traffic stream or link toolbar item; click on the particular type of that item
that you want (signalled, unrestricted, etc.) and then click anywhere in the diagram to
add an item of that type. Each mouse click will add one arm/link section (i.e. a new
bend for the arm/link), until you right-click. To add a straight arm or link, click once to
set the start point, again to set the end point, and then right-click to finish. You can also
finish the arm/link using the middle mouse button, which has the effect of staying in
arm/link-adding mode, so that you can easily add further arms/links of the same type.
N.B. when adding a traffic stream you are, in fact, adding a traffic stream within an arm.
If you want more than one traffic stream within an arm simply use either of the right-
click Add copy traffic stream or Add new traffic stream options.
Drag any of the individual traffic stream or link types onto the diagram to add an item of
that type (you will then need to reposition it)
NB you do not need to necessarily use the different traffic stream or link types: you can
add any type and then right-click on the newly added item and use the menus to change
the control type and give-way properties etc.
An OD matrix can be created using the same two methods (drag or clicking) as described
for creating nodes. When an OD Matrix is created a single Location will also be created
automatically
When creating additional Locations, select which OD matrix it will apply to first, then click
or drag the Location icon
You can also add arms, traffic nodes, links, etc. via the Data Outline, as with any other data
item, in which the new item will appear in an arbitrary position in the diagram. Data Grids and
some of the dedicated screens can also be used to add items.
Depending on options you select in the (User) Preferences screen, the network diagram
may prompt you to enter an item ID each time you add a new item.
You can merge Library Files into your existing network via the Junction button on the bottom
toolbar. Library files can be added to the network as many times as you like and at any time.
The use of Library files makes the construction of your network a lot quicker as it will often be
quickest to add a pre-prepared junction to your network than to start from scratch. Library Files
can be regarding as building-blocks for your network.
Use the Connect bottom toolbar item to connect items in the following ways:
Click on a traffic stream, lane, or link and then click on a traffic node to set that node as
the traffic node for that item. If the selected item is already connected to a traffic node,
the new node will replace the old node.
Click on a traffic stream, lane, or link and then click on a controller stream to set that
controller stream as the controller stream controlling that item. If the item is already
connected to a controller stream, the new controller stream will replace the old controller
stream.
Click on a link and then click on a second link to connect the first link to the second link.
(I.e., the first link will then be an upstream link (or source) of the second link.)
Click on a lane/traffic stream and then click on a second lane/traffic stream to connect
the traffic stream associated with the first lane/traffic stream to the traffic stream
associated with the second lane/traffic stream, (i.e. traffic streams are connected, rather
than lanes.)
Click on a link and then click on a connector to disconnect the existing source link for that
connector (if one exists) and connect the new link as the new source.
Click on a Location and then click on a traffic stream/link to set that traffic stream/link as
an Entry for that particular Location. Click on a traffic stream/ link and then click on a
Location to set that traffic stream/link as an Exit for that particular Location. Note how
the order in which you attach the traffic stream/link to the location determines
whether or not the traffic stream/link is defined as an entry or exit for the
selected Location.
Use the Share Links bottom toolbar item to set up shared stop lines. When in this mode, click
on a link and then click on a second link to assign the second link as a minor link of the first link.
The first link must already be a major shared link (which is true by implication if it is the only
link at a stop line). To unshare a link, you can view its Properties and untick the Is Minor
Shared Link property.
It is possible to curve source connectors in order to offer a more realistic visual path for traffic
through junctions and to help avoid unnecessary overlaps of connectors. Right-click on the
source connector and select Recurve - The connector is automatically split into a number of
even-length sections with bendhandles joining each section (similar to those on traffic streams
and links) and the connector is curved appropriately for the situation. A connector can be
straightened again using the Straighten right-click option.
Individual sections can be added and deleted using the right-click menu. Individual connector
bend-handles can each be manipulated to form whatever shape is required, but are hidden by
default. While the connector bend handles are hidden the shape of the connector curve cannot
be directly manipulated. Use the Top toolbar menu item Show>Connector bend handles to
reveal these.
To quickly re-curve all source connectors in the network, right-click in the network diagram and
select Tools>Recurve All Sources. An equivalent option also exists to re-straighten them.
Editing the position of some components of the network can sometimes result in unsatisfactory
curves. If this happens, simply use the Recurve option again, either on individual connectors or
on the whole network.
You can add textual annotations to the diagram via the Label Bottom Toolbar option. In this
mode, click anywhere on the diagram and type the annotation. You can then move and resize
the annotation by dragging it as with any other item. To resize it, click on the label and then
drag the red handles as either end.
The top toolbar Show menu lets you choose whether to display a variety of items. A number of
these are described below while the remaining ones are described in the following sub-sections.
Stop lines, bend handles, connectors, and connector bend handles can all be turned on and off
from the Show menu. Stop lines of signalled traffic streams and links are represented by black
square brackets, located at the downstream end.
When not using any background image the current scale is unimportant, but when an image IS
used, it may be desirable or necessary to change the scale of the diagram to match that of the
background image. In order to do this simply add your background image to the network
diagram, line the scale ruler up with an item on the background of a known length (e.g. image
scale, building, etc.) and right-click on the ruler. This will bring up the only option Adjust
Scale. Click this and enter the length of the background item. This changes the diagram scale
to that of the background.
If you have difficulty locating the Scale on the diagram then right-click on the network
background and use the option Tools>Go to Scale Ruler.
Once your network is adapted to fit your diagram, the Link Lengths view (section 10.8.8.1) can
be used to quickly check to see if youve forgotten to enter any of your traffic stream (or link)
lengths.
10.8.1.2 Compass
A compass can be displayed or hidden using the Top Toolbar>Show>Compass option. Drag the
bend handle at the end of the compass to orientate and resize it.
10.8.1.3 Key
Show/hide the key by selecting the Top Toolbar>Show>Key option. The key, when visible,
displays the animation time within the cycle and which step within the cycle is current. This is
particularly useful when running animations screen captures will include the key and hence
offer information on what time the image represents.
The key shows additional relevant/essential information, such as the type of overlay, and in the
case of the traffic model type overlay, the colour scheme used.
An example of the tool tooltip for a Lane is shown below. It shows the saturation flow value of
the lane itself, and additionally shows information about the traffic stream the lane is part of and
also identifies the Arm in which it belongs.
Turn on either Show Upstreams or Show Downstreams mode (Top Toolbar > Show >
Link/Stream under cursor) to check the direction of traffic flow along traffic streams (or links)
and also to give an overview of which streams or links feed into which other streams or links.
While in this mode, hover the mouse pointer over any traffic stream (or link) to show yellow
arrows on the upstreams or downstreams of that link or stream. Use the Reset option to come
out of this mode.
Traffic Nodes are represented by circles. The Traffic Node cones show coloured cones indicating
the traffic node for each traffic stream (or link). The controller stream cones, shown in a
different colour, indicate which controller stream (signals) is associated with that particular
traffic stream (or link). Each traffic stream (or link) traffic flow feeds into the traffic node, but
its signals are controlled (if relevant) by the associated controller stream.
For clarity, you may wish to turn the cones off. For convenience, when a network item is
selected the cones associated with that item will still continue to be displayed, even when the
cones for the whole network are switched off.
You can also show flow cones highlighting the connections between traffic streams (or links).
Use the top toolbar Backdrop options to select between showing the Network, the background
image(s) or a combination of both. Selection can be achieved either using the drop down list
(click on the down arrow) or by clicking on the icon itself to toggle between the options.
The Manage backdrops option offers a shortcut to the relevant part of the Network Options
screen.
Use Fast Mode to turn off certain textual items to increase the drawing speed.
10.8.6 Signals
Use this top toolbar set of options to display actual signal states for each traffic stream (or link),
on the complete item and/or just the stop line and/or connectors. Use the Animation Controls
screen to set the point in the cycle to display signals for, or start the animation to animate the
signals.
You may wish to use this in conjunction with the Timings Diagram, Stage Sequence screen or
Timing Wheels so that you can see the signal plans for one or more controller stream at the
same time, as in the screenshot shown.
Optionally (and by default), the current stage running at each controller stream is shown
underneath the controller stream number in brackets.
Starting red-with-amber times and end-of-green amber times will also be shown in addition to
green and not green when the network options Display Red-with Amber and Display End-of-
green Amber are enabled.
Signal stages can also be shown on the connector lines This can help to identify signals which
have been incorrectly set up. E.g. green connectors that cross each other path may indicate this.
It also makes them easier to see, particularly for larger networks where you will tend to zoom
out more.
It is also useful to be able to clearly see which phases are controlling which traffic streams.
Selecting the Show phases option displays throughout the network a circle on top of the stop line
of each signalled traffic stream indicating the controlling phase(s).
For convenience, when a controller stream is selected the phase circles associated with that
controller will be displayed, even when the option to show them for the whole network are
switched off. The circles also indicate their signal state when using the animation controls.
Use the Show Effective Greens option to show yellow arrows on any traffic stream (or link)
whose controlling traffic stream is showing a green signal, taking into account start/end
displacements, for the current point in the cycle. (Adjust the point in the cycle using the
Animation Controls screen.) If a traffic stream or link is not signalised then it is considered to be
permanently green. This mode can also be useful for displaying the differences between actual
greens and effective greens, if you combine it with the Show Signal States mode.
In the screenshot above, traffic stream 45/1 towards the bottom of the network is showing
actual red, but the yellow arrows indicate that traffic is still be crossing the stop line.
Use this tool to fade out all items in the network other than the selected type. In this way you
can easily see where the bus, tram and pedestrian items are, as in the screenshot below, where
Highlight Bus Network has been chosen. To restore normal appearance, select Reset.
A variety of tools are available via the top toolbar Data menu for the visualisation of traffic
stream (and link) lengths, queues and traffic flows. To show queues, you must have
successfully run the file at least once. Use the Summary Results screen to check the status of
this run data. If no data is available, you can still select the options, but no queues/animation
will be visible.
Note that you can scale the relative width of all queue and animation bars via the network
diagram Options screen.
Each of the available Data menu items are described in the following sections.
Queues, flows and occupancy overlays only show the uniform component of these
items. They still offer useful insight into how the traffic in a network would
behave. The MMQ overlay does include the random component of queue.
In the screenshot below, all the streams on the left-hand side of the junction are all 100m long.
Link Cx-long has been stretched to be longer than its real length so the yellow bars stop short of
the ends of the streams, and finishes with a dotted extension line. Stream C-short is too short,
indicated by the yellow bar showing a thicker section at one end. When the streams are
positioned correctly, the lengths of the yellow bars will exactly fit the streams, as in the case of
streams C-right.
For internal streams (and links) the discrepancies can also be seen along the source connectors.
Often, it will not be possible to have all of these lengths matching simultaneous since the lengths
of the connectors can (and probably will be different and the length of the link is represented in
TRANSYT by a single (average) length.
other). You may wish to adjust the Other Overlays width (see Options > Data overlay) to
adjust the width of the bars to suit your needs.
The mean maximum queue is only an approximate average of the maximum back
of queue that is likely to be encountered, and it will therefore be exceeded a
significant amount of the time.
10.8.8.5 Queues
In this mode the uniform component of the queue on each traffic stream (or link) is shown. The
queues are shown at the moment in the cycle time as set in the Animation Controls screen, so
you can animate the queues by starting animation via this screen. It may also be useful to show
signal states at the same, as in the screenshot below.
What you see on a particular traffic stream (or link) depends on what traffic model it is using. If
PDM is being used, then red and green bars are used to show the uniform component of the
queue. If CTM is used, then red cell values are show instead showing where traffic is
stationary. The queues are shown at the moment in the cycle time as set in the Animation
Controls screen, so you can animate the queues by starting animation via this screen. It may
also be useful to show signal states at the same, as in the screenshot below.
The red bars (or cells) on each traffic stream (or link) represent stationary queues, which will
tend to build up while the signal at the stop line is showing red. When the signal changes to
green, the position of the stationary queue moves upstream as traffic at the stop line begins to
leave the queue. Where PDM is used, the green part of the bar can be thought of as
representing moving traffic. In other words, the red bars show where the front and back of
queue are located.
The uniform queue animation exactly matches the data shown in the Spatial Queue Graphs.
10.8.8.6 Flows
This mode shows the flow rate along every traffic stream (or link) for the current point in the
cycle time, as set via the Animation Controls screen. For CTM traffic streams and links, the flow
in each CTM cell is shown. Where PDM is used, the traffic stream and links are split into a
number of sections since PDM does not have cells as such. One obvious difference between
PDM animation and that of CTM is that you are likely to spot traffic disappearing at the stop line
rather than at the point it reaches the back of a queue. This is a simply a reflection of how the
PDM works i.e. traffic queueing vertically at the stop line.
The width of each green block is proportional to the flow at that point along the traffic stream (or
link). You can control the width scaling of the blocks via the Options screen (Options>Data
Overlays>Cell flow Size Scaler). Larger blocks show where the highest flows occur at the
current point in the cycle. They will be largest on links and traffic streams with the highest
flows, and at times where these are discharging the maximum amount of traffic, e.g. when a
queue begins to dissipate.
Please note that this mode shows no queues whatsoever only moving traffic.
Despite the slightly unrealistic nature of this output, it can assist in the interpretation of traffic
flow through complex junctions and larger networks.
It may often be easier to visualise the flow by showing them at the same time as the cell
occupancies. An alternative appearance is available by selecting Flows (arrow overlay), which
will use arrows for flows instead of blocks.
10.8.8.7 Occupancy
This mode shows cell occupancy at each cell for the current point in the cycle time as set via the
Animation Controls screen. The width of each blue block is proportional to the occupancy of that
cell. (Control the width scaling of the blocks via Options>Data Overlays>Cell flow Size Scaler.)
As you change the timeline via the Animation Controls screen, the cell occupancy blocks will
move through the network, and in this way you can easily visualise the movement of traffic
through the network. Blocking back effects are also easy seen.
The maximum occupancy of each cell is proportional to the traffic stream (or link) saturation
flow, and the pedestrian link has an arbitrarily high saturation flow. The resolution of CTM cells
is determined by the number of time steps in the model and the cruise speed of each link.
If the Stop line Saturation flow has been set to be different from the Cell Saturation Flow for a
traffic stream (or link), you will notice the difference between the width of a full cell at the stop
line compared with the rest of the CTM cells.
In addition to the main data that can be superimposed on the network diagram TRANSYT has a
collection of useful other overlays (Top Toolbar > Data > Other Overlays). Only one overlay at
a time can be displayed.
Use the Value Comparison option to show blue highlighting on each traffic stream (or link),
where the depth of shading indicates the relative value of a chosen data field. By default, the
data field is set to Total Flow, so the deepest blues show the heaviest flows. You can control the
sensitivity of this feature via the Value Comparison Ramp slider (Top Toolbar>Appearance>Data
Overlays.
You can show visualisations of any other data item by switching on this mode and then clicking
on any data field in the Data Editor or a Data Grid screen. As long as the data field is numerical,
the network diagram will attempt to colour the blue overlay boxes according to the relative value
of this data field for each traffic stream and link. In the example below, the value comparison
tool is showing the relative values of Stop Weighting Multiplier for each traffic stream, and it is
immediately obvious that the user has entered a high (or non-zero) stop weighting for 3 of
them.
Select Flow Consistency to highlight any problems with flow consistency. Red or amber
links/sources indicate that there may be an inconsistency with the flows at these locations. See
section 13.2 for more details.
NB you can change the colours used from the default reds and greens via the User Preferences
screen.
Select Traffic Model Type to show the active selected traffic model type for each traffic
stream and link. It is always the model type that is going to be used by TRANSYT that is shown,
irrespective of the locally defined value, i.e. the active model type. The active model type is
not necessarily the same as that selected for a specific link or traffic stream, since the network-
wide options to force TRANSYT to use a particular traffic model may have been selected.
A number of overlays are also available covering the most used/important model
results. These are:
Degree of Saturation
Utilised Storage
Each of these overlays use colour coding on the traffic streams and links to indicate which parts
the network have the best and worst results.
The colour coding and value thresholds are hard-wired within TRANSYT so they offer an
absolute evaluation of the Network, rather than a comparative/relative one. The colour
thresholds for each overlay are as follows:
<=Sat. <=100%
Threshold*
*usually set to
90%
<=100%
Mean delay per PCU <= 20s > 20s >55s >80s
<=55s <=80s
<=200%
>=15kph >=5kph
Most items are self-explanatory and are not listed here other than the ones of particular interest
below, and the 3D options which are covered in chapter 11. Most tabs have a Defaults button,
which will restore the options on that tab to their default values.
Most diagram options are saved in the data file, so the same options will be used when you next
load the file.
Please also see the TRANSYT User Preferences screen for other options that may affect
the network diagram.
Add one or more background images via the Backdrops tab. Select Manage backdrops from
the backdrops dropdown menu and press the Add button to browse to a bitmap (bmp/gif/jpg
format), which will then be placed in the middle of the network diagram. Whenever you wish to
adjust the opacity, position and size of the image, you must select it in the list box.
New images will be automatically selected as you create them. When selected the network
diagram will jump to the location of the image, and will show the image with a red outline and
red handles, which you can use to move and resize it. Use the opacity slider to control how faint
the image is relative to the rest of the diagram.
You can add more than one image. For example, you may have several drawings of
junctions which you can superimpose on the diagram at the same time as an overview map.
Adjust the opacity, position and rotation of each image so that they overlay the relevant part of
the network structure.
The images are embedded in the main TRANSYT data file; there is no need to save the image
files separately. Note this is NOT the case with 3D model images.
Multiple Text Sets can be defined to store user preferences for displaying text on traffic
streams and links using the Text top toolbar menu. The Manage Sets menu option offers a
shortcut to the relevant tab of the Options screen.
A number of useful sets, including one selected as the default one is already set up when you
first install TRANSYT. These can be added to, adapted, or deleted. Use the Manage sets
shortcut to access these options. From here you can also set the default set (see screen
capture).
Text Sets are now within the users preferences (.config file) rather than within
the file so that they act as your personal collection of sets.
Within each set, settings are stored for traffic streams, links and connectors.
Sub tabs are used to set the data items separately for these items. There are
four positions where data can be displayed on traffic streams and five positions on links. The
data displayed can be any TRANSYT data field (i.e. any input data or output results).
For traffic streams, a data field can be shown at both ends (positions A and C), in the middle (B)
and also in front of the stop line symbol (E). Select the data fields to use by clicking on them in
the Data Editor (or a Data Grid) and then clicking the Select Field button. Alternatively, click on
the dropdown arrow next to the Select Field button to use the data tree structure instead. Tick
the 2D and/or 3D boxes to actually show the values on the diagram.
Similarly any data field can be shown on each link by setting up options in the Link Text sub-tab
- A data field can be shown at each corner of each link (A, B, C and D) as well as in front of the
stop line symbol.
Each text set can be selected using a button on the toolbar, either using the down arrow to
select or clicking on the symbol to toggle through each of the available sets.
To be reminded what items are being displayed, firstly ensure you have Show> Item Tooltips
enabled and then hover over the item to reveal the tooltip listing each item description.
Use the Manage sets shortcut to set the default set (see screen capture).
Via the Appearance tab of the Options screen you can change the appearance of a variety of
network diagram items. Many of the options allow items to be resized, re-coloured, or widened.
Some of the items you are most likely to want to modify are described below:
The foreground and background colours can be changed - A dark background and a light
foreground can be useful for high visibility visualisations.
The text sizes sub-tab offers you the option to change the size of the text on traffic
streams and links.
The data overlays sub-tab offers you the ability to change the height or width of many
of TRANSYT network diagram overlays. Please note that some sliders affect items in both
2D and 3D modes, such as the cell flow scaler, while some affect only 3D as indicated
by their names.
User arrows can be switched on so that you can set up arrows on each traffic stream (or
link) showing which way traffic is allowed to turn. Right-click on the traffic stream (or
link) and select from a left, straight or right user movement. The movement will be
depicted using a blue arrow at the stop line.
If you have dual monitor display, either right-click in a blank area of the network and un-
select Tools>Keep Inside Application Window each time you open the network diagram, or
set your preference via the User Preferences screen. The network diagram will then become
detached from the main TRANSYT window and you can position it on the secondary monitor.
Even those who are very familiar with TRANSYT can benefit from using 3D Mode, because it
allows:
the network, and its associated TRANSYT data, to be examined more easily.
more-easily fit the network on one screen
more-easily examine the results by changing your view point of the network
put the network into context by adding network artefacts, such as street furniture,
buildings, trees, etc.
display results in a more intuitive way
emphasise particular outputs using 3D, while using 2D for the rest
3D mode is enabled by selecting the network diagrams 3D menu option Display diagram in 3D
The screen captures below illustrate the effect of switching from 2d to 3D.
Orbit around current viewpoint: Move mouse with middle button (or mouse wheel) and
SHIFT key is down.
Move camera: Move mouse with middle button (or mouse wheel), OR use arrow keys
Zoom in/out: Scroll mouse wheel, OR use plus (+) and minus (-) keys
These instructions are also available from the 3D menu option 3D mouse/keyboard controls.
11.2 3D Results
While in 3D mode results such as text sets and overlays can be shown in the network diagram
exactly the same way as in 2D i.e. drawn on the surface of the network. Additionally there are
two ways to display data in 3D, so that it stands proud of the network surface. The first method
works in conjunction with the text sets (see Diagram Options > Text Sets) as described in
section 11.2.1. The second method shows 3D data that is more appropriately displayed along
the complete length of traffic streams (or links) These are called 3D Blades and are described
in section 11.2.2.
Any item chosen to be part of a text set can be selected to appear in either 2D or 3D Simply
tick the relevant boxes to display a vertical bar proportional to the value of the data. This, of
course, works only with numbers.
Select this
The screen capture shown above illustrates the use of the 3D text set bars. The degree of
saturation is shown by the vertical blue bars. The width and height of these can be changed
using Options>Appearance>Data overlays>3D bar base size and 3D bar height scaler sliders.
The colour can also be changed (Data Overlays>3D Bar colour).
Notice how both 2D and 3D items can be displayed at the same time the red/yellow/green
colour-coded traffic streams is as a result of selecting the Practical Reserve Capacity other
overlay.
11.2.2 3D Blades
Any item chosen to be part of a text set can be selected to appear in either 2D or 3D Simply
tick the relevant boxes to display a vertical bar proportional to the value of the data. This, of
course works only with numbers.
Traffic Blades
Flow
Queue
Occupancy
Each traffic stream or link (and connectors) is split into a number of cells. This naturally is the
case when using a CTM model for PDM the traffic stream is split into sections and the flow or
occupancy is calculated for each point based on the PDM traffic model results. The traffic flow
flow/queue or occupancy for each cell during each time segment is drawn with a height relative
to the value of that data item, i.e. they can be animated over time using the Animate screen.
These blades each have an equivalent flow or spatial graph, as they are, in effect, showing the
same data. Although these animations only show the uniform component of the items shown,
they retain their usefulness in illustrating the general behaviour of traffic within a network or at
a single junction and can help considerably when carrying out diagnostic work on a file.
Traffic blades (below): This shows both moving traffic (in green) and stopped traffic (in red) in
the one blade overlay. Currently these blades are only shown on CTM traffic streams and links.
Flow blades (below): This shows where moving traffic is. Stationary traffic is omitted.
Queue blades (below): This shows only stationary traffic. Currently these blades are only shown
on CTM traffic streams and links.
Occupancy blades (below): This blade uses just the one colour (blue) to indicate where traffic is.
It does not differentiate between queue and moving traffic.
No models are supplied with TRANSYT, but a wide variety of models can be sourced from a
number of internet sites - Just search for Collada files.
Once you have created or downloaded your first models you will find that they are
not just a single file The model is a collection of files including surface rendering
graphics that are required in addition to the model DAE file itself. However, most
models will be stored or downloaded as a single compressed file. You should un-
compress the contents of the file into a single folder and give that folder a unique
name. You should then ensure that all your model folders are located within the
one master folder. Finally to access these models you need to tell TRANSYT
where this master folder is (See left-hand screen shot below). This can also be
set via File>Preferences.
To add model to your network select Add from the Options>3D Models tab and select the DAE
file This should be located in the models sub-folder of the particular folder used for that
model. You may add the same model multiple times into your network.
Unlike backdrops, these 3D models are only referenced within TRANSYT so will
only appear automatically in your TRANSYT file so long as the same models exists
in the same locations relative to the master folder. If you wish to send a file to a
a colleague or client and wish to use3D models you will need to separately send
them the individual folders containing you models and then ask them to set their
TRANSYT model folder to the folder in which they have copied these to.
The 3D models are highlighted and manipulated in the same way as for backdrops, i.e. the
network will jump to the item (shown as a red framework) when you select it in then list.
When you add a new model it is automatically selected. To rotate or enlarge grab the red bend
handles, hold down the left mouse button and drag. Make sure that you have the 3D menu
option Show 3D models switched on if you are manipulating a 3D model.
To get rid of a reference to a model, select it in model list and press the Remove button or
simply select it in the network diagram and press the delete key. Model references can only be
removed one at a time.
Currently it is assumed that all models will start at height zero, i.e. they site on the ground
You may find some ready-created models that either start in mid-air, are on slopes, go below
ground, etc. There is no option in TRANSYT to change the height of such models, and without
this ability, you will probably find these particular models are not very useful in TRANSYT as they
will look rather odd.
Although the network file size will be unaffected by the number of models referenced, you may
find that the use of a lot of 3D models may slow the performance of the Network Diagram. If
this happens there is a 3D menu option to hide them until you really need to display them.
TRANSYT 15 allows a single fly through a network to be stored within the data file. To record
one, simply select the 3D option Fly through to show a small dialog screen (see screen shot
above).
Press Record to start recording any then click back to the network diagram to make your
movements of the network. You can use all the same keyboard and mouse options that you
would normally use to change your view point of the network over time, i.e. there are no special
movement options specific to the fly through feature.
If a recorded fly through already exists and you press the Record button, you will be asked if
you wish to overwrite the old one.
The pause button allows you to stop the recording temporarily. While paused, you can still
change the network position using all the same controls. One use of this feature is to store a
presentation that is a timed set of snapshots of the network This can be achieved by recording
pausing, moving your viewpoint, and un-pausing to record the new view point, and to repeat this
as many times as needed. It is best to give each view plenty of time as when you play it back
you can increase the speed while it plays, but you cannot decrease it.
There is also a repeat button, so that you can leave an animation to play continuously in a loop.
Please note that all Network diagram display options and standard
animation controls can still be used in the middle of a recording, or a
playback. These are NO recorded. This is because you are only recording
the change in viewpoint and NOT what data is displayed or animated
They are totally independent of each other.
Particularly long recordings will increase the size of your data file
significantly.
Analysis Sets allow you to store multiple sets of data within a single file, representing, for
example, different signal plans and flows for AM and PM peak periods.
Demand Sets allow you to store different sets of flow data, which can optionally be
combined together. Each Analysis Set uses a single Demand Set, but this Demand Set can
reference any number of other Demand Sets.
Time Segments are used when using TRANSYT with more than one time segment
specified. For example you can run the TRANSYT model over a 60 minute period using 4 time
segments of 15 min each. Flows can optionally be entered for each time segment, or you can
set up TRANSYT to produce flows automatically; in either case, a set of results will be available
for each time segment, along with a set of overall summary results representing the entire 60
minute period.
NB do not confuse Time Segments with Time Steps. Time Steps are used internally to
control the resolution of the model on a per-cycle basis and are independent of Time
Segments.
The current Analysis Set, Demand Set and Time Segment are always shown at the top of the
main window in Advanced Mode. Click on the icon next to each one to jump to the appropriate
part of the Data Outline where you can edit the definitions. The same icons are used throughout
the Data Editor and other screens to indicate where a data item is entered or is available for
each Analysis Set / Demand Set / Time Segment.
To change the current set, select it via the appropriate drop-down list. Any screens that show
data for each set will then automatically update.
Make sure you understand the distinction between editing the definitions of
Analysis/Demand Sets versus editing the actual data for each set. E.g. you may
have an AM Peak and PM Peak Analysis Set, each of which contains a separate set
of data. Edit the data via the normal data entry screens, making sure that you
have selected the correct Analysis/Demand set via the drop-down menus on the
main program toolbar.
The current analysis set and current demand set is also indicated by the
presence of an asterisk in the Data Outline, as an additional reminder of
which sets will be used when you run the file. For Demand Sets, this is not
necessarily the same set as you are editing/viewing at the time, as it is the
specific Demand Set referenced by the current analysis set that is run.
When you add a new Analysis Set or a new Demand Set, the new set contains a
copy of all the data for the previously selected set. E.g., all traffic flows for the
new Demand Set will be a copy of the flows for the last selected Demand Set.
When you start a new file, the file contains a single Analysis Set. To rename analysis sets or to
use multiple analysis sets the file must be in Advanced Mode (Main Menu: > Data > Show
Advanced Mode Items). You can rename it by locating it in the Analysis Sets section of the Data
Outline and then using the Data Editor to set its properties.
Although multiple Analysis Sets can be stored within one file, only one set of
results is stored at any one time, representing the results from the last-run set.
To run different Analysis Sets, you must select each in turn via the Analysis Set
drop-down menu and run each separately. You can however use the Run>Run All
Analysis Sets and Generate Report option to run all Analysis Sets that have their
Include In Report option set.
As an example, add a new Analysis Set (via the Data Outline), and note that the drop-down
menu at the top of the TRANSYT window now lets you choose between two Analysis Sets. Now
use the Data Editor or Main Data screen to view the network cycle time; note that the network
cycle time has an icon next to it to indicate that it can be set for each Analysis Set. Set the
network cycle time to 100s. Switch to the other Analysis Set via the drop-down and notice that
the network cycle time is now the value for the other Analysis Set.
For each Analysis Set, you must enter a Demand Set (e.g. enter D2 to use Demand Set 2).
This determines the flows that will be used for this Analysis Set. E.g. you may set up two
Analysis Sets with the same signal plan but different Demand Sets (representing two different
traffic forecasts, say), a third Analysis Set that uses a Demand Set which includes extra
development flows, and then a further two Analysis Sets using the same Demand Sets but
alternative signal plans or network cycle times. (In more complex scenarios it may of course be
easier simply to save the different setups as different files.)
The data items that can be entered for each Analysis Set are easily identified within the data
If a file contains multiple analysis sets, the results in the file will be those
of the last-run set. If you change sets, and wish to examine the results,
you will need to press the Run Evaluation button to repopulate the file with
the new sets results. This will also prevent the Report ever presenting the
results of one analysis set alongside the input data of another.
When you start a new file, the file contains a single Demand Set. To rename demand sets or to
use multiple demand sets the file must be in Advanced Mode (Main Menu: > Data > Show
Advanced Mode Items). You can rename it by locating it in the Demand Sets section of the Data
Outline and then using the Data Editor to set its properties.
Each Demand Set defines a separate set of flows, but the flows themselves are entered using
the normal data entry screens. This applies to OD Matrices as well, i.e. an OD-Matrix provides
access to define the OD flows for several demand sets.
If you need to add together multiple sets of flows, add a new Demand Set and tick the
Composite option; you can then enter the Demand Sets that you wish to add together to form
this new Demand Sets e.g. enter D1,D2,D3 to add together the flows for Demand Sets 1-3.
A Demand Set cannot refer to itself in this way, so you must always add a new Demand Set for
this purpose. If the currently selected Demand Set is composite in this way, then link flows for
individual links will be greyed out and will show the calculated total flow, as in the screenshot
below.
Use the Start Time option to enter a time of day that the flows are for. (This is only used for
labelling purposes when showing time segments.)
Entry Flows can be entered for each time segment using OD Matrices. The data
entered is for the currently displayed Time Segment on the time-segment drop-
down menu at the top of the main window. N.B. the Summary Time Segment
flows will always be zero as no data is specified for this drop-down selection.
If not using OD Matrices to allocate flows, the Total Flow and Uniform Flow for each link can also
then be entered separately for each Demand Set, using the Data Editor and/or Data Grids.
Time varying flows must be entered via an OD Matrix You can no longer specify them directly
via entry source flows.
In Analysis Set and Demand Set definitions, tick the Locked option if you have finished entering
data for the set and want to avoid accidentally altering data. In this mode, all relevant data
fields will be locked when this set is chosen. For example: create two Demand Sets, and lock one
Demand Set only. Now open the Local OD Matrix Data screen: the entry flows for the locked
demand set will be greyed out and disabled, but editable for the other demand set.
Although locking an Analysis set locks all signal timings, it does not prevent the timings to be
changed by carrying out an optimised run. Furthermore, locking an Analysis set does not lock
the data of the referenced demand set.
By default, a TRANSYT uses a single time segment which is the same length as the entire
modelled period. You can view and edit this via the Data Editor (Network Options>Network
Timings section) or via the Main Common Data screen. By default, there is a single time
segment of 60 minutes, giving a total modelled time period of 60 minutes.
To split the 60 minute period into 4 time segments of 15 minutes each, simply edit the Time
Segment Length and Number of Time Segments values.
Time varying traffic flows are allocated to the network using OD Matrices or directly onto links,
allowing flows to be specified for each time segment (See section 13.1.1).
After running such a file, the Time Segment drop-down menu at the top of the main window will
show an entry for each time segment, plus a special Summary item. Displaying any set of
results (network results, or results for individual links) will then show the results for the chosen
time segments. You cannot see all time segments within the Data Outline or on one screen
together, but generated reports can optionally show results for all time segments.
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.
If a traffic stream (or link) is fed by other traffic streams (or links), then it has one or more
sources. (In TRANSYT 12 and earlier these were referred to as upstream links). If a traffic
stream (or link) is fed by no other traffic streams (or links) then it is an entry traffic stream
(or entry link) and has no sources. However, TRANSYT still needs a mechanism for entering
values such as cruise speed and bus parameters for entries, and so in these cases, entries are
considered to have a default Entry source. A default source shows slightly different data
compared to a normal source.
In the example below, Traffic Stream 21/1 is fed by traffic streams B1/1 and A1/1, so Traffic
Stream 21/1 has two sources: Source 1 [Stream B1/1] and Source 2 [Stream A1/1]. These can
be accessed via the network diagram or the Data Outline, and each Source has a set of
properties such as the Total Flow and cruise speed etc.
In the same network, Traffic Stream B1/1 enters the network from outside, and so is an entry
traffic stream. It has no sources. However, clicking on the Sources section of Traffic Stream
B1/1 will show the properties for this items default Entry (Source), such as the entry cruise
speed etc. (NB Entry cruise speed means the cruise speed along the whole traffic stream for
traffic using this traffic stream as an entry traffic stream into the network - NOT the speed at the
entrance.)
To use time-varying profiles, you must set up the Network Timings options so that there is more
than one time segment (Outline: Network options > Number of Time Segments) - See section
12.1.4. You can then use the Time Segment selection dropdown located at the top right of the
main screen to select each time segment.
Flows are entered either via OD Matrices or can be entered directly on each link when Local OD
Matrices are not being used. Each method is described below:
Open your OD matrix and then select the required time segment. You can then enter data in the
usual way for that particular time segment. Select each time segment in turn to specify your OD
flows. Make sure that you specify data for every OD matrix in the network and for every time
segment. Varying flows can be applied to either traffic streams or link structures that use an OD
Matrix to allocate traffic to the network. If using this method, you cannot also use the direct
method that can be used with a link structure.
Each link and source has a new property called Profile Type (Outline: Link n>Flows and Link
n/Sources) that allows you to define what type of time-varying flow data you wish to enter.
Changing Entry Profile Type to GAUSSIAN will take the average Total Flow (rate) that applies
over the modelled time period and will apply a normal curve to the traffic profile so that it fits a
pre-determined distribution as used in the ODTAB option in ARCADY, PICADY and OSCADY
PRO. (This only works if you are using a 90 minute modelling period.) This is a convenient way
to model a typical peak curve without having to enter separate flows.
If you require more flexibility you can choose DIRECT as the profile type. Separate Total Flows
boxes will then be editable for each time segment. (See screenshots.)
Please note that the GAUSSIAN option is only available using the method described here. The
DIRECT type is the equivalent to entering time-varying flows via an OD Matrix.
Use the time-segment dropdown to see results for each time segment. You can also see the
results for a Summary Segment which represents the average across all time segments.
When optimising the results given will be those for the best timings found that minimises the
combined P.I. of the network for all time segments combined, i.e. it offers the best overall single
set of signal timings. It does not separately optimise each time segment.
Select the Flows tab to reveal a set of sub-tabs. The first sub-tab Flows displays the Total
Flow on the link. This is only editable if you are not using an OD matrix to allocate flows to that
link. For convenience you can examine and edit both the upstream and downstream link data
using the next two tabs. A Flow Consistency Tool is also embedded into this screen This is
described in section 13.3.
Accessed from Flows tab of both the Link Data Screen and the Traffic Streams screen, the flow
consistency tool shows details for the currently selected traffic stream (or link) and updates as
you change item. (You can change the current item by clicking on the blocks in the diagram,
and in this way you can trace your way through the network. Double-click on any block to go to
the link or source in the Data Outline/Data Editor.)
Since flows for traffic streams can only be specified using OD matrices, flows within the area of
the network covered by each OD Matrix will automatically be consistent as long as all the
required TRANSYT paths exist. However traffic flows across the boundaries of OD Matrices can
still be inconsistent This is where the Flow Consistency Tool is still useful.
The screen is designed to show the flows in and out of each traffic stream or link, and any
inconsistencies with those flows; and also acts as a map of which items are connected to the
current items. In the screenshot, the current item (i.e. the link last clicked on in the network
diagram or any other screen) is Link 15, and this is shown in the centre of the diagram. Traffic
on Link 15 flows into Links 43 and x11 and is shown on the right. On the left, are shown the
upstream link (4).
All other numbers represent flows on the link and on its upstream and downstream links. Some
numbers are the actual entered values; other numbers (generally in brackets) are calculated
values and show the computed contributions from each link. For details, hover the mouse-
pointer over any block to show a fuller description.
In the screenshot above, the user has entered a total flow of 100 PCU/hr on link 15. However,
the total flow entering the link at its upstream end is specified as 218. Since link 15 is fed only
by this one link, there is clearly a discrepancy in the flows which shows up as a warning in the
task list and is also indicated in the consistency tool. The rectangular block representing Link 15
is coloured red, and the upstream that could equally be wrong is also coloured red.
TRANSYT (internally) scales the upstream flows so that the total upstream flow matches that of
the total flow on link 15. These scaled numbers are shown in brackets (100).
An amber colour is also used to indicate where a discrepancy might exist (see screen shot
below). This is usually the case where traffic leaving a network has not been modelled on a
particular exit link. It is, of course technically OK not to model where leaving traffic goes when
using a link structure, but TRANSYT has no way to know whether or not it is simply traffic
leaving or a genuine discrepancy.
You can now see that Link 45 has a flow of 681 PCU/hr, and that it has two downstream links 17
and 18. The user has specified that 324 PCU/hr flows from Link 45 to Link 17. This is consistent
with Link 17 total flow. The flow is also consistent with link 18 and hence the downstream
rectangular boxes are green. However the total flow out of 45 is only 353 as opposed to the
specified total flow of 681. Therefore there may be an inconsistency (hence the yellow
rectangle on Link 45, but the missing traffic may simply have left the network. To avoid this
uncertainly you can model all leaving traffic on exit links.
Such warnings are also shown as information items in the Task List. If TRANSYT considers the
flow difference to be too great, then these will be shown as warnings/errors, and red colouring
will be used in the diagrams.
You can also visualise all flow warnings and errors in the network diagram, by selecting the Flow
Consistency other overlay.
OD flow allocation requires the use of a number of network diagram items such as Local OD
Matrices, WIDE-AREA OD Matrices, Locations and Paths:
A Local OD Matrix contains traffic flows between Origins and Destinations which are
defined as Locations in TRANSYT. Usually each junction will need its own OD Matrix,
although closely-space junctions and small networks can also be made to share a matrix.
Sharing of local matrices by more than one junction should only be considered
when the movements of traffic defined by the matrix is already known or can be
easily predicted.
A Location is a user-defined traffic entry and exit point into and out of a section of the
network. There can be any number of locations, and normally at least two.
A Path defines the continuous route within a section of the network related to an
OD Matrix. Each path starts at a location and ends at a location. Therefore, a TRANSYT
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).
OD matrices and locations are created in a similar way to creating links, arms and controller
streams. This is described in section 10.7.6. The OD matrix must be created first so that the
locations can then be associated with the OD Matrix. Note: Deleting an OD matrix will also
delete all of its associated locations and paths.
OD Matrix Location
Locations and paths can also be created manually from within the OD Matrix Data screen by
selecting the relevant tab, and right-clicking on the first column of the grid. The links or streams
of a path are specified by creating a list of link or stream IDs, separated by commas. The order
must make sense i.e. the order must match how the links or streams are connected in
TRANSYT. When modelling single junctions, the first link or stream of any path is likely to be an
entry link or stream and the last link or stream likely to be an exit (from the network) link or
stream.
In the case of Paths, however, it will often be far easier to let TRANSYT create the collection of
all possible paths for you. The Auto Calculate option will continually re-calculate all possible
paths based on the Network connectivity. All paths between OD pairs are created, except those
removed due the OD Matrix options set (described below). If a path already exists its existing
data will be used. The program will report how many paths have been calculated.
With the Auto Calculate option switched off you can alternatively use the Calculate Paths
button which calculates all possible paths on a one-off basis and the Clear Paths button to
delete them all. Paths names automatically include the origin and destination e.g. Path A to
B. See section 13.4.4 for an explanation of the allocation options that can affect the
generation of paths.
WIDE-AREA OD matrices are created in a similar way to ordinary OD Matrices. See section
13.4.5 for a typical order of construction. The WIDE-AREA OD matrix must be created before
the wide-area locations are, so that the locations can then be associated with the matrix. Note:
Deleting a WIDE-AREA OD matrix will also delete all of its associated WIDE-AREA locations.
Also note that a wide-area location should never be attached to a local location that is not
feeding into an ENTRY traffic stream or link. If this occurs by mistake, the flows in and out of
the wide-area location will not be assigned to the local matrix and will show up as a wide-area
flow discrepancy on the "resultant flows" tab.
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:
Path equalisation: This is the same as that previously provided in TRANSYT 14.0 - then the
only option. Wherever multiple paths are defined from a location to another location the traffic
travelling along that path is by default split equally between them as the allocation mode name
implies. This equalisation also takes account of the Allocation Type associated with each
individual path which allows fixed and percentage flow values to be set. No account is taken of
the number of lanes. See section 13.4.6 for details.
Lane Balancing: When selected, this mode assigns traffic to TRANSYT paths in such a way as
to balance flows across all traffic streams on each entry to the junction (i.e. those lanes whose
source of traffic comes directly from a TRANSYT location. Internal traffic streams are not
balanced see exception to this for CPDM flares on entries. This mode is useful for modelling
single junctions (e.g. crossroads, staggers and roundabouts). It takes account of the saturation
flow of each traffic stream (max flow for give-ways), while it is NOT influenced by the travel time
through the junction which reflects reasonably well the nature of decision making required by
drivers who are travelling through a single junction and choosing the most appropriate path
through it. For situations where flared junctions have been modelled explicitly using separate
CPDM traffic streams the balancing process is still applied, ensuring sensible balancing is
achieved on the approaches to junctions. Lane Balancing assumes full utilisation of Quick Flares.
For WIDE-AREA OD Matrices there is no choice of allocation process it uses Journey Time
Equilibrium Assignment More detail of this process is provided in section 25.11.
The Journey Time Equilibrium method assigns traffic to paths using an iterative process which
assigns traffic in such a way that the cost to traffic on each of the alternative routes is equalised.
This mode is most appropriate when applied to larger networks where simply balancing flows
based only on degree-of-saturation would not be good enough. This option is currently only
available through the use of a WIDE-AREA Matrix which feeds a set of local matrices (see section
13.4.2). More than one WIDE-AREA matrix can be used in order to feed multiple sets of
matrices, within the one network. If a local matrix is connected to more than one wide-area
matrix it should be noted that the assignment process only allocates flows from a single wide-
area matrix at a time and any newly assigned flows will therefore replace those from any
previous assignments. See section 25.11 for more detail on the Assignment model.
The allocation modes provided simply aid the process of establishing suitable
traffic flows throughout the network. Inevitably there will be situations where the
allocation of flows by these methods will not be suitable and in such situations
users have the freedom to specify flows in a more direct manner.
The local OD matrix data screen and wide-are matrix screen both have a number of other user
options that influence how flows are allocated or assigned These are set from the Local OD
Matrix Local Matrix tab or the Wide-Area matrices General tab as follows:
Allow Looped Past Exit Locations: Select this option to allow paths to be created that pass
an exit location. This option applies to Local Matrices only.
Allow Looped Paths On Arms: Select this option to allow paths to be created that travel
through the same arm more than once. Details of why this may be required are the same as
described for the following option.
Allow Looped Paths On Traffic Nodes: Select this option to allow paths to be created that
travel through the same traffic node more than once. A typical example of this is shown in
Figure 13-3 A path from location 1 to 2 can be achieved by travelling around the whole
roundabout and exiting at the last-plus-one exit, i.e. a wrap-around path. This type of path is
not auto-generated. However, in some situations, such as in networks containing banned turns
or extra-large roundabouts this may be a valid and or required manoeuvre for traffic, hence the
provision within TRANSYT to allow them to be created automatically.
Limit Paths By Length: Select this option to allow only paths that are a factor
longer than that of the shortest path to be created. This option allows you to
more easily remove unrealistic paths and hence improve your results and speed
up runs of TRANSYT.
Path Length Limit Multiplier: Paths longer than this number times the shortest
path (between two locations) will not be created.
Limit Paths By Number: Select this option to allow you to specify the maximum
number of paths created between any two locations. Again, this allows you to
limit the number of paths to only realistic ones, and hence also speed up runs of
TRANSYT.
Path Number Limit: Sets the maximum number of paths that will be created
between two locations. Care should be taken when using this option as too small
a number here could result in the removal of some genuinely realistic paths for
traffic.
Having set the path options, you will often want to check that the created paths represent
genuinely realistic paths for traffic - The easiest way to do this is to use the TRANSYT 15 path
filter option to display the paths associated with just one particular source LOCATION at a time.
By selecting each path in your filtered list, you can then examine the network diagram which will
highlight all of the traffic streams or links of the selected path. A Data Grid can also be used to
examine and filter data associated with OD Matrices, Locations and Paths.
You will not see the effect of the wide-area assignment path options on what
paths are created until the next assignment of flows has been carried out, i.e. the
paths displayed and their associated path flows and path journey times are that
of the most recently carried out assignment.
Validation of the specified OD Matrix data is carried out by TRANSYT, and any errors or warnings
will show up in the Task List. E.g. all specified entry links must exit; all specified exit links must
exist; paths must be valid; all specified links must exist; start and end Locations must exist.
Invalid paths are ignored by the OD Matrix Data screen.
The OD Matrix Data screen is simple to use, but may appear complex the first time you use it.
To help you familiarise yourself with it, below is a typical order of actions required to make use
of OD Matrices:
1) Create your network structure (e.g. traffic streams, links, traffic nodes and controller
streams (e.g. using the network diagram) in the usual way, if it does not already exist
2) Specify the Traffic Type for each traffic stream and link.
3) Add a Local OD-Matrix by dragging it from the network diagrams bottom toolbar.
4) Add local locations (also by dragging from the toolbar) one for each flow entry/exit pair.
Typically this would be one for each approach to a roundabout. Each location acts as
both an origin AND a destination, e.g. traffic entering on Arm A of a roundabout and
exiting on Arm A use the same Location. (See screen shot).
5) Add exit link or streams if the network does not already have them. Exit links or streams
can be set as unrestricted types as they are not being used to model any restriction to
traffic.
Please note that there is no need to create traffic nodes at the ends of these. Also note
that for links and traffic streams using CTM, the cell saturation flow will still restrict traffic
entering traffic streams and links, so should still be set appropriately (see section 18.3).
6) Connect each Location to the link (or stream) it is feeding. In that order
7) Connect each exit link (or stream) to its destination Location. In that order
Before defining any traffic flows you should consider whether or not you wish to use TRANSYTs
user-equilibrium assignment process. For larger networks the use of this method should be
considered.
If you are planning to use it (i.e. use a Wide-Area matrix) please skip Step 8 as your local OD
flows will be determined by the wide-area flow assignment process. Step 11 should also be
deferred until after the assignment process has been completed.
8) Double-click on the Local OD Matrix and add your origin-destination flows i.e. specify
the entry flows for normal traffic, buses and trams.
9) Disable any unwanted paths within your local matrices. N.B. With the Auto-calculate
button on, all possible paths from each location to each other location will be created
automatically. Please note that these will include U-turns (if possible with the given
network connections) and also possibly inappropriate wrap-around paths (if the network
is complex), hence the possible need to disable some paths. (Tip: Use the filter option to
display the paths for just one source or one destination at a time it will make it far
easier to see if you are missing any paths or have ones you want to disable.)
10) Set the required Allocation Types of each path (see section 13.4.6). Leaving a path as
Normal will leave the OD Matrix to allocate the available entry flow for that particular
origin and destination using the chosen Allocation Mode.
11) Check the resultant flows (these are the flows are will be applied to the Source and Total
Flow data of the relevant links and streams).
At the end of this process you should now have a structure that will allow you to change the
entry flows in the local ODMatrix and see these automatically assigned to the relevant traffic
stream (or link). An example of the use of an OD Matrix on a signalised roundabout can be seen
in chapter 28.
12) Add a Wide-Area OD-Matrix by dragging it from the network diagrams bottom toolbar.
Wide-Area matrices are shown in the network diagram as large lime-green squares.
13) Add Wide-Area locations (also by dragging from the toolbar) one for each flow
entry/exit pair. Typically this would be a set of locations surrounding an area (wide-area)
containing more than one local matrices (see screen shot). Wide-Area locations are
shown in the network diagram as small lime-green pentagons.
14) Connect each Wide-area Location to the one local OD-Matrix Location that it is to feed
traffic into. In that order. (See screen shot.) The local location MUST feed a set of
ENTRY links or traffic streams.
16) Assign your Wide-Area flows, therefore populating your local OD matrices with traffic
flows. Note that there is no automatic assigning of Wide-Area OD flows - Use the
Assignment Tools Assign from Wide-Area Matrix button.
17) Optionally, you may wish to check how the flows have been assigned and, if necessary,
apply assignment cost weightings to some traffic streams or links (see section 13.4.8).
These allow you to influence any subsequent assignment that you carry out.
Flows are specified in more-or-less the same manner for both wide-area OD matrices and local
OD matrices, but for details specific to Wide-Area OD matrices see section 13.4.7.
Flows are specified by filling in the Entry Flows matrices for normal traffic and for buses, trams
and pedestrians if needed. Totals from and to each Location are automatically calculated for
you. If no enabled paths exist between any two local locations, the corresponding cell in the
matrix will be shown in grey to indicate that it will NOT be possible to allocate the flow in that
cell. This helps to ensure that your network structure is as intended. You can still type in your
desired flows however as you can still enter data in the grey boxes.
Once the flows have been entered, there are local OD options that allow flows to be allocated to
links and streams. A slider is provided to shrink and enlarge the matrix in order to allow the
matrix to cater for the smallest and largest numbers of origins and destinations.
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 multiple paths (from one Location to another) exist, the user must specify how the
OD Matrix is to split the flow.
The splitting of flows between multiple paths is based on the user-selected Allocation
Type. The Allocation Types are as follows:
o Normal: Split OD flow using selected Allocation Mode (default: Lane Balancing)
o Fixed: User specified fixed flow on this particular path. Note: the wide-area
assignment process will not overwrite fixed flows.
o Disabled: This path is disabled, which prevents any flows being allocated to it, i.e.
its flows will be set to zero. N.B. this does not necessarily mean no flows are
assigned to the links or streams on that path, as other paths might assign flows
(i.e. resultant flows) to these links or streams.
With the Auto Calculate option switched off the Reset Flows button can be used to set all path
flows to zero. The Allocate Flows applies the flows to links and streams. The allocation of flows
to links and streams involves adding the path flow to each link or stream the path passes
through. Connector flows (i.e. source flows) are updated in the same way.
Entry links and entry traffic streams that have other traffic passing through them have their
Uniform flow value set to the entry flow and the Uniform flow Source Name set to the OD Name
to make it clear what has been done.
The top number is the sum of flows on paths between the ODs. The numbers in brackets
represent any discrepancy (resultant entry) between the entry flows and the resultant flows
(i.e. those actually applied to links and streams). Discrepancies between allocated flows and
Entry Flows can arise for a number of reasons, e.g. if the only path between an OD pair is
disabled, resulting in the OD flows having nowhere to be assigned to.
Links 1, 2 and 3 each have a different Allocation Types. Links 4 and 5 are set to normal the
same as for Link 3. The selected Allocation Mode in this exam500ple is Path Equalisation
Link 1s total flow is 150 as it is has been assigned a fixed flow of 150.
Link 2s total flow is 125 as it has been assigned 25% of the 500 flow.
Link 3, 4 and 5 each have a total flow of 75, which represents the equal proportioning of the
remaining 225 flow, i.e. 500 150 125.
An example of the use of Local OD Matrices on a signalised roundabout can be seen in chapter
28.
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.
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.
Discrepancies between the entry flows and those that are assigned to the local OD matrices can
arise whenever the physical path between a wide-area OD pair does not exist within the
network. However, disabled local OD matrix paths do NOT affect assignment These will show
up as local OD resultant flow discrepancies if it prevents traffic locally from getting to its local
destination. Fixed flows on local OD matrices will not be overwritten by the wide-area
assignment process so this can also lead to further OD resultant flow discrepancies.
The assignment process will always replace any Local OD matrix flows that are
covered by the wide-area matrix and will leave untouched those that arent, i.e.
traffic defined as travelling within the wide-area but never entering or leaving it
for example.
You can check that the created paths represent genuinely realistic paths for traffic by opening
the Paths tab and using the path filter option to display the paths associated with just one
particular source and destination LOCATION at a time (see Figure 13-13). By selecting each
path in your filtered list, you can then examine the network diagram which will highlight all of
the traffic streams or links of the selected path. You will find the highlighted paths easier to see
if you switch off the lane opaque option, and switch off many of the diagram show options
and the text sets.
You will not see the effect of the wide-area assignment path options on what
paths are created until the next assignment of flows has been carried out, i.e. the
paths displayed and their associated path flows and path journey times are that
of the most recently carried out assignment.
An example file showing the use of Wide-Area Assignment of flows is supplied with TRANSYT.
This is a variation of the TRL1 optimised network.
Although there are options to influence the wide-area paths created between each location pair,
once these paths exist, how much traffic uses each one is determined by the UE assignment of
flows from the wide-area OD matrix. If you have information that is outside of TRANSYT that
you believe will affect wide-area path choice, you may wish to influence the assignment process
to favour particular paths. This can be done by applying assignment cost weightings on
particular traffic streams or links (see Figure 13-14).
Assignment Cost weighting (%): Adjusting the assignment cost weighting (Figure 13-14)
will allow you to increase or decrease the assignment cost to any traffic passing through this
traffic stream or link, and hence will add to the cost of any assignment path that makes use of it.
The default weighting of 100% means the calculated assignment cost will be used unchanged; a
value of 0% will mean there will be no costs incurred on this section of any wide-area paths that
pass through it. Negative percentage weightings will cause more traffic to be assigned to any
wide-area paths that pass through this particular traffic stream or link.
Assignment costs are only ever used during the assignment process so they only
influence the wide-area assignment and have no direct effect on other TRANSYT
costs. The effect that using the assignment has on the flow volumes used by
TRANSYT, of course will affect many TRANSYT results.
Local OD Matrices can be used in conjunction with multiple demand sets. Different entry flows
can be specified for each non-composite demand set. Composite demand sets (i.e. those based
on other demand sets) automatically populate their OD matrices with the entry flows specified in
the individual demand sets which will automatically provide a valid composite set of link flows.
Therefore, to model composite demand flows, e.g. base + development, or separate flows (e.g.
am and pm peaks) multiple demand sets should be used and NOT overlapping multiple OD
matrices.
Matching the number of traffic streams and lanes either side of the boundary between one OD
Matrix junction and another avoids any possible confusion, but can result in unnecessary
network items being created. It is also possible to end one matrix and start the new one at an
existing break in the network structure, say, at a lane gain or lane drop along a carriageway as
shown in the diagram immediately above, or where a traffic stream splits from one two-lane
traffic stream to two one-lane traffic streams, but this can make it slightly harder to spot any
anomalies between traffic flows either side of the boundary.
Crossing boundaries (switching OD matrices) within a junction itself is highly likely to lead to
overlaps (which will generate errors) or wrong allocation of flows, so should be avoided.
Another consideration also applies where, for example, there is a dual one-to-one connection
between two traffic streams across a local boundary (as seen with Arm 1Ax and Arm C in the
Figure 13-18) the use of a single local location as in this example will have the effect of losing
the separateness of the two connections across the boundary. This means the total volume of
traffic flowing across the boundary will be consistent but there is no guarantee that, say, the
volume of traffic on traffic stream 1Ax/1 will match that of C/1. This is because traffic from
location 1 (which is the sum of the traffic from both traffic streams on Arm 1Ax) is being
reallocated by whatever allocation mode is currently selected for that local OD matrix either
path equalisation or lane balancing. As far as location 1 is concerned it is equivalent to the
situation shown in Figure 13-19.
Therefore, if you wish to preserve the consistency of traffic across the two separate traffic
streams you need to create an additional location on either side of the boundary - see Figure
13-20. This allows traffic to leave one local OD matrix via location 2A and 2B and to re-appear T
locations 1A and 1B. It will depend largely on the real situation you are modelling whether or
not the preservation of consistency between traffic streams is relevant.
The diagram below illustrates an incorrect modelling solution, where the middle traffic streams,
3/1 and 3x/1 fall outside of the Local OD matrices on either side. This situation will result in the
flow profiles across the boundary being lost. To preserve the flow profiles across a boundary the
traffic streams associated with the Local Matrices must be adjacent to each other.
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.
Before specifying traffic flows within the OD Matrix for each of the traffic type, the relevant
traffic streams and links must be defined as carrying buses or trams. By default all new traffic
streams (and links) are set to traffic type Normal, i.e. neither a bus nor a tram. To allow a
traffic stream to carry buses as well as normal (all purpose) traffic, the traffic type should be set
to Normal, Bus (see Figure 13-23). All combinations of Normal, Bus and Tram are allowed on
traffic streams. Links can carry only one traffic type.
OD Matrix paths for a particular traffic type only exist based on the definition of
the Traffic Types on each traffic stream, i.e. there will be no bus paths until the
traffic streams have been set to carry buses such that at least one path between
two locations has been made possible. In the screen shot Figure 13-22 four bus
paths have been generated, although the actual network may well contain many
more which carry normal traffic. For links, the paths are determined by the
Source Type.
Whenever separate bus and trams flows are specified, TRANSYT models their flow profiles
separately while still allowing the performance of each traffic stream to be reported, which may
or may not contain different vehicle types. As explained elsewhere, it also allows weightings,
bus/tram speeds (Outline: Traffic Stream n > Sources > Bus Free Running Speed) and bus/tram
stop data (Outline: Traffic Stream n > Buses > Stationary Time) to be specified and applied
appropriately - either to all paths using a particular traffic stream or to each separate path using
that traffic stream by using the Per Path facility (e.g. Outline: Traffic Stream > Modelling >
Buses > Per Path).
Although TRANSYT offers the ability to specify bus, tram and pedestrian flow data separately to
normal traffic, this is because it needs to model these traffic types differently and/or
separately. However, the traffic counts that you have available, may have been provided to you
in a number of different formats, e.g. as total PCU, total vehicles, vehicle mix (lights and
heavies), etc. This mix of traffic types does not necessarily need to be modelled separately and
hence a facility to allow such data to be specified directly in TRANSYT exists. The facility allows
you to specify a mix of traffic types, each with an associated PCU Factor. The PCU factors
allow TRANSYT to always use and report the number of PCU or vehicles throughout the network.
In addition to the core traffic types described in section 13.4.11 (normal, bus and tram) which
each have their own path structure, the normal traffic type can be split into a number of
extra traffic types. The traffic flows of these new traffic types are summed together to give total
normal traffic flows. By default, the normal traffic type is represented by just one set of
flows under the name normal. This can be renamed and added to, so that, for example you
could have light and heavy as two categories which together represent the sum total of the
normal traffic, as seen the screen shot.
New traffic types are added via the Data Outline. The steps required are:
1. Ensure your data file is in Advanced mode (as this facility is an Advanced one).
2. Go to Data Outline: Network Options > Traffic Options > Advanced > Normal
Parameters.
3. Click the Add a new Traffic Type button (You should now see that you have TWO traffic
types).
4. Double-click on one of them and rename it to whatever you want.
5. Rename the other one as well. For example you might choose Light and Heavy.
Please note, that it is best to keep the name as short as possible, while keeping it
recognisable. This is because some GUI screens and output tables work better with short
names.
6. If using Traffic Streams, and hence OD Matrices to allocate traffic to the network, you can
now open an OD Matrix where you will see that the Normal traffic type is split into your
new traffic types, and an additional tab called Normal (Total) is also present. This extra
read-only tab simply reports the sum of the different traffic types flows that make up the
total Normal traffic.
PCU factors are specified via the Data Editor (Network Options > Traffic Options > Advanced).
within the Parameters section of each of the traffic types in the data outline. This includes the
Bus, Tram, Normal and any additional normal traffic types, such as those shown below.
By default all traffic types in TRANSYT have a PCU factor of 1.0. This means that regardless of
what input or output units you choose for traffic flow, the results obtained will be the same. This
also has the simple implication that when importing older TRANSYT files (that do not contain any
PCU factors), the flow data used and how it is used will remain the same as before.
If you choose to specify PCU factors other than 1.0 (i.e. provide additional traffic flow
information) the choice of traffic input units will then make a difference to the results as
TRANSYT will interpret the traffic flows differently depending on the units. TRANSYT never tries
to convert the actual data supplied changing units only changes how they are interpreted. If
the flows youve entered are in vehicles, you need to tell TRANSYT this, by setting the correct
units, and PCU factors.
TRANSYT internally always maintains both the PCU flow and vehicle flow based on the supplied
data, the chosen units, and the PCU factors, so that it can always report and use the right one
for the right situation- PCUs for its capacity calculations and vehicles for its queue and delay
calculations.
If you save a file with flow units in Vehicles, please be aware that if the
file is subsequently opened in a version of TRANSYT prior to version 15.1.0,
it will not recognise the fact that the data is in vehicles. This will result in
an inconsistency between the flow data and the saturation flows (still in
PCU/hr) which TRANSYT will wrongly assume are in the same units. The
PCU factors in the original file will also be lost, which has the effect of
changing the results, as mentioned earlier. We therefore recommend that
anyone passing a file to someone else ensures they are using TRANSYT
15.1.0 or later.
if you choose not to use the Local OD matrices to allocate traffic to the network, TRANSYT will
still only allow you to specify a single total traffic flow on a link. If you wish to specify traffic in
vehicles, you will need to set PCU factors for the total flow and for each source flow. This
information is required so that TRANSYT will know how to convert the flows from vehicles to PCU
and vice-versa. Of course, you can always work throughout with PCU, in which case you can
simply leave all the PCU factors set to 1.0.
The OD Matrix and Path information is used by TRANSYT to calculate point-to-point journey
times which is always available via the Journey Time tab in the OD Matrix Data screen.
Selecting the Use For Point to Point Table OD Matrix option will result in an additional Journey
Time table appearing in the Report. Journey times are provided for all vehicles combined and
also separately for normal traffic, buses and trams.
When the auto-calculate option is used, the OD Journey Times calculated will be the flow-
weighted average of all path journey times between each pair of origins and destinations. A
path journey time is the sum of the traffic stream (or link) journey time for links on the path.
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.
The only output associated with paths are journey times, and the optional point-to-point journey
time tables. If you wish to examine particular paths in more detail the option
Tools>Collections>Convert Path to Route can be used to convert the currently selected Path into
a TRANSYT Collection. This then gives access to the Collection-based results in the Report.
Since the release of TRANSYT 14.2 for Transport for London (TfL), TRANSYT can now accurately
model the behaviour of pedestrians at traffic signals. Pedestrians crossing during the red man
are derived by the new model, as well as saturation flow rates during the green man. In order
to offer this capability TRANSYT requires the user to enter various pedestrian-specific data
relating mainly to the nature of the crossing, such as crossing length and crossing width as well
as some extra vehicular traffic movement data. Some of TRANSYTs existing data such as signal
timings is also reused by the model. The following sections describe in detail the data required
and the processes that need to be worked through to model pedestrians in the best way
possible.
The model has been derived from research based on the extensive analysis of
pedestrian behaviour in London only. Therefore, anyone wishing to use it to
model pedestrian behaviour at signals outside of London should consider the
appropriateness of doing so. Changing the Vehicle bunching scaling factor can
be used to assist with calibration of the model for specific crossings.
There is currently no dispersion model specific to pedestrians, but if you wish to change the
effects of the standard dispersion model the parameters are accessible for each side of each
crossing (i.e. each direction of travel) from the Advanced section of the Side data.
Pedestrians are modelled within their own network of pedestrian crossing objects. Use of
pedestrian crossing objects removes any need to set up a complex link structure, and have a
number of significant advantages over using a link structure as they:
The crossing object has two sides that are identified within TRANSYT as Side 1 and Side 2.
Double-clicking on one side or the other will take you to the data entry for that side, while
double-clicking on the line between them will allow you access to the overall crossing data. This
data is explained more in section 14.4, while there is more information about the network
diagram crossing object in section 14.6.1.
It is fairly common practice to use a single pedestrian link in TRANSYT to straddle the vehicular
links or traffic streams in order to represent a crossings existence and the average green time it
uses, when the intention is to not model the pedestrians using it. In order to model pedestrian
accurately in TRANSYT a number of steps are required as follows:
1. Firstly, you need to model the pedestrian flow in both directions. For this you use a
single pedestrian crossing object, which automatically models and represents pedestrian
flow in both directions. These can be added in the usual way from the network diagrams
bottom toolbar or via the data outline.
2. Secondly, where there is an island you need to model the movement from the kerb to the
island separately from the island to the destination kerb, i.e. two pedestrian crossing
objects should be used.
3. In order to model accurately the coordination of pedestrian flow across complex crossing
types (Figure 14-5), you will also need to connect each of the pedestrian crossing objects
to each other using pedestrian crossing connectors. These connectors are made in the
same way as for other objects in TRANSYT, but are different because they have
properties of their own. The distances between the crossings are represented by the
pedestrian connectors no links are needed, although the connectors themselves will
need their length and cruise speed specified. The default cruise speed of pedestrians is
5.4 Km/h (1.5 m/s).
4. Flow data also needs to be allocated to the pedestrian network using a local OD Matrix
see section 14.3 for full details.
5. Finally, the pedestrian crossing object data needs to be set correctly for the crossing, for
each side of the crossing and for their associated conflicts with traffic see section
14.4. Each crossing side is used in TRANSYT as the source of pedestrians (fed from an
OD Location).
There are a number of different pedestrian crossing scenarios that TRANSYT can model. These
are best described by illustration:
Where an island exists the two movements - from-kerb-to-island and island-to-kerb - need to be
modelled separately (Figure 14-3). The platooning effect of the first half of the crossing and
progression of pedestrians to the kerb of the next crossing is taken account of in the model by
connecting the two pedestrian crossings together.
in the usual way. The distance travelled and time taken by pedestrians to travel along the island
between the crossings is accounted for accommodated within the connector which requires both
a length and cruise speed to be specified.
The flexibility of the TRANSYT network structure allows it to model a wide variety of pedestrian
crossing situations. An example of a complex crossing situation is illustrated in Figure 14-5
which is a T-junction with a split approach on the arm of the T, and includes four separate
pedestrian crossings. Each crossing can be set up as described in the way described for the
earlier examples.
The distances walked by some pedestrians to reach each kerb is not necessarily the same. In
order to ensure that reasonably accurate progression of pedestrians across the junction is
achieved it is recommended that fairly accurate lengths are specified on each pedestrian
crossing connector.
Pedestrian links, as used in versions of TRANSYT prior to 15, can be imported and tolerated, but
no new pedestrian links can be created within TRANSYT itself. These are most likely to exist
only to indicate the existence of a crossing and which phase it is controlled by - Usually the
pedestrians themselves are not being modelled.
When imported pedestrian links exist in a network the flows (pedestrians) on these links have a
nominal PCU value of 1.0. Wherever input or output values are show in figures in units of PCU
(or derivatives of) you should interpret these as Pedestrians for pedestrian links. It is not
necessary to assign a 'real' PCU value (such as 0.2) to pedestrians since they do not mix with
other traffic, and it is the relation between the stream's flow and its saturation flow that is
important.
All results screens will show results for pedestrian links just as with vehicular links. In the report
pedestrian links are indicated using the letter P. As pedestrian links do not make use of the
new pedestrian behaviour model results associated with them should be interpreted with
caution. Unless pedestrian flows are very high, the delays and other results are likely to be very
low. However, the results still give indications as to the performance of the pedestrian links, and
are therefore a way of assessing and comparing provision for pedestrian passage. The Average
Delay result indicates the average time an average pedestrian has to wait to cross the road; the
Queue at end of Red represents the average number of pedestrians waiting to cross the road
when the pedestrian green signal starts.
The above all assumes that pedestrians cross only at the assigned crossing points and that they
do not display human characteristics such as giving up waiting, finding alternative crossing
points, crossing in gaps between vehicles or generally changing their minds. Because of this, we
recommend that you convert pedestrian links within imported files into pedestrian crossings as it
will allow you to more accurately model pedestrian behaviour.
Although not necessary, it is also possible to use separate OD matrices for pedestrians and
vehicles.
Full details of how to allocate flows to TRANSYT generally is covered in other parts of the User
Guide, e.g. chapter 13.
The Local Matrix tab option Allow Paths Past Exit Locations will often need to be
switched off, as it will be fairly common to wish to model pedestrians passing
pedestrian exit points (i.e. other locations) before leaving the network. In Figure
14-7 note how pedestrians walking from Location 8 to Location 5 will need to walk
past Location 7 without exiting the network.
Wide-Area matrices and the assignment model can only be used for vehicular
traffic.
In the example shown in Figure 14-7 note how there is no loop formed as
there are no connectors between the crossings. They are connected only
via the locations.
Pedestrian crossing objects are either created by using the pedestrian crossing icon on the
bottom toolbar of the network diagram, or by creating a pedestrian crossing object via the data
outline.
Optionally, you can select Allow Walk on Red. With this option selected, TRANSYT will use a
pedestrian behaviour model which estimates what opportunities there is for pedestrians to cross
during the red man, and how often they will make use of these opportunities to cross. This
offers improved results compared with simply assuming pedestrians only cross during the green
man period.
Irrespective of whether or not you are using the walk-on-red model, you can specify the length
of the crossing. This input parameter can be ignored if you are not using the walk-on-red model
and also do not wish to model the progression of pedestrians through the network.
The data described below represents the requirements of the walk-on-red model. If the walk-on
red model is not used, then the data requirements are reduced and the unnecessary items are
hidden from view.
In addition to using the Data Editor, data entry can be carried out using a dedicated crossing
data screen (described in section 8.5), which is accessed from the main vertical toolbar.
Length (m) is simply the length of the crossing from a pedestrian perspective.
Cruise Speed (kph) or Cruise Time (seconds). This value should be set to the
average speed of pedestrians on the crossing. A typical value for this has been provided
as a default, but it is recommended that this is changed when local information is
available.
Number of lanes are the number of lanes of traffic that pedestrians have to cross in
one go. Only include the lanes relevant to the pedestrian leg being modelled by the
crossing object, i.e. do not include lanes on the far side of an island as they are part of a
separate leg.
Crossing width (m) is the distance between the two rows of crossing studs. If
crossing studs are not present the crossing width should be measured using your own
judgement.
Vehicle bunching scaling factor (%) can be used to calibrate the pedestrian model.
The value of this factor will affect the amount of platooning of the vehicular traffic passing
over the pedestrian crossing. A value of 100% will result in the default level of
platooning to be assumed. Values above 100% should be used to model where
platooning of traffic is above average.
Please note that the bunching factors effect on pedestrian delay will also depend on
vehicle flow and saturation flow. The calculated pedestrian delay depends on the
availability of gaps suitable for pedestrians to cross within. Furthermore, the availability
of these gaps is dependent on both the headway (derived from the relevant saturation
flows) and also the proportion of bunching.
Additionally you need to specify data that is specific to each side of the crossing (see Figure
14-9). As previously mentioned, one side of the crossing is nominally called Side 1 and the
other Side 2. Where possible, when Side 2 must have the opposite value to Side 1, this
will be made read-only on Side 2 and is set automatically.
Additionally you will need to specify what signal phase controls the crossing, and also add a
blackout period on each pedestrian phase see section 14.4.1.
Finally you need to set up what conflicts exists between pedestrians and vehicular traffic see
Section 14.4.2. In this particular model vehicles never yield to pedestrians.
Signal data is set up for pedestrians in more-or-less the same way as it is for vehicular traffic
(Figure 14-11). Full details of working with signals can be found in Chapter 15. You will need to
reference the controller stream and phase that controls it. The phase should be specified as a
pedestrian phase Use the View Signals button to get to the phase data.
Setting a phase type as Pedestrians allows you to set a phase Blackout Time (s) - This is
the only signal data requirement, over-and-above that of a normal vehicular phase, that is
needed by the pedestrian behaviour model. This value is used to calculate the effective green
time for pedestrians for use by the pedestrian behaviour model. Figure 14-12 illustrates how the
blackout period appears in the Timings Diagram as a black extension to the end of the green
period. Any other effects that might influence the effective green time can still be specified
using a relative start or end displacement value in the usual way. These will be added to the
adjustment already made by the blackout time.
The pedestrian crossing object also requires the conflicts with vehicular traffic to be defined.
Each separate conflict needs to be defined. Conflicts can be added by selecting the Conflicts
section of a Pedestrian Crossing and then using the Add a new Conflict button.
The following data is required for each conflict (see Figure 14-13):
Controlling Type select whether pedestrians are yielding to a LinkShare (major link + its
associated minor links) or to a traffic stream.
It helps to know what this value is used for, as it helps you check you have
chosen the right option - This data tells TRANSYT which vehicular cyclic flow
profile to use.
If Out of junction is selected, TRANSYT will use the cyclic flow into the
downstream link (or traffic stream). If Into junction is selected, TRANSYT will
use the cyclic flow of the combined outflows of the upstreams.
Where traffic conflicting with pedestrians is leaving the junction, you should
reference the traffic stream or link immediately downstream of the crossing and
specify the Vehicle Direction as OutOfJunction.
Vehicle Saturation Flow is required only if the vehicle direction is Out of Junction. This
value should be the estimated maximum flow rate at the point that the crossing exists. For
Into Junction situations this value is ignored as the required data can be gleaned from existing
traffic data.
Vehicle clearance Time (seconds) is the time for traffic, referred to by this conflict, to clear
the crossing. This is to ensure that a suitable offset in the flow profile at the crossing is used by
the pedestrian model. Where the traffic being fed into the controlling link is from several
sources an average value should be applied - Ideally a weighted average.
Please note that for larger junctions you may wish to introduce an additional stub
link between the feeding upstream links and the downstream link (i.e. those either
side of the crossing). This new link becomes the conflicting link (as far as the
crossing object is concerned). This will allow the differing times it takes traffic to
travel to get to a point where they are conflicting with pedestrians at the crossing
to be taken account of. However, this will only be necessary for the largest of
junctions where there are significant differences in the vehicle clearance times.
14.5 Optimisation
In TRANSYT you have the choice as to whether or not pedestrian delays contribute to the
calculation of the Network Performance Index. For pedestrian crossing objects, this is specified
by using the Modelling Data option Exclude From Results Calculation (Outline: Pedestrian
Crossing n > Side 1 > Modelling).
You have this choice irrespective of whether or not you are using the pedestrian walk-on-red
model. The only difference is that if you have chosen to use the walk-on-red model then you are
then more likely to want to also INCLUDE pedestrian delay in the P.I. and hence influence the
optimiser to provide optimised timings that offer the best multi-modal performance.
Because Exclude From Results Calculation is specified on a crossing side by crossing side basis,
you can ensure that only those crossings you wish to influence the signal timings are included in
the calculation.
A global setting to exclude all pedestrian crossings/links from the results calculation (no matter
what the above option is set to is also provided (Outline: Network Options > Traffic Options >
Advanced).
For those crossings sides included in the P.I. calculation the cost of pedestrian delay is calculated
using the Pedestrian monetary value of delay. (Outline: Network Options > Economics).
See Figure 14-14.
Delay weighting (%): Adjusting the delay weighting (Figure 14-15) will allow you to increase
or decrease the cost of delay and hence importance given to the pedestrian delay on individual
sides of individual crossings. Higher values will encourage the optimiser to reduce delays if
possible at the expense of others.
Has Ped Gap Accepting Penalty: Additionally, the TRANSYT optimisers can also be influenced
through the use of cost penalties. When using the walk-on-red model a penalty can be applied
to the proportion of pedestrians over a user-defined limit that is crossing during the gap
accepting period. This period excludes the before-green and after-green periods (defined by the
model). This can be used to influence the optimiser to reduce this particular type of non-
compliance with the green man (and relatively safe periods either side) and hence potentially
improve the safety of pedestrians. Since the penalty is only applied to the excess, high penalty
costs are usually needed. You may also find that setting the limit slightly lower or higher than
you want to achieve will help you achieve the desired outcome.
Degree of Saturation Penalties: Although not part of the crossing object data, the use of
degree of saturation penalties may also be of use. Because the degree of saturation reported for
each side of the crossing relates only to the pedestrian green period (green man), the optimiser
can be encouraged to offer longer pedestrian greens by applying a limit to the DoS with an
appropriate penalty.
Max Queue Storage and Has Queue Limit: These two parameters work in exactly the same
way as those for traffic streams and links. They have been made to work with pedestrian
crossings in case they prove useful for particular modelling circumstances.
Pedestrian crossing objects are drawn in the network diagram in a distinctive way to ensure they
are easily recognised and they also have a number of unique features. An example of a crossing
object is shown in Figure 14-17.
Double-clicking on one side or the other will take you to the data entry for that side, while
double-clicking on the line between them will allow you access to the overall crossing data.
Right-click menus also exist for both the crossing and for the sides of the crossing that reveal a
menu of useful items, including the option to change some data items, reveal graphs and add,
delete or copy the selected crossing.
Mean Max Queues can be displayed using the same Top Toolbar Data option as used for vehicle
MMQs.
The Queues network diagram overlay (Top Toolbar > Data > Queues) can be selected to
display average pedestrian queues at each end of the pedestrian crossings for the current time
step They can be animated over time. Each queueing pedestrian is represented by a single
red square. Up to three rows of queueing pedestrians are drawn. The first two rows (nearest
the kerb) expand to contain a maximum of 6 pedestrians each, while the back row contains the
remainder of the queue.
The Flows overlay displays the flow of pedestrians across crossings and along connectors
between crossings. When animating flows over time, the pedestrian flows in each direction
(green blocks) are kept separate by displaying them on the top and bottom of the line that
crosses the road as shown in Figure 14-17.
Figure 14-17 Pedestrian Crossing object with pedestrian queues and flows
The Traffic overlay displays both queuing pedestrians and pedestrian flow over time.
The bars at either end of the crossing indicate the state of the signals, and the direction that
pedestrians have to look when crossing (as specified by the user) is also indicated.
The Flows overlay displays only the moving traffic, i.e. no queues.
Both of these overlays distribute the flow across both the connectors and the links and traffic
stream lengths. This enhances the animation of flows such that the conflict between pedestrians
and vehicles can be more easily seen. See Figure 14-18.
Figure 14-18 Conflicting pedestrians and vehicles using PDM Cell Flows
TRANSYT pedestrian results are presented in the Results section of the data outline as follows:
Results are presented for each of the two sides of the crossing the point at which pedestrians
can experience delays to their journey.
A pedestrian summary contains a collection of some of the key output values associated with
the crossing. The remaining sub-sections over similar results to that for vehicles. When using a
data grid to examine the results for all pedestrian crossings, TRANSYT automatically filters out
all but the pedestrian crossing data. (See Figure 14-19).
All summary items also appear in the other topic-based sub-sections. (see Figure 14-20).
Most output values related to pedestrians are shown with the appropriate units.
However, wherever TRANSYT refers to input or output values as per PCU or
PCU/hr where they relate to both vehicles and pedestrians, these should be
read as per pedestrian where it is appropriate to do so.
The key outputs that are unique to the walk-on-red model are as follows:
The pedestrian saturation flow is the maximum rate at which pedestrians cross when opposing
traffic is stopped and it applies to the GREEN+BLACKOUT period. The pedestrian saturation flow
increases with the numbers of pedestrians waiting to cross. To ensure that unreasonably high
saturation flows are not used, the pedestrian saturation flow is also capped. The cap is based on
the crossing width and an assumed upper limit for pedestrian flow of 82 persons per minute per
metre (Department for Culture Media and Sport, 2008).
The above four flow rates are shown only for pedestrian crossings using the walk-on-red
pedestrian model. The cycle is split up into four different time periods each representing a
significantly different scenario for pedestrians wishing to cross. The flows indicate the predicted
volume of pedestrians crossing during each of these periods. The time periods are calculated
internally within TRANSYT. N.B. Green is a reference to the green man period.
Ped Gap Accepting Penalty ( per hour) shown for pedestrian walk-on-red links only
This is the penalty cost added to the PI as a result of the level of pedestrian gap-accepting set by
the user being exceeded.
Links which are defined as pedestrian links can only exist within TRANSYT from having been
imported from an existing file. This capability is retained simply to allow pedestrian crossing
data to be retained. It is recommended that such pedestrian crossings are remodelled/replaced
using the new pedestrian crossing objects.
Pedestrian links that imported are drawn differently in the network diagram in order to
differentiate them from ordinary (vehicular) links. A white arrow is used to indicate the direction
of travel of pedestrians represented by the link. Example shown below:
Signals data can be viewed and (in some cases) edited using the Data Outline and Data Editor,
as with any other data. In addition, several screens provide graphical viewing and (in some
cases) editing. These screens are the Timings Diagram, the Stage Sequence Diagram, and the
Intergreen Matrix screen. Timing Wheels also offer stage editing and viewing within the network
diagram.
We recommend using the Timings Diagram and accessing stages and link green periods by
clicking and double-clicking on the relevant parts of that diagram. Individual Timing Wheels
(see 15.4) are a useful way to view and edit stage timings within the network diagram. Finally,
the signals data screen (see 8.2) is particularly useful for defining all aspects of your signal
timings quickly and easily.
Controller streams, by default, use the network cycle time (Outline: Network Options>Network
Timings). The cycle time defines the rate at which controller streams throughout the network
repeat their stage sequence.
The Restrict to SCOOT Cycle Time allows you to limit your selection of cycle time to those
compatible with SCOOT. An error will appear on the task list when this option is set and the
time is not compatible.
TRANSYT has adopted a single straightforward approach to representing signal timings in a way
that matches the data traffic engineers or planners will generally have to hand and helps to
ensure that novice users set up their signals correctly. Generally, the Signal data entered, such
as phase constraints and intergreens, act as a set of constraints on what stages, stage
sequences, and signal timings are possible and valid. Various tools are provided to generate
suitable staging arrangements and valid timings. These valid phases, library stages, sequences
and associated timings can be viewed and edited graphically.
The two Signal Representation Modes of TRANSYT 13 no longer exist in TRANSYT 15. However,
the Timings Diagram offers two different manipulation modes stage mode or phase mode.
A controller stream object exists that contains all the signal timing data, such as phases, library
stages, stage sequences and signal timings. Under the Properties controller data item,
additional non-modelling data can also be stored, such as manufacturer, model, site number,
etc.
A phase is a separate item within the controller stream which has its own properties. Signalled
controlled links and traffic streams reference the phase(s) that control them.
The screenshot below shows the TRANSYT Timings Diagram. All illustrated uses of the timings
diagrams are when it is in its Stage Mode rather than Phase Mode - Details of these modes
are described in 15.3.
Stages are shown in blue and interstage periods are shown as blank areas. Interstage times are
derived from the phase-to-phase intergreens that you specify. The Intergreens show up as
green diagonal lines.
Phase green times can extend beyond stage starts/ends via link-losing or gaining delays. The
diagram can be edited using the mouse, while certain data may also be entered numerically such
as phase delays, which phases run in which stages, stage end times, and even the stage
sequence. Note that in this example; stage 6 ends as soon as the first phase (phase A) running
in that stage ends, and phase B has a phase-losing delay, as is consistent with standard stage
definitions. Similarly for Stage 7 and Phase F.
In TRANSYT, actual greens and effective greens are explicitly shown as separate values,
wherever possible. In TRANSYT stages and link timings are always viewed and manipulated
using actual timings. Optionally, you may overlay the effective timings, which are shown in
the Timings diagram as lighter coloured bars above each actual green block. In the screenshot
below, each links effective green starts and ends a few seconds after its actual green.
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.
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.
The advanced network options allow you to set a network-wide starting red-with-amber time
(Outline: Network Options > Signals Options > Advanced) and for each phase, an end-of-green
amber time (Outline: Controller Stream x > Phase x).
When the amber options are enabled via the Network Options (or View Tab on the Main
Data screen) the amber times will be displayed in TRANSYT for all phases except pedestrian
phases, in the following locations:
For details of using amber times in the Intergreen matrix please see section 15.5.6.
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.
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.
Each controller stream has a current Stage Sequence and also a set of alternative stage
sequences. The currently used sequence is indicated in the Data Outline, Timings Diagram and
the Stage Sequence Diagram with an asterisk. The current sequence is a property of the
controller stream and can be changed at any time to reference/use a different sequence. The
selected sequence must exist for TRANSYT to run. A missing sequence will NOT be generated for
you (unlike referenced Stages within the current sequence).
Stages Sequences can be defined manually or you can use Auto Generate Sequences either
from the Signals Data Screen or from the Tools menu of the Timings diagram to generate a set
of the top ten shortest sequences. For details of other stage and sequence generation options
please see the Timings Diagram (section 15.3).
To manually define which stages run in a sequence either enter a comma-separated list of
stages (Outline: Stage Sequences/Stage Sequence n) or use the Stage Sequence Diagram to re-
define stages, add new library stages to the sequence or re-arrange the order of existing ones.
For full details on how to do this please see section 15.6.
The nominal first stage in the current stage sequence is indicated by a + sign next to the
sequence.
Like many items, stages have IDs. The stage number is simply the stage number. For any
operation where TRANSYT requires to automatically generate a stage TRANSYT will simply
choose the next available number stage numbers starting with stage 1 (i.e. if stages 1 and 2
already exist TRANSYT will create a stage 3, and then a 4 if necessary, and so on.
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.
You may either run the signal timings exactly as you enter them, or you can enter an initial set
of timings and then optimise them.
To run timings exactly as you enter them (evaluation mode), use the Main Common Data screen
(or use the Data Outline and browse to Network Options>Optimisation Options) and select
Enable Optimisation, and turn off Auto Redistribute.
To optimise timings, select Enable Optimisation, and chose the Optimisation Level you wish to
use. If you turn on Auto Distribute then TRANSYT will also calculate an initial set of timings
which it will then subsequently optimise, instead of simply optimising the current set of timings.
By using Auto Distribute, you can leave all signal timings at arbitrary values, and only need to
specify which phases run in which stages, define a stage sequence and set the controller stream
to reference that sequence.
During optimisation TRANSYT does not attempt to calculate the actual stage order
or which traffic stream and links should run in each stage. However, various tools
are available in the Timings Diagram which allows sequence and stage orders to
be optimised if required, similar to the facilities provided in TRLs isolated junction
design and evaluation tool - OSCADY PRO.
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.
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.)
Phase intergreens and phase delays are an integral part of defining signal timings, as they act as
constraints on the TRANSYT optimiser, as well as on what timings are deemed to be valid or not.
They also affect the behaviour of the Timings Diagram as the manual manipulation of the
timings (phase green periods and stages) will be influenced and restricted by them. They, in
effect, define the transition from one stage to another.
The example diagram below shows timings within the Timings Diagram. It contains no
intergreens or phase delays. You will notice that there is no gap between stage 1 ending and
stage 2 starting. In order to introduce a delay between one phase ending and another starting
you need to either specify an intergreen (using the Intergreen Matrix - which is shown on the
diagram) or specify a phase gaining delay (see section for more on phase delays), to model the
fact that a phase is to start later than would otherwise be the case - Phase B in this example.
In TRANSYT the gap between the stages will either have to contain a phase delay or an
intergreen as shown below.*
or
It is up to the user whether or not they specify a full set of intergreens or just those related to
the phase-to-phase transitions that are active. It is however, often useful to define a full matrix
as it will mean that subsequent changes to stage orders can be achieved with relative ease.
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 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.
Phase C has a phase-losing delay of 5s (shown by the darker shading) If a phase was to
start later than the other phases running in that stage a phase gaining delay would be
needed.
TRANSYT stores phase gaining and losing delays explicitly in the data file. This allows
them to be created, deleted and edited both graphically and directly.
When the file is run, the intergreens and phase delays will maintain the gaps between the
stages, as they act as constraints on what the optimiser can do. In this example all the
optimiser can do is rotate the diagram (i.e. change the offset) or extend the length of one
or more stages at the expense of one or more of the remaining stages.
In the screen shot above phase B is now adjusted to start at 5s later than it needs to, it is shown
with a phase-gaining delay (the dotted line, in the diagram above). This particular gaining delay
is specified as being relative to the end of active intergreen.
If a stage sequence for the controller stream in this example is specified as being double-cycled
(via the Data Outline; Controller Stream>Stage Sequences>Stage Sequence n>Multiple
cycling), the timings could look like this.
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.
Most stage parameters are calculated automatically, but you can adjust the timings of the stage
by dragging the edges or the centre of the blue blocks in the Timings Diagram.
To change the offset, without changing the existing green timings, you can either drag any blank
area that is between any of the stages or anywhere within the blue blocks (N.B. not on top of
the green phases).
To extend or reduce the length of a stage you can drag the edge of a blue block. (N.B. not the
end of a green phase)
Stage Start and Stage End values are filled in automatically as you move the stages
around using the Timings Diagram, but you can also, if you wish, directly edit them in the
normal way (using the Data Editor or Data Grids). You can edit Stage End timings via the
Stage Sequence data, while both stage start and stage ends can be edited via
Resultant Stages > Stage n.
In the Stage Sequence shown, stage 1 ends at 33 seconds and stage 2 at 73 seconds.
The stage start times are defined by the intergreens and phase delays.
For those familiar with using percentage split times (e.g. in Australia) that define what
percentage of the cycle is taken up by each stage, these can be displayed by switching
then on using a File>Preferences>2.Localisation option.
A variety of resultant stage data is presented in the controller stream data under
Resultant Stages. Most of these values are read-only and only presented for reference
as they may be of interest to some users.
Stage Start, Stage End and Stage Minimums can be edited directly. Note that the
editing of percentage split times will alter both the stage duration and the stage end
times, while retaining the existing stage start times.
If you need to re-enter data from, say, a printout of your signal timings this can be done
easily by changing directly the editable data under Resultant Stages - The standard
stage definition Stage Start and Stage End times can be modified. When doing this, it
can be useful to use a data grid and to also have the Timings Diagram open at the same
time so that you can see the changes graphically as you make them.
TRANSYT has calculated that the Stage Minimum for Stage 1 is 10s, in this case
because Phase A has a minimum green of 10s (entered via Controller
Stream>Phases>Phase A). In some cases this calculation is more complex e.g. Stage 1
could be shorter, because phase A could satisfy its minimum green outside Stage 1.
Because of this, TRANSYT allows you can enter your own stage minimum. Note that this
is done via the User Stage Minimum box (Data Outline>Controller Stream n>Stage
Library>Library Stage), even though the value is also displayed in the Resultant Stage
Data as a resultant value. If this is smaller than the calculated value, it will be ignored; if
it is larger than the calculated value, then it will be used in preference. The Stage
Minimum box always shows the value that TRANSYT will actually use.
If a phase runs in consecutive stages, then TRANSYT may be unable to calculate a stage
minimum, and will use a one for this value, in which case you should enter a user value.
If you wish to see resultant Stage Data that uses TRANSYT 12 definitions
you must switch these on (see Data Outline>Network Options/Display
TRANSYT 12 Style Timings). These will appear in the data editor prefixed
with TRANSYT e.g. TRANSYT Stage Start.
TRANSYT has calculated that Stage 1 has a minimum Preceding Interstage of 10s.
This is shown using the diagonal shading (switch on via Appearance>Show minimum
preceding interstages). This represents the smallest preceding interstage that is
allowed, given phase intergreen constraints. If stage 1 started any earlier, then at least
one intergreen constraint would be broken.
You can also use the Controller Streams (Signals) Data screen to conveniently view, edit, add
and delete stages, phases, phase delays and stage sequences at any controller stream:
Phase green period parameters are all calculated automatically from other data such as phase
delays and stage timings, and are only filled in for reference. You may choose to ignore these
values.
The timings of the green periods are adjusted by dragging the edges of the green blocks in the
Timings Diagram. This will have the effect of adding or removing phase gaining and phase
losing delays. It can also indirectly affect the timings of other phases, e.g. by introducing or
extending a phase delay the following stage may have to start later to satisfy the defined
intergreens. This in turn will mean phases running in that stage will also be changed. The
easiest way to see this effect is to try it yourself.
Phase A has only one green period in this example. It runs from 87s - 35s. It cannot run
earlier since it is constrained by the intergreens from Phase B to Phase A, but could start
later if a phase gaining delay was to be added.
In many countries vehicles are permitted to take a nearside turn at a traffic light showing a red
signal, when the way is clear. Although in many cases it will be safest to assume no such
vehicle benefit from such a facility when predicting future performance, in some circumstances
users may still wish to evaluate the performance of a signalled junction by taking account of this
benefit to traffic. TRANSYT has a rudimentary system for modelling such occasions.
Both traffic streams and links can be set up to allow traffic to turn on a red signal, by enabling
the option Allow nearside turn on red (Outline: Traffic Streams > Traffic Stream). This is an
advanced item. Enabling this option allows you to specify a maximum flow rate over the stop
line during red. Red is defined in this case as NOT effective green, so excludes time naturally
used by traffic, say, in the amber time after the end of the actual green signal.
The flow of traffic during red can be observed in a cycle flow profile (CFP) graph.
If, for example you are aware (i.e. have measured or predicted) how many vehicles benefit from
this facility in real life per red period you will need to estimate the max flow required to achieve
this value. Note that the resultant flow rate will also depend on the traffic demand during red
(i.e. what traffic is still queuing or arriving during red).
The resultant traffic flow during red is reported as Flow On Red (PCU per cycle) (Data Outline:
Total Results > Flows and Signals).
At the moment this facility is limited to traffic streams and links that contain only
nearside turning traffic. If the traffic stream or link contains other movements a
task list error message will appear.
The Timings Diagram has two manipulation modes Phase Mode and Stage Mode. Stage
Mode is the default and the recommend mode for most situations. At any time you can switch
modes.
When in Stage Mode stages cannot be created or deleted by dragging it is assuming that you
wish to keep the stage and stage order as it is, and only manipulate the timings in other
respects.
When In Phase Mode the assumption is that you do not care initially about the stages and
stage order and are more concerned about what phases run where and when. This mode offers
the most freedom (and is not dissimilar to the Free Mode button in TRANSYT 13). As you drag
phases about you will see how the stages are redefined based on the phases.
In this mode you can also directly edit the phase green periods (Start Time and End Time) from
either the data editor or from the Resultant Tab of the Signals Data screen (see screen shot).
Furthermore, it illustrates many other important points about the way phases and stages fit
together and is one of two main ways of visualising the signal timings at each controller stream.
It can be used in conjunction with the Intergreen Matrix, Stage Sequence screens and Network
Diagram Timing Wheels (see 15.4).
You can show several Timings Diagrams at once and can lock each screen to show data for a
particular node by using the padlock.
The Timings Diagram not only shows timings for the current (active) stage sequence but also
can be used to view any unused sequences and also, via the Interstage Matrix, all possible stage
transitions.
Different colours are used to represent the stages, to make it easier to identify which of the
three types of timings you are looking at - Stages of the current stage sequence are shown using
blue blocks; stages of unused sequences are shown in yellow; while interstages are shown in
light-brown. Examples are shown below:
Phase/Stage Mode: The operation of the Timings Diagram is governed by two modes of
operation Two buttons at the top right of the screen allow you to toggle between Stage Mode
(the default) and Phase Mode. In Stage Mode stages cannot be created or deleted by
dragging, while in Phase Mode as you drag the phase green periods, new stages are
automatically formed and defined, (based on standard stage definitions). Phase Mode gives
the most freedom (and is not dissimilar to the Free Mode in TRANSYT 13). Phases are moved
simply by dragging the green area of the phase to the left or right. In both modes phase start
and end times can be directly edited.
Repair Timings: An additional button is provided to allow invalid timings to be repaired. This
will re-distribute timings evenly between the stages in order to try to satisfy any phase delays,
intergreens and stage and phase minimums.
The remaining features of the Timings Diagram are described in the following sections.
Appearance>show effective greens: this shows the effective greens as a lighter green above the
actual green. It is on by default. Notice how the blue pedestrian phases effective green is the
same as its actual value.
Appearance>show losing/gaining delays: this shows the phase losing and phase gaining delays:
the losing delays are indicated by the darker green band that will appear after the end of a
stage; the phase gaining delay shows up as a dashed line before the beginning of a stage. This
option is on by default.
Appearance>show minimum preceding interstage: TRANSYT calculates a minimum value for the
preceding interstage in order to prevent stages from overlapping. This minimum can be
displayed as a hatched area between the stages. The minimum preceding interstage will
normally be the same as the actual value. This option is off by default.
Appearance>show stage minima: TRANSYT calculates a minimum value for the stage length.
This minimum can be displayed as a hatched area, starting on the left-hand end of the stage.
This option is off by default.
Appearance>show stage timing hints: this switches on a permanent display of the stage starts,
stage ends and stage durations at the top of the diagram. This option is on by default.
Appearance>show controlled link and traffic streams: this switches to showing one phase for
each traffic stream (or link) (resulting in the same phases being shown multiple times in many
case) rather than the default of showing each phase only once. When showing each phase only
once, the right-hand column indicates the number of traffic streams (or links) the phase is
controlling (as shown in the screen shop below). If blank, it is controlling nothing. When
showing links and traffic streams it shows the controlled items ID.
Appearance>show ALL intergreens: the intergreens that are relevant to a particular stage
change are always shown. This option shows all the other intergreens that have been specified in
the intergreen matrix. Default is off
Appearance>show zero length intergreens: intergreens that are of zero length (i.e. define a
conflict only) are shown optionally when this option is selected. Default is off.
Appearance>show error / warnings list: if screen space is required this list can be hidden. This
option can also be toggled on and off using the blue text at the bottom of the diagram. N.B. the
blue text itself is hidden if there are no errors or warnings
---------------------------------------------------
and
These two options allow the timing data to be used to work out phase conflicts and intergreens.
This facility is also available from the intergreen matrix, where it is fully explained See section
15.5
N.B. the timings diagram will add phase delays automatically as you manipulate phase timings.
You may wish to delete some of them, particularly the phase gaining delays which are only
created because of the lack of intergreens, which you have now added.
---------------------------------------------------
---------------------------------------------------
Tools>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>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.
In Stage mode:
stages cannot be created or deleted by dragging it is assuming that you wish to keep
the stage and stage order as it is, and only manipulate the timings in other respects.
This mode is the default and recommend for most situations, particularly if you are not
already familiar with TRANSYT signal timings. Stages are moved simply by dragging the
blue area of the stage to the left or right using the mouse. While dragging items, other
items will be pushed out of the way, in order that constraints such as intergreens are not
broken.
In Phase Mode:
as you drag the phase green periods, new stages are automatically formed and defined,
(based on standard stage definitions). Phase Mode gives the most freedom (and is not
dissimilar to the Free Mode button in TRANSYT 13. Phases are moved simply by
dragging the green area of the phase to the left or right using the mouse (even if this
breaks intergreens or other constraints).
Far less rules apply when in this mode as constraints imposed by the presence and order
of stages in stage mode, do not apply. This mode is most useful when you wish to
quickly set up which phases run together and let TRANSYT define the stages for you
based on this.
Drag the start/end or middle of a phase over other stages to redefine stages
In either mode:
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 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.
The various options listed above are available so that the user can manipulate the phases,
intergreens, and stage data as they see fit. However, to make life easier when setting up
standard junctions in a standard way, the following guide is suggested. There are two
recommended ways to set up a junction from scratch.
The first uses primarily the Signals Data Screen (as well as the intergreen matrix and
the network diagram): This method is described in a sub-section of part of the manual covering
the use of the Signals Data Screen see section 8.2. This is likely to be your preferred method.
The second uses a mixture of the Signals Data screen, intergreen matrix and the
network diagram as follows:
1. Create your new controller stream, if needed, either in the network diagram or via the
Add a new Controller Stream button on the data outline.
2. In the network diagram associate the traffic streams with the new controller using the
connector tool.
3. Right-click on the Controller Stream and select the option to show the Timings Diagram.
4. From the Tools menu click on Create New Phases and specify the number of phases you
need. Tip: If you are not sure how many you may need it is not a problem you can add
more or remove unused phases easily. Guessing high is marginally easier as unused ones
can be easily ignored or deleted at the end.
5. Select the controller stream in the network diagram. At this point the phases controlling
each traffic stream will be displayed. By default they will all be set to Phase A. Simply
right-click on each traffic stream or link to select the right phase.
6. Open the Intergreen Matrix screen on the vertical toolbar. Fill in the intergreens (first tab
of the intergreen screen) in order to define which phases conflict with each other. You
only need to add the intergreens for the phase transitions you wish to use, but entering
them all is advisable if you are unsure of what your final stage sequence will be.
7. On the Tools Menu select Auto Generate Library Stages to generate a set of valid library
stages, each of which maximise the number of phases that can run in them.
Alternative 1: To manually set up the stages you want, use the Tools item Reset and
Create New Stages to create the number of stages you want. Then right-click on each
stage in the Timings Diagram to select which phases run in which stage.
Alternative 2: You can also use the stage sequence diagram to define which phases run
in which stages by double-clicking on each traffic stream (or link).
Alternative 3: Create the number of stages you want by clicking on Stage Library of
your controller stream, and use the Add a new Library Stage. Then click on each stage
to directly specify which phases run in each stage by entering a comma-separate list of
Phases In Stage.
Note how your stage starts and end times are changed for you, so that the
specified intergreens are resolved automatically as you add each phase to each
stage.
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.
When there are two junctions closely spaced that have internal stop lines, it may be that they
would be controlled by a single controller stream. Below is an example showing just such a
case. Since TRANSYT 14, and the introduction of the controller stream object, this situation is
easily modelled - the green cones illustrate the fact that all signalled arms are controlled by the
one controller stream 1.
To setup one controller stream to control two traffic nodes, select each traffic stream entering
the two traffic nodes and set there Controller Stream to the same controller ID.
Once this has been done, link greens, intergreens, stages etc. can be specified in the normal
way.
There are various options in the Clipboard menu to copy the current set of timings to the
clipboard, from where you can paste it into a spreadsheet etc., and to paste in timings.
In particular, if you have a specific set of link timings and wish to enter them directly into
TRANSYT, then an easy way is to enter them in e.g. Microsoft Excel, and then use the
Clipboard>Paste Link Timings option. TRANSYT will calculate the corresponding stage timings.
For example, the timings above give the below when the clipboard option is used:
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.
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.
Right-click on controller stream and select Show Timing Wheel. Select this option again to
hide it. Timings wheels can be shown for as many controller streams as you like.
Drag the green bend handle located at the top of the wheel away from the wheel to
enlarge the wheel and the opposite way to reduce its size
The timing wheels consist of three concentric circles. The inner circle displays the cycle time of
the controller stream that the wheel is representing. The middle ring shows the signal stages
(coloured blue) and interstages (white). The outside ring is reserved for the signal timings - The
numbers in brackets are the duration of each of the stages (in seconds), and the other are the
start and stage times of each of the stages.
Select the user preference SCATS split times to show stage durations as the percentage of the
cycle, instead of seconds. Please remember that these are based on a stage definition that
includes the following interstage. (See example below.)
Timing wheels are also tolerant of multi-cycled stage sequences (see example below).
Either the stage start time or end time can be changed using the timing wheel. Click anywhere
on the separating line at the end or start of a stage. The line will turn red and a red dot appears
indicating that you have selected that item to edit. You can then use your mouse to drag the
timing for forward or back. The difference between the new value and the original is displayed.
You cannot change the interstage from here, so any change to a stage start will result in the
same change to the preceding stage end, and vice versa.
The stage offset is indicated by a small black dot at the located at the start of stage 1. Select
and drag the dot in either a clockwise or anticlockwise direction to change the signal offset.
In order for any signal timing changes to be reflected in the results you will need
to either carry out an evaluation run manually or switch on the auto-run facility.
The Intergreen Matrix screen shows the matrix for the current signalised controller stream. You
can show more than one at once. Use the padlock to lock it to a particular controller stream.
The Intergreen Matrix screen defines which phases are compatible with each other phase (i.e.
which phase pairs can run together in the same stage.) If two or more phases are compatible
with each other, then there is no conflict between the phases and it is possible for those phases
to run together in the same stage. The matrix is symmetrical, so that if Phase B is compatible
with Phase F, then Phase F must also be compatible with Phase B. Hence, when one phase
conflict is defined, its reciprocal is automatically added with a zero intergreen.
TRANSYT uses the phase intergreen matrix to calculate constraints for stages and phases that
are utilised by the signal optimisers.
15.5.1 Intergreens
Edit the matrix by double clicking in a cell to toggle a conflict on or off, by typing a number in
each cell, or by pressing the Delete key to remove a conflict.
Conflicts between phases are shown with a red background. The remaining cells of the
intergreen matrix will be either white or pale yellow. Pale yellow is used to suggest where
conflicts might be required, i.e. where conflict pairs are currently not running together.
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.
You can generate a set of phase conflicts and intergreen values, based on the current phase
timings (i.e. on what appears to conflict). Access to this facility is gained from either the
Timings Diagram or via the Signal Timings button on the Intergreen Matrix screen. (Intergreen
tab only).
For example if you set up the Timings Diagram to show stage/phase timings as in the screenshot
below and then select Tools>Calculate Phase Intergreens>Conflicts and values, the intergreens
shown further below will be obtained. It is a one-shot option and would need to be selected
again if the intergreen matrix needed re-calculating after a change to the signal timings.
Alternatively you can select the Conflicts only sub-option to populate the matrix with 0s conflicts.
It will be often easier to simply populate the intergreen matrix by hand. This option is also only
of use if the stages you have, represent groups of mutually exclusive phases.
Before:
After:
Alternative - Setting conflicts and intergreens via the Intergreen Matrix screen:
It is laborious job working out conflicts and intergreen values. TRANSYT 15 now offers a facility
to derive both conflicts and initial estimates of intergreen values quickly and easily from the
network diagram. The conflicts are derived from the crossing or merging connector paths within
the network diagram. Both vehicular and pedestrian conflicts are derived. Intergreen values are
also estimated for vehicle-vehicle conflicts based on the distance and probable conflict points.
These calculations are based on the UK Traffic Advisory Leaflet 1/06 Part 4.
1. Clear all then find Conflicts and values: Click this to start afresh This will wipe out
all your existing conflicts and intergreen values.
2. Find missing Conflicts and their values: Click this to get TRANSYT to look for new
conflicts (and associated intergreen values) while retaining all existing conflicts and their
values.
3. Update values (Increase only): Click this to calculate intergreen values for those that
are currently zero, without changing any of your existing conflicts. This button is
intended to allow existing intergreens to be retained while new conflicts, that do not have
intergreens specified, to be calculated.
4. Update Values: Click this to simply update all intergreens (based on the current
geometry) without changing any conflicts.
A Clear All button is also provided to allow you to start with a clean slate.
1. Add a backdrop of the real network to assist you to locate the network
items accurately
2. Scale the diagram so that distances within it are as good as they can be.
This is essential.
4. Adjust connectors if needed such that they represent a realistic path that
vehicles would take to make that movement.
5. Use the capabilities of the files Audit trail to leave notes regarding the
process/changes you have made when deriving your intergreens, e.g. you
could indicate whether or not you used auto-calculated values and also if
you changed them or checked their validity.
15.5.4 Interstages
For anyone wishing to use TRANSYT derived timings either directly or to simply set signal timing
constraints within any stage-based signal control system (e.g. SCOOT), TRANSYT calculates all
interstages.
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.
For countries where amber times can vary from phase to phase, TRANSYT offers the option of
working with amber times and clearance times instead of intergreens. When the Intergreen
Matrix screen Use Clearance and amber Times option is set, phase conflicts are defined by
specifying clearance times between pairs of phases. Edit the matrix by double clicking in a cell
to toggle a conflict on or off, by typing a number in each cell, or by pressing the Delete key to
remove a conflict.
The intergreens used by TRANSYT are derived from the clearance times and (end-of-green)
amber times and are not directly editable while in this mode.
Amber times are specified for each phase via the Data Editor (Outline: Controller Stream n >
Phases > Phase n).
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.
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.
As well as redefining what phases run in which stage, you can use the Stage Sequence Diagram
to change the stage order within a selected sequence. Simply drag and drop any stage in the
sequence to a new location. A red vertical bar indicates the location into which the sequence is
placed (see screenshot).
Furthermore, using a second stage sequence diagram, locked to the stage library, you can drag
new stages from the library into your sequence displayed your other stage sequence diagram.
This makes it very quick and easy to set up the staging arrangement you want. Your starting
sequence can be totally blank.
In the last box, after the last stage in the sequence, a banned stage diagram is shown. The
stage numbers are arranged in a circle and a line drawn between each allowable stage change.
Lines with an arrow indicate that this direction of change IS allowed, but the opposite direction
isnt. If the line is missing altogether, this indicates that this transition is banned in both
directions. Banned stages are specified in the Banned Stage Changes tab of the Intergreen
Matrix screen. The example shown below indicates that a change from stage 1 to 8 is banned,
and also from stage 8 to 7.
Banned stage changes are also indicated if they exist in any stage sequence, and will be an error
if they appear in the current stage sequence.
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.
Intergreen A to B = 6 seconds
Phase A
Relative phase
gaining delay = 2 s
2 seconds
Absolute phase
gaining delay = 8 s
Phase losing
delay = 3 s
Stage 1 to 2 = 10 seconds
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.
By default, each controller stream references the TRANSYT network-wide cycle time which is
always specified, by having the controller streams Cycle Time Source set to NetworkDefault
(see Figure 15-1). This can be changed to either Manual, so that you can specify a different
cycle time, or alternatively it can be set to Controller Stream, in which case you need to
reference the ID of another controller, from which it gets its cycle time. In this way you can set
up a group of controllers to use the same cycle time as another controller, i.e. sub-networks can
be defined.
In all cases the flow volumes are transferred along the traffic streams (and links) from one
controllers control to the next one, however, due to the cyclical nature of TRANSYT the flow
profiles are only transferred if they are running on the same cycle, i.e. the flow profiles are in
effect flattened when the cycle times do not match. This is required since coordination between
uncoordinated controllers will simply not exist and hence any benefits from such coordination
would naturally be lost.
With the introduction of multiple cycle times in TRANSYT 15 the data outline has also been
enhanced so that it displays any cycle times that are set to anything other than the default (see
below). The centre of network diagram Timing Wheels also display each controller streams
cycle time.
Different cycle times and multi-cycling options for each sub-network can also be investigated
using TRANSYTs enhanced Cycle Time Optimiser (CYOP). See section 26.11.
Traffic streams and links have an option called Auto Cycle Time which, by default, is always
set. This option ensures that the cycle time associated with all traffic streams and links, whether
signalised or not, will associate themselves with the right cycle time. When set, the cycle time
of signalled traffic streams will use the cycle time of the controller associated with the phase
controlling that traffic stream. For unsignalled items it will base the cycle time on of the most
appropriate one it can identify. The option to switch off this automatic selection is only provided
for the rare occasion in which the selection is not what is required. Generally, this setting can be
ignored.
Flares can be modelled using two different techniques. One way is to use a traffic model that can
model the blocking back effects associated with a flare. The second method is one which has been
traditionally used in TRANSYT, but which has limited capabilities This involves the explicit
creation of Quick flares to model flared approaches. These two methods are introduced in the
following two sections.
sat.
flow
0 green time
To model a short flare you simply add the appropriate traffic stream (or link) type and set its
traffic model to Flare. The maximum queue storage value then determines the amount of traffic
that can store in the flare (short lane).
Setting traffic streams and links to use a flare model is a more natural way of
defining flared approaches. For complex situations it is easier to set up and also
models more accurately, due to the inherent ability of the flare model to take
account of blocking effects and platooning effects.
The congested platoon dispersion model (CPDM) is used automatically for shorter flares (less
than 30 metres) due to the fact that it models random effects in addition to its inherent ability to
model platoon dispersion. For longer links the superior full horizontal spatial awareness of the
CTM model will make it a more appropriate model to use despite it not modelling platoon
dispersion. When blocking back effects need to be modelled these will also be the very
situations where modelling of dispersion will be less important.
The automatic selection of blocking model ensures that the model choice is both
consistent (between users of the program) and that the most appropriate model is
always used. The traffic stream (or link) structure is the same no matter which
model is used.
In the simplest case, whichever flare model is chosen will provide additional capacity which will
have an equivalent effect to that of a quick flare - see the stepped form of the non-linear
saturation flow in Figure 16-2 which contrasts with the constant, single valued, saturation flow for
non-flared links.
The Flare models are more flexible, as they handle situations that the older quick flare model
couldnt, e.g. the flared area does not have to be controlled by the same signal phases as the
adjacent full lane, for example.
To model a short flare you simply build a Link or traffic stream structure in same way you would
build the rest of the network, i.e. explicitly provide the additional space provided by the flared area
by adding links and lanes to take the extra traffic, and connect the lanes or links together in the
usual way.
The simplest example (Figure 16-2) is a single lane flaring out to two lanes at a signalled stop line.
The signals presented to both lanes are identical in this example, but dont have to be. It also
does not matter whether or not a traffic queue is likely to block back at any time to the one lane
part of the carriageway any blocking will be taken account of if it exists. Starvation of any of the
stop line lanes due to blocking upstream will also be taken account of. Figure 16-3 shows the
required traffic stream structure in TRANSYT as well as illustrating the use of the queue overlay
(which can be animated over time).
main lane
flare
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
the network diagram.
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.
3. The Saturation flows of the two stop line lanes are specified in the usual way.
4. Traffic Stream Model Type: Traffic Streams 2/1 (Main Lane) and 2/2 (Flare) have their
traffic model set as Flare so that they will block. Traffic Stream 1/1 is left as the
network default (in this case the network default is PDM) Essentially, you are defining
which items have the capability to block upstream traffic.
5. Maximum Queue Storage: TRANSYT, by default will automatically calculate internally the
amount of traffic that can store on any traffic stream (or link) using the length and
saturation flow. This is not necessarily accurate enough for modelling flares, since it is only
a rough estimate and can often be an overestimate of the maximum storage space that
traffic are prepared to use or can use in practice. Because of this, we recommend that any
traffic stream or link using the Flare model, should also have a user-defined maximum
queue storage value specified (Outline: Traffic Stream n>Modelling).
6. Feeding traffic stream: The feeding traffic stream has a (restricted flow) saturation flow
representative of a single lane. This is needed to ensure that the downstream traffic
streams are fed at the correct rate of flow when the feeding traffic stream queue (if it
exists) discharges into them.
If you wish to position the two lanes at the stop line, such that they are separate or not parallel to
each other, you can simply model them as two single traffic streams within separate Arms - The
model results will be the same.
Flare traffic streams (or link) should be constructed such that their
components (short lanes and feeding link/traffic stream) do not straddle
two OD matrices. If this is done the flare will not be recognised as
such, and the random blocking effects will not be taken account of.
Figure 16-4 shows the profile of traffic crossing the stop line made up of traffic from both lanes.
The diagram illustrates the benefit of the flare the extra capacity while the flare empties of
traffic and then a return to the flow rate associated with just one lane while the queue continues
to discharge. The shape of the graph is of a non-linear step form in contrast with the constant,
single valued, saturation flow for non-flared approaches and illustrative of the saturation flow
that is achieved for this situation. It is similar to what would have been achieved using the
quick flare model.
Because the flared area and the traffic using are explicitly modelled in TRANSYT, the go profiles of
the combined flared area automatically takes account of the extra capacity provided by the short
lanes, and this is done with respect to time, thus preserving platoon profiles for downstream links.
There are also other significant benefits of using the Flare models for modelling flares:
The different traffic streams that represent the flared approach do not have to be controlled
by the same signals.
Any platooning effects that reduce the potential benefit of the presence of the flare are
automatically taking account of. E.g. if all traffic arriving within a discrete platoon arrived
at the flared area and turned left using just the left-most lane, followed by a platoon that
all turned right using only the right-most lane, then the presence of the flared area could
be negligible.
Flares can be applied to give-ways and restricted flow (bottleneck) links and traffic
streams.
The model automatically works out the likely utilisation of each short lane, so that it takes
account of whether or not traffic can choose between the different lanes or not. This
makes the new model a more universal solution than with the quick TRANSYT flare
model, which allows one network structure to represent all flow situations.
It should also be remembered that the presence of flares giving extra discharge capacity for just
the initial part of the green may well mean that the signals will operate more efficiently on a short
cycle time. In this way, more frequent use of the flare capacity will be obtained, compared with
longer cycles.
Modelling of a flare using individual components as described when using the Flare model type
naturally means a full set of results for each individual component is provided. However, it may
be more natural and more desirable to evaluate a flare as a complete unit. In order that this can
be done additional results are provided.
This is best described by way of another example. The example here is a two lane approach
flaring to two, with two lanes catering for a straight ahead movement and a single lane for both
straight ahead and right.
For the feeding (upstream) traffic stream (traffic stream 2Cf/1 in the example) additional Flare
data is provided under the Total Results section of the traffic stream. This is accessed from
the Data Outline as shown in the screen shot.
The values shown represent those associated with the combined effect of the referenced Flare
Components. Degree of Saturation (and associated PRC value) is defined in such a way that it
closely matches the results that would have been reported when a Quick flare had been used to
model the situation. This value represents a capacity specific to the particular utilisation of the
flared area as a consequence of the traffic model predictions.
TRANSYT models the extra capacity available from flared approaches giving extra lanes at the stop
line, as in Figure 16-7 by defining one or more quick flares on a link.
main lane
flare
The non-linear saturation flow is of the stepped form shown in Figure 16-8. It contrasts with the
constant, single valued, saturation flow for non-flared links or traffic streams.
sat.
flow
0 green time
TRANSYT quick flares are defined on either traffic streams or on links. Quick flares can be used
with both CTM and PDM models. They should not be used on traffic streams or links that use the
Flare traffic model.
Because the new Flare Model technique offers advantages over the previous
quick flare model, we generally recommended the use of the new methods over
the use of quick flares. However, there is no reason not to continue using them for
simple flare situations. TRANSYT 14 will import existing flares, but will not attempt
to convert them.
Flares modelled in TRANSYT 13 using the CTM model will not be converted to using
the automatic chosen Flare Model. You can re-specify to use the flare model if
you wish.
A summary of how quick flares work and how they are specified is retained in this section to allow
them to be understood by anyone who comes across them, and is not intended to give full details
of their use Full details are available In AG63 TRANSYT 13 User Guide. (Binning et al, 2008).
The normal saturation flow specified for a traffic stream or link (Outline: Traffic Streams > Traffic
Stream n or Links > Link n) represents the value for the main lane alone. In addition, the user is
required to specify, in Quick Flare Data (Outline: Traffic Streams > Traffic Stream n > Quick Flares
> Quick Flare n);
1. the saturation flow for the extra lane(s) provided by the flare,
2. the average number of vehicles which are able to use the flare during each green,
estimated or measured (Effective storage)
This value can be entered manually as the Effective Storage or the flare capacity routine Que
Prob can provide a quick method for estimating the likely capacity gain for the situation where a
single approach lane (a main lane) widens out to give an extra lane (a flare lane) at the stop
line.
The QueProb routine assumes that the traffic in the two lanes goes to different
destinations, i.e. an individual vehicle does not have a choice of lane. Therefore,
QUEPROB is not an appropriate tool to use when the traffic from the two lanes
have the same destination.
The program derives its estimates from binomial probability theory, calculating the various cases
where either the main lane or the flare lane fills up first and cuts off access to the other lane,
causing a less-than-maximum usage of one of the lane queueing areas.
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.
Enter the percentage of traffic which uses just the main lane.
QUEPROB then works out the likely utilisation of the short (flare) lane giving you this in the form
of Extra capacity due to flare.
The GO profile is modified to take account of the extra capacity provided by the short lanes, and
this is done with respect to time, thus preserving platoon profiles for downstream links. It should
also be remembered that the presence of flares giving extra discharge capacity for just the initial
part of the green may well mean that the signals will operate more efficiently on a short cycle
time.
Examples of using the flare model in various cases are given in the following sections.
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.
For examples, where use of the flare lane and the main lane will probably be unequal, the method
of modelling may well be dependent on the cycle time being used, and whether a link has double-
green or not. This is because the likelihood of queues blocking back to the narrower part of the
approach increases with longer red times for a flared link.
Queues interact, and flare caters for separate movement from main lane:
If the flare lane caters for (say) a left-turn movement while the main lane caters for straight-
ahead traffic, then not all the physical extra capacity will be usable on average because (a) for
some cycles, the flare or the main lane may fill-up before the other, blocking access to the extra
road space provided.
The extent to which these queues interact will depend on the percentage of traffic using each of
the lanes. To model this, it is necessary to specify the average number of vehicles able to use the
flare each green (Effective Storage Value). The user can be assisted in specifying this value by
use of QueProb. Again, the assumption is that the flare green is the same as that of the main-line
green If not use the Flare traffic model instead.
In this situation the modelling is difficult and the flare model will not have been used. Other
modelling techniques will have been employed. Care should be taken when interpreting these.
The new flare modelling options available in TRANSYT make the modelling of such complex
situations a lot easier and simpler to model.
Additionally, for those wishing to understand fully what TRANSYT is doing on your behalf, in
terms of the traffic model, you may be interested in reading section 25.5.
In TRANSYT, you have a choice between using a lane or a link structure to represent your real-
life network. You will generally find that the lane structure is a more intuitive way of setting up
your priority intersection as it will usually result in a one-to-one relationship between real lanes
and TRANSYT network lanes. The Priority Tool allows junction geometries (as used in ARCADY
and PICADY) to be specified, in order to work out the required give-way coefficients. These
coefficients can be assigned automatically to the TRANSYT lane or link structure.
The first couple of sections of this chapter start off describing the easiest way to add a priority
junction to a TRANSYT network by adding a library file which contains a Priority Object.
Rather than construct junctions from scratch, users can choose to start off a new
network with a library file or merge one into their existing network. A small
library of files is supplied with TRANSYT, which can be supplemented by files users
wish to store as additional library files. A number of priority object files of various
configurations are supplied. This feature is fully explained in section 7.2.
The remaining sections describe how to use a number of other methods which may be required
when needing to model specific situations for which there is no library file supplied and for those
situations not covered by the priority objects.
Figure 17-1 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.
Priority objects exist for roundabouts (all types), T-junctions and crossroads. Staggered
crossroads can be accommodated using two T-junction priority objects.
The models, now built into TRANSYT, that make this possible are those also used in our sister
products ARCADY and PICADY, which are used to model roundabouts and priority junctions
respectively. One of the main benefits of this new feature is that the performance of priority
junctions will take account of the effects of other closely-spaced junctions (signalled and
unsignalled) as well as take account of the effects of the cyclic flow patterns generated by the
presence of traffic signals within any modelled network.
To add or edit either a T-Junction or crossroads priority object within TRANSYT you
must have a registered version of PICADY on your computer. Similarly for the
Roundabout objects, you need a registered version of ARCADY on your computer.
Priority Object will not be editable. Priority Objects can always be deleted from a
file.
Both ARCADY and PICADY can be registered from within TRANSYT using the main
menu option Help > Manage Licences.
2. Click on the Insert Library File button on the network diagrams vertical toolbar and then
click on the network diagram where you wish the new file contents to be deposited. This
will bring up a list of available Library Files.
3. From the list, select one of the files indicated as containing a T-junction Priority object,
and click OPEN.
4. Select the default prefixes or re-enter your own arm IDs and traffic stream IDs must be
unique within the network, and click MERGE. The contents of the file will be deposited at
the chosen location.
5. Connect the external traffic streams to the rest of the network (if required).
N.B. if you look at the traffic stream data you will see that all of the required movements
and conflicts have been created automatically for you. There is no need to change these,
unless you wish to model a different layout of traffic streams.
6. Specify the junction geometric data for the Major Road and Minor Road See Figure
17-3 (Outline: Priority > T-junctions > T-Junction n). This automatically generates the
Slope and Intercept data that is used by TRANSYT to calculate the final give-way
coefficients.
7. Double-click on the OD Matrix in the network diagram and add your OD flows. The flows
entered will be assigned automatically to the traffic streams. Use a Local OD Matrix to
control how the flows are assigned to the network. Details on how to use a Local OD
Matrix is in section 13.4
8. Check the Task List for errors and if error-free simply run the file.
9. If you want results for the whole junction, rather than each individual traffic stream, add
a collection based on the relevant traffic node, in order that results appear in the
TRANSYT report.
Once a library file is loaded into TRANSYT it can be manipulated like any other file.
Saving the file will save it as an ordinary TRANSYT .T15 file, but can also be
saved as a new library file if you wish.
Once you have added a new Priority object (using the network diagram or Using the Data
Outline) you can specify the objects data. One of its properties is Auto Assign Priority.
When this is set it will assign the calculated give-way coefficients to the relevant traffic
movements. In order to do this, TRANSYT traffic streams or links need to be matched up with
their corresponding movements within the Priority Object model.
If the junction is build using links it will be links that will need to be referenced and if the
junction is build using traffic streams it will be traffic streams that will need to be referenced.
Setting the Type to TrafficStream allows traffic streams to be referenced instead of links
(see Figure 17-5).
In either case, TRANSYT references the various movements (e.g. Entry AB traffic
steam) by copying the approach naming convention copied from ARCADY and
PICADY The names of each of the approaches to the junction are as shown in
Figure 17-4 and Figure 17-6. For a UK give-way the Priority Model refers to the
major right as Arm A, minor arm as Arm B and the major left as Arm C.
If the referenced traffic streams (or links) do not match this convention TRANSYT
will give you incorrect results.
Traffic streams need to be matched up with the Entries and Exits on each arm of the
junction. Therefore, for the traffic stream network for the simple T-Junction (Figure 17-2),
Entry AB Traffic Stream will need to reference traffic stream A1/1. In this example the traffic
streams themselves have been conveniently named using the PICADY naming convention to
make it easier to match up the items, but of course, there is no need to do this, and in many
cases you will not want to rename existing traffic streams in your network. This example also
illustrates the need to reference the same traffic stream more than once if it carries traffic
making more than one movement, as in this case.
Links need to be matched up with traffic movements at the junction. Therefore, in the example
shown in Figure 17-5, Link 24 is defined as the link carrying traffic from Arm A to Arm B i.e.
associated with Entry AB.
Where one way entries or exits exist please refer to section 17.3.1.
Another important property that can be set is Calculate Slope and Intercept. When set this
TRANSYT automatically calculates a complete series of required slope and intercept values based
on the geometric data. When this option is not set the various slopes and intercepts can be
specified directly (if you have them) without the need for the geometric data. For an
explanation of what the slope and intercept coefficients are, please see section 25.5 or read the
relevant sections of an ARCADY or PICADY User Guide.
By default the Traffic Direction on each arm is set to Two-Way. If traffic is restricted
from entering or leaving a junction, i.e. either one-way in or one-way out of the junction, the
Traffic Direction should be set appropriately as either Entry only or Exit Only.
The Priority Object needs to know this information, otherwise, it will demand the ID for traffic
stream(s) or Link(s) that do not exist and will try to set up unnecessary conflicting movements
of traffic (see Figure 17-7 and Figure 17-8).
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.
The priority object also tolerates banned movements so if for example a right-turn movement
from the minor arm is banned, the priority object will automatically take this into account by
only setting up the conflicts and calculating the slopes and intercept needed for the TRANSYT
network that has been set up, i.e. it will spot when certain connectors are missing and take
account of them (see Figure 17-9).
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.
When using a lane structure to model a T-junction you must use a Local OD Matrix to specify
your traffic flows in and out of the priority junction. A link structure can be used instead and is
described in 17.8 (Using Links to define your priority junction).
Figure 17-10 Network structure using arms, traffic streams and lanes
or Description data are not mentioned. Other items not mentioned are not required, so should
be left as their defaults. It is assumed that as you add the items to the network diagram, you
will re-position them appropriately.
1. Using the network diagram, add a traffic node and then the required number arms
(three), traffic streams (one per arm), each of which has one lane. An arm has one
traffic stream by default and a traffic stream has one lane by default, so for the example
the defaults are OK - no new streams or lanes are needed. You should ensure that you
have a full set of exit arms as these are a requirement of using a Local OD Matrix. For
our example you will need six arms in total.
2. In the network diagram, connect the various traffic streams to each other to define what
traffic goes where. Note that this does not define any give-way movements or conflicts
only where the traffic goes.
3. Enter the Traffic Stream Data using either the Data Editor or the Streams Data screen.
The Saturation Flow Source is defaulted to SumOfLanes. If the traffic stream has
only one lane (as for this example) the Saturation Flow Source can be left as the default.
This automatically assigns the sum of the individual lane saturation flows to the traffic
stream saturation flow. However, there is the option DirectlyEntered if you wish to set
the traffic streams saturation flow directly. Pure give-ways do not use the Saturation
Flow value, but give-ways with a restricted flow (give-way bottlenecks) do need it.
4. Define what type each traffic stream is: You will need to set the minor road traffic stream
as a give-way (pink in the network diagram) and the same for Arm C2 (Outline: Arm
B2>Traffic streams>Traffic Stream 1). The Is Signal controlled option should be de-
selected as the arm is not signalled. The exiting arms A2x and C2x will be whatever type
is required by the rest of the network, or if all the traffic on it is exiting the network it
should be set as an unrestricted traffic stream (sandy-coloured in the network diagram).
The signal data such as Controller Stream will be disabled, as the junction is not
signal controlled.
5. Enter lane data using either the Data Editor or the Lanes Data screen. The only
information you need here is the Saturation Flow. This can be measured and entered
directly, or the RR67 option used to derive it from various geometric parameters. Full
details on using the RR67 option are described in section 3.5.5.
For Arm A2 the traffic stream option Has Restricted Flow should be disabled, or the
saturation flow set to a very high value to ensure that no queueing will occur on these
lanes. (Often the value 9999 is used, as it an established and recognisable value used for
this particular situation.) Arm B2 give-way will not use the saturation flow value so can
be left as the default. Arm C2 does not use the saturation flow value either but a give-
way max flow for the straight ahead movement (Movement A2x/1) is required, and is set
automatically to 1800 This ensures that results match PICADYs as closely as possible.
6. Add an OD Matrix using the network diagram: Add the number of locations required (one
is provided automatically). Three are required for the example as there are three entries
with corresponding exits. Use the connector tool to connect each of the exiting traffic
streams to the relevant location and connect each of the locations to the relevant entry
traffic streams, remembering to follow the order as described. N.B. The direction you
connect the locations defines what is an entry or exiting traffic stream.
7. Either add a T-junction Priority Object or add your Give Way Data manually. See
section 17.6 on how to add a Priority Object. Since using Priority Objects avoids the need
to set up much of the data required, it is recommend that you use one, as long as the
priority object satisfies your modelling requirements.
By default, a give-way will have its property Opposed Traffic set to AllTraffic
(Outline: Traffic Stream n>Give Way Data). This means that all traffic on in this traffic
stream is opposed by some other movement(s) irrespective of where it is going.
In the T-junction example not all of the main road traffic arriving from the left (Traffic
Stream C2/1) is opposed, as some is travelling straight ahead. Setting the Opposed
Traffic to Movement allows individual movements to be added, so that the different
characteristics of each movement can be defined separately as required for this example
situation. See Figure 17-20. When opposed traffic is by Movement ALL movements
must be set up, even for movements that have no conflict. Those movements that have
no conflicts should have their Percentage Opposed value set to zero.
This is the only option that needs to be set for this example as the step-wise opposed
turn model is only applicable to signalled give-ways and the Visibility Restricted option
is not required for this example see 17.7 for an explanation of what this option does.
8. Specify your movements and conflicts (or add a T-junction Priority Object). See section
17.6 on how to set up movements and conflicts. See section 17.6 on how to add a
Priority Object. Since using Priority Objects avoids the need to set up movements and
conflicts manually, it is highly recommend that you use one, as long as the object
satisfies your modelling requirements.
9. Check the Task List for errors and if error-free, run the file.
10. If you want results for the whole junction, rather than each individual traffic stream, add
a collection based on the relevant traffic node, in order that results you require are
available.
Destination Traffic Stream: The movement itself defines the origin of the
movement and this defines the destination of the traffic.
Max Flow (Opposed): This the maximum flow that can be achieved when traffic is
giving way to one or more opposing traffic streams, but when that opposing flow is zero.
N.B. this IS not the same as not giving way at all. It also sometimes referred to as the
Intercept, as it is in ARCADY and PICADY. When give-way traffic behaves as if it is
unopposed then this situation can be modelled see section 17.16 to find out how.
Percentage Opposed: In this example the value is 100% as all the traffic making this
movement is yielding to the opposing traffic.
For the T-junction example, Lane C2/1 needs two movements specified to traffic stream B2x/1
and to A2x/1 (see Figure 17-14). These are necessary as the straight ahead movement
requires having a higher maxflow compared to that of the turning traffic. This is to reflect the
fact that it is not opposed by any traffic A value of 1800 is set automatically to match the
results of PICADY. In this example the opposed movement has a max flow of 752 (N.B. this is
an example value only Not a default).
B2/1 requires movements to C2/1 and A2x/1 as again the give-way properties for each
movement are different, e.g. different conflicts and give-way coefficients.
However, A2/1 does not require ANY movements defined as both traffic movements (to B2x/1
and C2x/1) are modelled as having the same experience, i.e. nether give way to any other
movements. (In some countries this would not be the case, in which case separate movements
should be defined.) They CAN be specified for consistency and will not affect the model, but are
not required in this example.
The definition of the various movements allows each of them to be set up with associated
conflicts, i.e. a particular movement will conflict with one or more other movements. The screen
shots shown below show you how these will look in the Traffic Stream Screen.
The data needed to define a conflict is as follows: For a given movement, first you need to
specify the Controlling type. Since we are using arm/traffic stream/lane structures
throughout this example, the Controlling Type required will either be TrafficStreamMovement
or TrafficStream. If Traffic Stream was chosen you would need to specify the conflicting
traffic stream and this would mean all the traffic on that named traffic stream would conflict with
the current movement. In this example we wish to specify a full model and means that we need
to specify that the different movements conflict in different ways even when all the traffic
conflicts. We therefore chose TrafficStreamMovement (see Figure 17-16, Figure 17-17 and
Figure 17-18 and Figure 17-19). This necessitates specifying where the conflicting movements
come from and goes to, by entering the Controlling From Traffic Stream and Controlling
To Traffic Stream values.
Percentage Opposing: You also need to indicate what percentage of this movement is
actually conflicting Often this will be 100% when using TrafficStreamMovement as is the case
here. TRANSYT allows users to specify this data to ensure TRANSYT remains generic in nature
and therefore flexible enough to model all situations you may encounter both in the UK and
elsewhere in the world.
The next required value is the Slope Coefficient (i.e. same as PICADY slope). This value
determines the rate at which the give-way capacity diminishes as the opposing traffic increases.
See section 25.5 if you wish to know more.
The Upstream Signals Visible defines how give-way traffic reacts to upstream signals See
17.16 for fully details.
Give-way conflicts do NOT have to involve traffic crossing each others paths.
Certain movements can still influence the behaviour of traffic on non-crossing
movements This is the case at T-junctions where the major road traffic takes a
nearside turn into the minor road (A2 to B2x in the example) affects the capacity
of the minor arm B2.
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.
Figure 17-13 show the standard links and link-shares needed to model a basic T-junction. The
yellow pentagons shown are two of the OD Matrix locations.
When using a link structure to model a T-junction you do not need to use an OD Matrix to
specify your traffic flows in and out of the priority junction, but it is worth considering as it
makes it easier to make changes to your flows and is less error prone. Details on how to use OD
Matrices is in section 13.4. It is also worth considering using the T-junction Priority Object, as in
this way you can store all your junction data within the one software package.
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:
Same as Major Link: This option allows the give-way data of the minor arm to
simply match that of the major arm This is the default. On links 26 and 28 in the T-
junction example, we do not want to do this, as the model required the properties of the
two links to be different (e.g. different conflicts), hence this option has been deselected.
Percentage Opposed: Used to define how much of the traffic on this link is yielding
to the opposing traffic. In the T-junction example, 100% of the traffic on each of the
give-way links has to give way.
The T-junction example could have been modelled with a single link instead
of links 27 and 28. In which case, the straight ahead traffic (75%) on the
combined link would not be giving way, so the Percentage Opposed would
be 25% instead of 100%. However, this simplifying of the model prevents
two separate max flows to be defined and as a result would not produce
quite the same results.
Max Flow (Opposed): This the maximum flow that can be achieved when traffic is
giving way to one or more opposing traffic streams, but when that opposing flow is zero.
N.B. this IS not the same as not giving way at all. When give-way traffic behaves as if it
is unopposed then this situation can be modelled see section 17.16 to find out how.
Max Congested Capacity: See Modelling give-way links in CTM. This item is only
relevant to the CTM model, so is a hidden item in this example.
Use Step-wise Opposed Turn Model: This item is only relevant to opposed turns at
signalled junctions.
Visibility Restricted: See section 17.7 for an explanation of what this option does.
The main difference between crossroads and T-junctions is the number of conflicts that need to
be set up (in order to offer results comparable with PICADY) Crossroads naturally have far
more movements of traffic through them, and hence require far more conflicts. We
recommend, therefore that you do not attempt to set these up manually, and instead always use
the Priority Object to do this for you.
Roundabouts and priority T-junctions gives you the option of adjusting or specify your own slope
and intercept values instead of using those calculated by the priority object. However due to the
impracticality of allowing this facility for crossroads, these values are not reported nor editable
from within the priority crossroad object itself and are only reported on the conflict data of each
traffic stream (or links). These values may appear to be editable but are in fact read-only. See
Figure 17-21 for an example.
The Visibility Restricted option is not required for crossroads so can be ignored, and the
Use Step-wise Opposed Turn Model only applies to signalled give-ways, so can also be
ignored.
The easiest way to model an unsignalled roundabout is to simply load one of the supplied library
files. The library files use the new Roundabout Priority Object (see section 17.1) to allow the
roundabout geometries to be specified and the resultant give-way coefficients attributed to the
relevant traffic streams on the roundabout.
An example conventional four arm roundabout is used to illustrate how to build your model or to
adapt an existing library one. (See Figure 17-23) The model requires four Entries to be added
to the Roundabout Priority Object one for each approach. Exit-only arms do not require an
Entry. TRANSYT 15 needs only a minimum of ONE entry per roundabout object - unlike
TRANSYT 14 which required a minimum of two.
The steps described in section 17.5 are essentially the same, as each roundabout approach is
treated as a simple T-junction with one-way flow on the major arm. Traffic exiting the
roundabout is represented by either a set of traffic streams (or links) with unrestricted flow if the
exiting traffic is also leaving the network, or whatever traffic streams (or links) type is required
for modelling of the downstream situation within the network.
For the equivalent of step 7 (from section 17.5) - Add your Give Way Data:
Under General give-way Data, a give-way link will have its property Opposed Traffic set
(by default) to AllTraffic (Outline: Traffic Stream n>Give Way Data). This means that all traffic
in this traffic stream is opposed by some other movement(s) irrespective of where it is going.
This is the case here, so there no need to change it. If you are using the roundabout object this
value (along with some other data) will always revert to the correct value even if you do try to
change it!
The Visibility Restricted option is not required for roundabouts so can be ignored, and the
Use Step-wise Opposed Turn Model only applies to signalled give-ways, so can also be
ignored.
Under Conflicts > All Movements the Max Flow (Opposed) is simply the ARCADY
Intercept and can either be entered directly or calculated for you if the Roundabout Priority
Tool is used to assign the intercept to this give-way traffic stream (or link). The Percentage
Opposed can be left at the default of 100% as all traffic will be giving way to the circulating
traffic.
For each approach you are required to specify how many Conflicts you need each conflict
being a single traffic stream (Controlling Type = Traffic stream). The specified conflicts
should represent all the traffic passing the entry. These conflicts will be automatically set up for
you if you use the Roundabout Priority Object.
The ability to specify multiple circulating traffic streams within the Roundabout
Priority Object is new to TRANSYT 15.
Figure 17-24 shows how Arm 3 in this example has Traffic Stream 8/1 as its conflicting traffic.
The conflict should be associated with All Movements of the entering traffic stream, as there
is only one movement onto the circulating carriageway.
The Percentage Opposing should be set to 100% (default) to model the fact that the
entering traffic has to give way to all of the circulating traffic. It is automatically set to 100%
when using the roundabout object.
As was the case with Max Flow, the Slope Coefficient (the ARCADY slope) can either be
entered directly or calculated for you if the Roundabout Priority Object is used to assign the
slope to this give-way traffic stream (or link).
The definitions of the give-way geometric data is the same as for ARCADY. Full
details of these are given in the ARCADY User Guide, so are not repeated here.
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.
The geometric data associated with each entry to a standard roundabout is shown in Figure
17-26. The data required depends on the roundabout type chosen. The data is the same as that
used by ARCADY. Definitions of these can be found in the ARCADY User Guide.
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.
Having added the data described above you should now be able to run TRANSYT. Your
roundabout can either be totally isolated or connected to other junctions as part of a network.
Often storing several variations of the same file in the same file can be useful, e.g. a fully
unsignalled one and, say, a partially or fully signalled one. As TRANSYT 15 now tolerates
different cycle times within a file, storing multiple signalled roundabouts with different cycle
times in the one file is not a problem and can also be an elegant way to store sets of alternative
designs.
Figure 17-27 shows the standard links and link-shares needed to model the same four-arm
roundabout. Examination of the library files is a useful way to understand the structure needed.
When using a link structure to model a roundabout you do not need to use any OD Matrices to
specify your traffic flows in and out of the priority junction, but they are worth considering as
they makes it easier to make changes to your flows and is a less error prone method. Details on
how to use OD Matrices is in section 13.4. It is also worth considering using the Roundabout
Priority Object, as this way you can store all your junction data within the one software package.
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 28 modelling signalled roundabouts in order to
ensure you fully understand the link structures required.
Please also note that the step-wise opposed turn model cannot be used for mutual
opposition situations.
17.13.1 T-junction with Two lanes on the minor road and no blocking of
straight ahead traffic by right-turners
Figure 17-28 T-junction with two lanes on minor road (using links)
To represent two separate lanes on the minor road one carrying left-turning traffic and the
other right-turning traffic - the two links representing the minor road are not shared.
To represent the fact that traffic on the main carriageway is not blocked by traffic making an
offside opposed turn into the minor road, the link carrying the straight-ahead traffic is not
shared with that carrying the opposed turn traffic. It is also defined as a link with an
unrestricted flow as no queueing is expected on this section of road.
The links representing the main carriageway in the other direction as similarly set with
unrestricted flows. They can be shared or not-shared it will make no difference in this
situation.
All Percentage Opposing values should be set to 100%, since shared links have been used to separate out the
different movements.
The give-way conflicts needed (for the example shown) will be as follows:
LINK 25 (B-A, right-turn from minor): Opposed by LINK 23, 24, 27 and 28
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.
The only difference with the two-lane example is that the minor arm uses two shared links.
Figure 17-29 T-junction with one lane on minor road (using links)
17.13.3 T-junction with a turning bay on the main carriageway
The effect of the presence of a turning bay on the give-way coefficients is taken account of
through the geometry value for the major road Width of C-B traffic, when using the T-Junction
Priority Object, or by external calculation of the give-way coefficients.
The effect of the turning traffic blocking or not blocking traffic travelling straight ahead is
modelled using either shared or non-shared links, or one or two traffic streams.
However, between full blocking and no blocking (as it is known in PICADY) traffic may block
after filling up the turning bay For technical reasons it has not been possible to re-use the
PICADY partial-blocking model inside TRANSYT, but another technique can be used instead
which should give similar results:
The Congested PDM model (CPDM) can be used to model the blocking effect.
The diagrams below show an example of partial blocking in operation. In the first diagram link
28 is about to block The red line indicates the queue and the cyan cells show the flow rates
In the second diagram the queue has reached the end of the link and a queue is now forming on
upstream Link 30. Link 27 is now also being starved of traffic now that it is blocked.
The model also takes into account the random effects on the likelihood of blocking.
A lane equivalent of this model can also be set up in a similar way. (See supplied Library File.)
In New Zealand traffic turning left into a minor road gives way to traffic turning right from the
main carriageway, as shown in Figure 17-32. This is easy to set up in TRANSYT, but may
require calibration and/or validation in order to obtain suitable give-way parameters. The give-
way values suggested here are simply starting values which should be adjusted in light of local
data.
The right turn lane can be set as simply a restricted traffic stream (or link), while the opposite
main road approach is modelled as a give-way. The left turn movement into the minor road (A1
into B1) has a single conflict with the right turning traffic opposite (C2). Therefore the
controlling traffic stream is C2/1. It is suggested that the give-way coefficients can be obtained
by applying those associated with the right-turn movement in the UK (which is usually giving
way). These can be obtained by making the required geometric measurements and using them
either in PICADY or in the Priority Object in TRANSYT to calculate the coefficients.
The Priority Object Auto-Assign Priority should not be used as it assumes specific conflicts exist
between specific movements (as would be encountered in the UK) which dont match those of
New Zealand.
This situation can be modelled with a few small changes to a standard T-junction library file. A
restricted traffic stream (or link) is added on the approach from the right in order to feed traffic
that is turning left into the side-road onto the slip-road. The slip-road itself is designated as a
give-way traffic stream (or link) as it gives-way to the other traffic exiting down the side-road.
The give-way coefficients can be calculated by the addition of another T-junction Priority Object
or by entering them directly.
Some adjustment to the calculated coefficients might be required in light of experience as this
situation is not quite the same as an average T-junction. Some differences in driving behaviour
may be observed due to the proximity of the slip-road give-way to the main junction. These
effects are likely to be minimal in situations where the distance of the slip-road give-way from
the main T-junction is considerable.
All situations require specification of both signal control data and give-way data.
We also recommend the use of the step-wise opposed turn model, because it, as the name
suggests, takes account of opposed situations on a step-by-step basis. It is takes account of the
opposed turn research results published in Research Report RR67.
Please note that you cannot use this model where mutual opposition exists. For this, you must
use the method described in 17.14.8
All of the following examples assume the various scenarios are built from scratch
The use of one of the supplied Library Files will, in most cases, offer the quickest
and easiest way to set up your model. Examples of each of the described
situations are provided as Library Files.
In the situation where offside-turners do not benefit from an unopposed stage, they will turn
through gaps in the opposing flow. For situations where traffic waiting in front of the stop line at
the end of green can clear during the intergreen see section 17.14.2
Where the offside turn movement does not have an unopposed stage, it is likely that the traffic
demand for that movement is low. In the absence of an offside-turn bay (dealt with in the next
sub-section) it is most likely that the offside turners will share a lane with other movements.
Occasionally there might be a dedicated lane.
Shown in Figure 17-35 is a fully signalled T-junction where the offside turners from Arm 1 have
been modelled as wholly opposed.
1. Start off with each approach traffic stream defined as signalled controlled (e.g. Arm 1 >
Traffic Streams > Traffic Stream 1 > Is Signal Controlled) and with a restricted flow (i.e. a
saturation flow), e.g. Traffic Stream 1 > Has Restricted Flow
2. You also need to specify Arm 1 (the one with the opposed movement) as a give-way, i.e.
Traffic Stream 1 > Is Give Way)
At this point it is worth pointing out that there several different ways to model
opposed turn movements. However, the instructions here are simply the
recommended ones (using the RR67 step-wise model) If you wish to learn more
about older methods that you may still come across, or indeed still wish to use,
please see section 17.14.8.
3. Now specify the give-way data (Arm 1 > Traffic Streams > Traffic Stream 1 > Give Way
Data). Set the Use Step-wide Opposed Turn model to TRUE
4. This example has no storage in front of the stop line so the Number of spaces = 0
5. Enter the Radius of Turn. You have the option of entering this directly or letting
TRANSYT work this out from the geometry of your network diagram. The diagram MUST
be scaled if you chose the latter option.
You now need to define the actual conflict with the opposing traffic. N.B. the defining of conflicts is
designed to be flexible in order to allow as many situations as possible to be modelled. Therefore
there are a number of selections required to set any particular conflict. How to define conflicts
generally is described in 17.6.
6. For this example the turning traffic is being opposed by all traffic from the opposing single
traffic stream, therefore the Opposed Traffic data item should be left set to All Traffic.
(Traffic Stream 1 > Give Way Data > General Tab)
7. Now switch to the Conflicts data (See Figure 17-36)Figure 17-39. In this example, the
turning traffic is part of a mixed stream (some are travelling straight on), so not all traffic
is opposed. The Percentage Opposed should be set to the percentage of turning traffic
(Traffic Stream 1 > Give Way Data > Conflicts Tab).
N.B. The Max Flow (opposed) is simply the Saturation Flow which youve already
specified, and this is not editable from here.
8. Add a Conflict. The controlling type is set to whatever the opposing item is a Traffic
Stream or a Link. In this example it is a Traffic Stream.
9. For this example you need to set the Controlling traffic Stream to 2/1 the traffic stream
that carries the opposing traffic.
11. Specify the Conflict Shift and Conflict Duration values. Full details of these are described in
section 17.14.7 which gives full details of the step-wise opposed turn model. Generally,
Conflict Duration should be left as 2 and Conflict Shift set to the clearance time
between the conflicting traffic.
17.14.2 Opposed offside turn with storage in front of the stop line
In the situation where offside-turners do not benefit from an unopposed stage, they will turn in
gaps in the opposing flow, and those waiting in front of the stop line at the end of green will clear
during the intergreen, as illustrated in this example.
As shown above, there is additional room for right turners to store out of the way of other traffic.
This will give additional capacity by allowing more vehicles to store before blocking the other
movements. Fortunately this is relatively easy to model in TRANSYT and the use of the supplied
Library File for this situation can speed up the modelling process.
The recommended method involves modelling the right-turn storage explicitly by adding a short
traffic stream in the middle of the junction which is long enough to store the number of PCUs
expected (see Figure 17-37). This additional lane has the right turn give way parameters. An
alternative method is described in section 17.14.2.1.
1. The approach to the opposed turn (Arm C1) should be defined as a normal signalled traffic
stream (with a saturation flow restriction), i.e. it is NOT a give-way traffic stream.
2. An additional traffic stream (on Arm C2) needs to be created to represent the storage area
in front of the stop line for offside turners. This should be a restricted give-way (i.e. give-
way bottleneck). Give-way, because it is giving way to opposing traffic, and has
restricted flow (saturation flow) as this value is needed by the RR67 step-wise opposed
turn model.
3. Traffic Stream 1B/1 also needs to be set to use the FLARE traffic model (Traffic Stream
C2/1 > Traffic Model = Flare) so that the vehicles waiting in the middle stop the vehicles
on Arm 1 from proceeding. How many vehicles store in front of the stop line can be left
for TRANSYT to work out from the link length, or by specifying your own maximum queue
storage value.
Where an early cut off situation is being modelled (with an offside turn
indicative green arrow) the use of a separate traffic stream will ensure that
any bonus capacity that exists from this situation will be automatically
taken account of by TRANSYT - There is no need for any additional
adjustment factors. Even where the green arrow phase may be particularly
short and the storage area extensive, the reduced benefit of the early cut-
off in this situation will be taken account of automatically.
4. The give-way data needs to be set up for Traffic Stream C2/1 see the previous example
for how to do this. The only difference in this situation is that the percentage of opposed
traffic will now be left as 100% as the storage area only contains turning traffic.
5. Please note that the step-wise model data Number of spaces = 0, despite there being
storage in front of the stop line. This is because we are already choosing to model the
storage explicitly using its own traffic stream This value if it were set, would represent
storage in front of the storage!
In this example there is a traffic node between Arms 1 and 1B Although this is Node is not
essential, its presence avoids the need to additionally set the OD Matrix property Allow Looped
Paths on Traffic Nodes see section 13.4.4 for the reason for this.
An older way to model the situation where traffic stores in front of the stop line and clears
during the interstage, is to skip using an explicit traffic stream all together, and to model
the bonus capacity that results by adding an appropriate end displacement (Controller
Stream 1> Phases > Phase N > Relative End Displacement). The time to add is 3600/sat
flow x storage.
This method, although straight forward, is not ideal if you expect to have to
change the stage order or phasing. Stage re-ordering may invalidate the
use of the relative end displacement, since clearance in the interstage may
no longer be available. For this reason, if you think you may be changing
the stage order or phasing (e.g. using TRANSYTs phase and stage
optimisation), you should use the recommended method in which the
storage area is explicitly modelled using its own traffic stream.
Where a right turn bay exists, as shown in Figure 17-38, there is additional room for right turners
to store out of the way of other traffic. This will give additional capacity by allowing more vehicles
to store before blocking the other movements. This situation requires the addition of a second
traffic stream at the stop line.
Traffic Streams on Arm C1 need to be modelled with the traffic model set to Flare. Using a
model like this allows the blocking by right turners of the other movements to be modelled.
Traffic Stream C1/1 representing the straight ahead lane, should be defined as signalled.
Traffic Stream C1/2 representing the right-turn bay, should be defined as a both signalled and as
a give-way. Give-way parameters will be the same as those described for the basic example in
section 17.14.1
17.14.4 Opposed offside turn with a turn bay and storage area
Figure 17-39 T-junction with offside turn bay and modelled storage
Where a right turn bay exists, as shown in Figure 17-39, there is additional room for right turners
to store out of the way of other traffic. This will give additional capacity by allowing more vehicles
to store before blocking the other movements. This situation requires the addition of a second
traffic stream at the stop line and a third traffic stream to model the storage area in front of it.
Traffic Streams on Arms C1 and C2 all need to be modelled with the traffic model set to Flare.
Using a model like this allows both the storage in the middle of the junction, and the blocking by
right turners of the other movements to be modelled.
Traffic Stream C1/2 representing the right-turn bay should be defined as only signalled, i.e. NOT
a give-way.
Give-way parameters will be the same as those described for the storage example in section
17.14.2.
Consider the situation where there are two lanes on an approach without bays or flares, with an
opposed right-turn movement. The main consideration is whether the offside lane will contain just
right turners, or a mix of traffic. If the lane is marked for right-turners only, it would normally be
expected to carry just right turning traffic. A separate traffic stream or link for this movement
would be required in this case. If, however, straight-ahead traffic is permitted to use the lane,
then it is a question of how much right-turn traffic there is: light demand will allow straight-ahead
traffic easier access to the lane, whereas heavy right-turn demand will discourage straight ahead
traffic from using it. You have to decide, either by on-street observation, by some common-sense
based calculation, or using TRANSYTs lane balancing and flow assignment processes, what the
mix of traffic on that lane will be. Where there are a high proportion of right turners in the offside
lane, some straight-ahead traffic might be able to get to the front of the queue ahead of right-
turners who might otherwise block them. The number able to do this (on average) depends on
the proportion of straight-heads to right-turners, and on driver behaviour. But it might be enough
to give a small increase in capacity which might be worth modelling with an increase in saturation
flow for example. On the other hand, even if straight-ahead traffic is unimpeded by the right
turners, the saturation flow will still be reduced as the right-turners divert and leave gaps in the
traffic flow. Having decided the mix of traffic in the offside lane, you need to specify the give-way
parameters for the opposed movement as indicated earlier.
Where there are two lanes on the approach with the opposed offside turn movement, there is a
high chance that there will be two lanes opposing the right turners and these lanes might form two
separate links. With TRANSYT 15 any number of conflicting traffic streams can be
accommodated. To do this use the add conflict facility and specify the conflicting traffic streams.
Account is taken of the increase in distance an opposed vehicle has to travel before crossing all
conflict points by specifying a longer Conflict Shift value for the furthest conflict, and that the
opposing flow is now using more than one lane.
Sometimes, a multi-lane approach may include a right-turn bay. Since the development of
TRANSYT 14 this situation, which previously required considerable care and consideration, is now
relatively easy to model simply by making use of the capabilities of the blocking Flare traffic
model.
Whether or not the bay can cope with the turning traffic will be taken account of by modelling the
bay area as a Flare traffic stream or link. The part of the adjacent (middle) lane that is next to
the bay will also need to be modelled as a separate Flare traffic stream. Both of these will be fed
by the offside approach lane which can be modelled simply as an unsignalled restricted
(bottleneck) traffic stream.
Having created the network structure and selected the relevant traffic models to use, the
remaining task is to assign traffic to the network in an appropriate way. The Lane Balancing OD
Matrix option can be used to distribute traffic to the various traffic streams. However, in light of
additional local knowledge you may wish to adjust the allocation of flows to better match your own
predictions. This can be easily done by switching the Allocation Type on certain paths through the
junction from Normal to one of the other options.
Figure 17-41 Diagram overlay shows where the Flare (CPDM) model is used.
17.14.6.1 Alternative method using quick flares.
Despite the ease in which this situation can now be modelled in TRANSYT, it is possible that
TRANSYT users will still come across the former way of modelling this situation and hence the
details of how to do this have been retained here for reference:
If using only quick flares to model this situation, rather than setting the Traffic Model to Flare, it
is necessary to know whether the bay is large enough to store all of the right-turn demand or not.
Once you have decided whether the bay can cope with the demand or not, the traffic stream
structure can be set. If the bay can cope with the right turn demand, the approach could be
specified as two or maybe three links (including a short one to model the effects of the centre
lane). Whichever way it is modelled, the capacity of the offside lane will be affected by the
proportion of right-turners in the stream. The greater the number of right turners present, the
fewer straight-ahead vehicles in the lane.
If the right turn is not especially critical, it would be possible to use three traffic streams, with the
saturation flow of the middle lane reduced in proportion to the number of right turners. The fact
that right turners can then queue in their own link in TRANSYT, whereas in reality they might not
all be able to reach the stop line, may not matter too much. If, however, the proportion of right-
turning traffic is high (but still not enough to fill the bay) it might be better to model the situation
with one traffic stream feeding two further traffic streams representing the bay and the adjacent
portion of the main lane. If the bay does fill up, it will effectively make the upstream offside lane a
right turn only lane. In this situation (seen in Figure 17-40) there will be some space ahead of the
point where the right turners divert into their bay. This extra space can be fully used by the
straight ahead traffic (whether they actually use the space is another matter). In many cases it
may prove difficult to find an ideal modelling solution to your problem. However, with the
application of common sense and experience it should be possible to find a solution that meets
your particular requirements.
TRANSYT uses a method of modelling opposed offside-turns within traffic signals that is superior to
the traditional TRANSYT 12 opposed offside-turn model traffic signals. In the traditional method,
the defined opposed saturation flow is assumed not to vary over the opposed green time and the
required data items are maximum flow (opposed) and slope coefficient. The new model derives a
give-way capacity which varies from time-step to time-step according to the opposing flow for
each step.
To activate this model the Use Step-wise Opposed Turn Model option is set. When set, the
maximum flow (opposed) and slope values are not required (N/A) and two RR67-related pieces of
information are needed instead the number of storage spaces available within the intersection
which offside-turners can use without blocking straight-ahead traffic and Radius of Turn (m) which
is the radius of curvature of offside-turning vehicle paths. You have the option of letting TRANSYT
work out this value from the geometry of the network diagram. If this option is selected the
network diagram MUST be scaled to match reality.
The step-wise (RR67) opposed turn model is only relevant to signalised give-way
situations and should not be selected for other situations.
The requested number of storage spaces is NOT used to calculate the additional
capacity due to those vehicles storing in front of the stop line which clear during the
intergreen. This particular effect should be modelled either explicitly using the
recommended method already described, or the older method which requires an
extension to the effective green using a Relative End Displacement on the relevant
phase.
A further two parameters which are for use when applying the step-wise opposed turn model are
also required:
The first of these additional parameters is the Conflict Shift. This is the delay between the
controlling flow departing and the controlling flow influencing the give-way. This has the effect of
delaying both the increase in opposed flow once traffic passes (e.g. clearance time), and also the
drop in opposed flow when a platoon of opposing traffic enters the junction (i.e. reaches the stop
line). The influence of the opposing traffic is essentially shifted (delayed) in time. The value set
will depend largely on the geometry of the junction (e.g. size), but generally will be a small
positive number of seconds (i.e. not zero).
The second of these additional parameters is the Conflict Duration. This is the time by which to
delay the establishment of discharge after a reduction in flow on the conflicting arm. It is in effect
a give-way equivalent to the start displacement for a signal controlled stop line and allows for the
time it takes for vehicles to get moving after a gap in the opposing flow has appeared. It would
normally be about 2 seconds. Without this, the results may be slightly optimistic. The data can
be found at Traffic Stream N > Give Way Data -> All Movements > Conflicts > opposed by Traffic
Stream X. N.B. it has no influence during times when the opposing traffic flow is rising.
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.
2. At a T-junction, the traffic making the near-side turn into the minor road has a lesser
effect on the minor road capacity than the straight-ahead traffic does. The effect of the
turning traffic (whose paths dont even cross) is approximately a third of that caused by
the main road straight ahead traffic. Missing this effect out is not likely to be critical, and
will produce a slightly pessimistic result for the performance of the junction. This means
one less link on the main road and one less movement, and hence a conflict referenced
by three other movements that you no longer have to specify.
3. If using a link structure to model a roundabout, use a single link for the circulating
carriageway, but only if none of the traffic on the approaches are platooned.
4. Use Library files as much as possible as it will speed up construction of your network and
reduce errors too. Be sure to check each data value though, to ensure that they are set
correctly for your particular network requirements.
5. Some simplifications and suggested give-way parameters are described in section 25.5.2.
It can be used for any of the following situations, but not limited to:
This effect is generated by drivers not having to pause at the give-way line to check for opposing
vehicles before making their turn because they know that there wouldn't be any opposing
vehicles.
A give-way traffic stream (or link) with a separate restricted flow is one that is controlled by the
restricted flow parameters (i.e. saturation flow) when the opposing traffic is stopped at a red
signal, but is controlled by the give-way parameters (maximum flow) when the opposing flow is
given a green signal. (In earlier versions of TRANSYT this was known as a give-way
bottleneck.)
To set one up is straight-forward: Firstly you need to specify a traffic stream (or link) as a give-
way WITH a restricted flow and enter both the give-way and restricted flow data. If the
controlling traffic stream (or link) is signalled, that is all that is required. However, if the
controlling traffic stream (or link) is not itself signalled the effect you wish to model will not
operate as the controlling traffic stream (or link) would normally have to be signalled. However,
introduced in TRANSYT 14, is the additional conflict option Upstream Signals Visible (see
Figure 17-43). This allows, say, a controlling link to be a restricted or unrestricted traffic stream
(or link) and it still takes account of the effect of any upstream signals. An example has been
produced below to indicate how this is set up and its effect on the restricted traffic streams (or
links) OUT-profile.
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.
The OUT-profile in Figure 17-46 clearly shows the expected three levels of out flow initially
running opposed, then discharging at saturation flow, and finally free flow (once any queue has
dissipated).
The traffic model can be set either globally for the whole network (Outline: Network Options >
Traffic Options) or for each individual traffic stream (or link) (Outline: Arm n > Traffic Streams
> Traffic Stream n > Modelling).
The Link or Traffic Stream options for Traffic Model are as follows:
Network Default: Select this if you wish the network (global) value to determine what
option is used for this traffic stream (or link).
PDM: Select this if you wish to use the platoon dispersion model for this particular traffic
stream (or link).
CTM: Select this if you wish to use the cell transmission model for this particular traffic
stream (or link).
Flare: Select this if you wish TRANSYT to model the limited capacity of a short lane, i.e.
one that is liable to block back and prevent traffic from entering it or other flares that it
may block. Only those traffic streams or link that are liable to block or be blocked need
to be set up to use the appropriate Flare traffic model.
At the network (global) level, the following Traffic Model options are available:
PDM / CTM: Select between Platoon Dispersion and Cell Transmission models.
Force To PDM / Force To CTM: Select one of these options if you wish to FORCE all
links and traffic streams to use the chosen model irrespective of what local value has
been set. This is useful if you quickly wish to investigate the effect of, say, using the
PDM model throughout the network.
The network diagram overlay Traffic Model Type can be used to inspect what links and TS are
modelled using which model.
The Random Parameter is a modelling factor that defines the randomness of the queueing
situation on a traffic stream (or link) and relates to the calculation of queues and delay.
These new modelling parameters are just part of the necessary changes to TRANSYT to allow it
to model fully unsignalised junctions and to remove the assumption that networks have to be
predominantly signalised.
These values can be set either globally for the whole network (Outline: Network Options >
Traffic Options > Advanced) or for each individual traffic stream (or link) (Outline: Arm n >
Traffic Streams > Traffic Stream n > Modelling > Advanced).
This is an advanced feature of TRANSYT and unless you have very specific/exact
modelling requirements, it is recommend that the global value is set to
Automatic, while all the individual links are left at their default of Network
Default.
Network Default: Select this if you wish the network (global) value to determine what
option is used for this traffic stream (or link).
Automatic: Select this if you wish the TRANSYT internal logic to work out which option is
best for this traffic stream (or link). If the item is an unsignalled give-way then the
Vehicle-In-Service will be INCLUDED and if not, it is NOT INCLUDED.
Uniform (TRANSYT): Select this if you wish to assume uniform queueing This option
sets the NOT INCLUDED in-service delay, and is what all previous versions of TRANSYT
have used, irrespective of the link type.
Random (ARCADY): Select this if you wish to assume random queueing This option
sets the INCLUDED in-service delay, and is, essentially, what all versions of ARCADY
uses.
Custom: This allows you to select the in-service coefficient manually i.e. INCLUDED or
NOT INCLUDED.
Automatic: Select this if you wish the TRANSYT internal logic to work out which option is
best for every traffic stream (or link) which has been set to the Network Default option.
Uniform (TRANSYT): Select this if you wish to assume uniform queueing for every
traffic stream (or link) which has been set to the Network Default option.
Random (ARCADY): Select this if you wish to assume random queueing for every traffic
stream (or link) which has been set to the Network Default option.
Force To Automatic: / Force To Uniform: / Force To Random: Select this if you wish
to FORCE all links and traffic streams to use these options irrespective of what local value
has been set. This is useful if you quickly wish to investigate the effect of, say, using the
same options that TRANSYT 13 uses, i.e. Force to Uniform.
The options are basically the same as those provided for vehicle-in-service and offer the same
ability to force the global network value on the individual links and traffic streams. The main
difference is the actual value used as the Random parameter for each of the options:
Uniform (TRANSYT): This sets the value to 0.5 the value used for all links in all previous
versions of TRANSYT, and represents a partly random queueing situation, which is generally an
appropriate value for predominantly-signalised networks.
Random (ARCADY): This sets the value to 1.0 the value used on all arms/approaches in all
previous versions of ARCADY, and represents a full random (unsignalised) queueing situation.
Custom: This allows you to select the random parameter coefficient manually. If an upstream
arrival pattern is deemed to be particularly consistent, there may be scope to reduce the random
parameter below 0.5, but generally there will be no justification to reduce it to zero or near-zero,
as no matter the situation, no arrival pattern of flows will be without some randomness.
Furthermore, one has to remember that TRANSYT was empirically developed and extensively
tested/validated for use with signalled networks, all of which included the use of a random
element of delay of 0.5 throughout.
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.
Basic results for each traffic stream (or link), such as each items Degree of Saturation
Basic results for the whole network, such as the whole network Performance Index, which
are calculated by summing and/or averaging individual traffic streams (or link) results
Basic results for parts of the network, such as collection/routes, or bus network. You can
see such results by generating reports or by setting up Data Grids to show such subsets.
User-defined custom data grids and TRLs default data grids are accessible from the
horizontal toolbar data grid button/dropdown.
All of the above for each time segment, and additionally for a summary time segment.
(This is only applicable if there is more than one time segment defined.) All of the above
are visible in the Data Editor and in Data Grids.
Detailed results from the different traffic models in the form of graphs and also equivalent
animations in the network diagram.
Basic results are saved in the file when you save it - To generate animation and graph data the
file needs to be re-run. What animation and graph data exists depends on what traffic model
are used to model the traffic streams and links in the network.
If you are displaying results, including graphs and animations, remember that
these represent results from the last successful run of TRANSYT. If you
subsequently change, say, the cycle time, but dont re-run TRANSYT, then the
results may be inconsistent with the current data file.
Remember also that results are available for only one Analysis Set at a time.
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).
A full set of individual results can be produced as part of the TRANSYT Report. (See
chapter 21 for a detailed description of each of the individual results found within the
Report.)
The Data Outline (see below) contains results data as well as input data. The results are
displayed within the Data Editor. Any data item that is a result, i.e., an output from
TRANSYT, is shown with a light green background:
When looking at results, some items may appear as N/A. This is usually because you
are looking at results for the whole network or for the summary time segment and the
particular data item is inapplicable. You can check this by showing the Help>Glossary
screen. In many cases inapplicable data items will simply be hidden from you.
Data Grids (see below) can also be used to display results, either as they are, or in a
customised format (see section 9.1.11 for how to use data grids to show results.)
When multiple cycle times exist within the network there will be multiple time-lines displayed.
See the network diagram (Chapter 10) for details of the items that can be animated.
19.4 Graphs
After running a file, you can view various graphs for each traffic stream or link. All but one of
these are accessed via the Flow Graphs and Spatial Graphs buttons on the main vertical toolbar,
or via Main Menu > View. PI-Offset graphs are access from Main Menu > Tools.
You can display any number of graphs; each graph will update to show data for
the current item unless you use its padlock (see section 6.9). Each graph can be
stretched to whatever size is required.
Signal states shown in the graphs can either show actual or effective greens;
change your preference via the option at the bottom of the graph.
The graphs types available will depend on the traffic models used for the selected
item and whether you have yet run the file; use the Summary Results screen to
confirm which data is available.
All graphs can be copied to the clipboard (via right-clicking) and you can also
include Cyclic Flow Profile graphs in reports by adding entries to the
Options>Reporting>CFP Graphs section of the Data Outline. These are arranged
in 2x2 blocks when you generate a report.
Please see elsewhere in this manual for background discussions of the various graph types.
They are listed below, with an example shown for each.
Note that you do not have to 'run' each graph separately. After running the file once, all
graphs for all traffic streams and links are available; simply select the graph type via the Graph
buttons on the main vertical toolbar, and then select the traffic stream or link of interest, via the
Data Outline or the network diagram. You can show several graphs at once, and each graph will
update to show data for the current item, unless you lock it.
A variety of flow graphs are provided. The main graph type is the standard Cyclic flow Profile
(CFP) graph which plots the variation over a complete cycle of the rate at which traffic arrives at
the stop line (the IN-profile) and leaves the stop line (the OUT-profile). An example of a CFP
graph is shown. Further explanation of the IN, OUT and GO profiles can be found in section
24.1.2
Each CFP graph represents, for one traffic stream (or link), the variation during one signal cycle
(horizontal axis) of:
a) The flow up to the stop line (red and green bars)- the IN-profile
b) The flow leaving the stop line (green and blue)- the OUT-profile
The two flow profiles are overlaid so that the flow distortion caused by the red/green periods of
the signal can be observed easily. Vehicular flows, shown in red, are stopped by the red light and
leave at a later time at saturation rate as shown in blue.
Details of where the traffic comes from is indicated and the red and green times of the relevant
(feeding) upstream traffic streams or links are shown. The green times shown are displaced
forward by the cruise time between the source item and the downstream end of the item being
viewed. Therefore, the arrivals from the sources should more or less correspond with a vertical
line dropped to the stop line on view. The offset used is displayed to the right of each source
red/green times.
The CFP graphs primary role is to help with validation and calibration of the TRANSYT model. It
is unlikely that all data specified is correct first time and even if no coding errors are made, the
model may be based on inaccurate assumptions about traffic behaviour. Comparisons can be
made between on-street arriving and leaving traffic patterns and those presented by the CFP
graphs. CFP graphs are also useful in understanding the interaction between different traffic
streams.
Furthermore, CFP graphs give a quick visual indication of how well co-ordinated the signals are for
each traffic stream (or link). This too can be compared to the on-street situation to ensure that
the model is as accurate a representation of the real-life situation as possible. The greater the
delay imposed by the signals, the greater will be the difference between the IN-profile (red and
green) and the OUT-profile (green and blue). The more green and the less red, the less delay is
being caused to traffic on the traffic stream (or link).
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.
1. The time-axis can be rotated in order to align different graphs to the same time at the
origin (such as the networks arbitrary zero) to allows graphs of related links to be more
easily compared.
2. The link length in metres is also given on the left-hand side of the queue graph - Useful
as it influences the total dispersion effect along the link.
3. The Performance Index for the chosen item is shown on the left-hand side.
4. The Mean Modulus of Error (MME) is shown on each graph. This refers only to the arrival
flow at the stop line and is a measure of how far the profile of the arrival flow deviates from
the mean value.
The MME is expressed as a number in the range 0.0 to 2.0. A uniform flow for example has
a MME of 0.0, while a high MME would indicate an item on which the flow was strongly
bunched or platooned and which would therefore benefit particularly from efficient co-
ordination of signals. The MME is similarly useful for selecting items on which co-ordination
of signals is not very significant (low MME) and which would therefore be suitable for the
location of sub-area boundaries if it should be necessary to break a region into smaller
sub-areas.
A general rule-of-thumb is that for a MME of less than 0.3 the item may not be worth
considering for coordination.
In addition to the standard Cyclic Flow Profile graph there are a number of other Flow graphs
available. These are selected via the dropdown box at the bottom left of the Flow Graph. These
(and there functionality) are described below:
InFlow This shows just the in-flow portion of the normal graph
OutFlow - This shows just the out-flow portion of the normal graph
EntryFlow - This shows just the entry-flow portion of the normal graph
GOFlow This shows what the outflow would be if the traffic stream (or link) was
fully saturated, and no blocking was occurring.
GOFlowWithBlock This shows what the outflow would be if the traffic stream (or
link) was fully saturated, with existing blocking effects taken account of.
Occupancy - This shows how many PCUs are currently on the traffic stream (or link)
at any point in the cycle.
Pointflow This graph is used in combination with the Point (m) distance value to
show the flows at any point along the traffic stream (or link). This can help to
match up an observers location when collecting on-street data with the predicted
shape at exactly the same point within the model. This is of most use when the
links and queues are long resulting on-street measurements having to be made
significantly upstream of the stop line. The two diagrams below show the flow
profile at the upstream end of the traffic stream (at 0 meters) and at four-fifths of
the way down steam (at 80 metres). The effects of platoon dispersion can clearly
be seen.
There are four types of spatial graphs. These are selected via the dropdown box at the bottom
left of the Flow Graph and are as follows - Flows, Occupancy, Queue and Traffic. The
graph types also match up with the network diagram overlay options that are available.
Like the Flow graphs, details of where traffic comes from is indicated and at the top of the graph
the signal states of the relevant (feeding) upstream traffic streams (or links) are shown. Unlike
the Flow graphs, the green times of the source items are NOT shifted in time, since the 'green
waves' can be seen directly.
The vertical axis represents distance back from the stop line. (The stop line is at the bottom of
the graph.) These graphs are essentially a type of time distance diagram, and clearly show
green waves of traffic travelling from the upstreams (at the top of the diagram) to the next
downstream traffic stream (or link) in question (at the bottom of the diagram).
The queue graph plots represent only the uniform component of any queue. The MMQ (mean
maximum queue) values shown in the final prediction table of the PRT file includes additional
queueing due to random effects (i.e. cycle to cycle variations) plus oversaturated conditions.
At some junctions, queueing may occur during the green period. This happens when the flow
along the traffic stream (or link) is greater than the saturation flow.
Queueing in the green may also appear on either major or minor shared links. This happens
when a platoon on one shared link joins the back of a discharging queue on the other shared link.
The queue graph for a shared link does not include the queues for the other shared links in the
same group, i.e. for the purposes of the displayed graphs, the main and shared links are, in
effect, treated as separate links, even though they in fact share the same road space.
Two examples of queue graphs shown here one is from a PDM traffic stream and the other from
a different CTM traffic stream. The differences that can be seen between the two graphs reflect
the different spatial information that the two traffic models naturally contain. The rougher
stepped nature of the CTM graph is determined by the number of cells that the item is made up of
Longer traffic streams with slower traffic will result in more cells being created.
Graphs drawn for items modelled using CTM will naturally look slightly different as CTM naturally
has a better idea of the spatial positioning of traffic but lacks the ability to model dispersion.
The screen capture of a PDM occupancy graph clearly shows how the edges of the blue platoon
of traffic becomes less distinct (fuzzier) as it travels from the upstream signals to the next stop
line This is due to the dispersion effects that are modelled by PDM.
In the screen capture immediately above, traffic from both green periods reaches the next stop
line such that most of the traffic is undelayed, i.e. it arrives during green.
19.4.2.3 Flows:
The plot of flows shows the relative flows at each point on the link at each point in the cycle. It
gives an indication of where along the traffic stream (or link) vehicles are moving. It is almost
an inverse of the CTM queue graph. Deeper GREEN colours are indicative of where traffic is
flowing freely. Lighter or the absence of shading shows either an absence of traffic, or, slowed
or queued traffic. You can see in the screen capture that there is an obvious void where the
typical saw-tooth shaped queue will be.
19.4.2.4 Traffic:
This plot is a combination of both the queue and flow graphs. It is similar to the occupancy
graph but is colour coded - It uses multiple colours to represent stationary (queued) and moving
traffic. Red indicates stationary traffic and green indicates moving traffic. Amber and red is
used indicate values in between. This graph corresponds to the network diagram Traffic
overlay (in 2D and 3D). It is particularly useful because it that combines the effects of two
graphs such that you can see both the total volume of traffic and what that traffic is doing.
The main purpose of the P.I. graphs is to indicate the likely change in P.I. following a change in
the offset between this controller stream and the upstream controller stream. The optimum
offset value indicated by the graph can be checked via a full TRANSYT run.
The Performance Index (PI) graph plots the P.I. for a traffic stream (or link) against the offset-
difference. The P.I. value, which TRANSYT uses to calculate the network P.I., is shown to the left
of the vertical axis. The graph shows how the P.I. would vary if the offset-difference was altered
by an amount varying between zero and the cycle time.
Since traffic stream (or link) on the edge of the network will have no upstream controllers they
cannot be offset from them. For these items the P.I. remains constant. In all the other cases the
P.I. for a particular item will vary depending on the offset-difference. The lower the P.I. the better
the co-ordination.
Each time distance diagram consists of the diagram itself plus a number of additional items. The
diagram is made up of progression bands, stop lines which the chosen series of links, traffic
streams, or OD paths pass through, and the time and distance axis.
The progression bands are shown in a variety of ways depending on the chosen band type, (See
section 19.5.5)
Stop lines are shown as a thin horizontal bar showing either the actual or effective green time.
Up to two bars are shown at each stop line. The upper one (of a possible two) is always shown
and represents the green times affecting the traffic being shown. The other bar shows the
combined green times of all other traffic stream (or link) that are feeding into the displayed
downstream traffic stream (or link). Unsignalled nodes are displayed with 100% green time.
Multiple green periods are automatically catered for.
The vertical-axis shows the distance away from (downstream of) the stop line of the first traffic
stream (or link) for each subsequent stop line. The distance between the stop lines reflects the
true distance between them. A distance scale and vertical scrollbar allows a limited part of the
total distance to be selected. The vertical-axis is also labelled with the signal node number (in
brackets) associated with each stop line, and the downstream traffic stream (or link), shown
between the stop lines.
The horizontal axis shows by default, one complete cycle. Multiple cycles on this axis may be
selected if needed (see Figure 19-2).
After running a file, you can view a time distance diagram (TDD), which is accessible via the TDD
button on the main vertical toolbar, or via View>Time Distance Diagram.
Time distance diagrams can be displayed by simply selecting an existing TRANSYT path, route or
by making a multiple selection (by holding down the CTRL key) in the network diagram. When
making a multiple selection, the items must be selected in the order that you wish them to be
displayed, and only after the second item downstream of the first is selected will the diagram be
displayed. To select the relevant traffic streams you need to click on any lane of that traffic
stream not the traffic stream itself. For links, simply select each link.
Upon loading, the TDD displays (by default) the flow from stop line to stop line for the currently
selected Route, Path, Link or Traffic Stream selection. A blank TDD will result if none of these
are selected. Multiple selections (via the network diagram or the Data Outline) must contain at
least two connected items before a TDD will be drawn.
You can display any number of TDDs; each one will update to show data for the current selection
unless you use its padlock (see section 6.9). Each TDD can be stretched to whatever size is
required.
Note that you do not have to 'run' each TDD separately. After running the file once, any
valid set of link-to-link progressions are available to display; simply select click the TDD button
on the main vertical toolbar, and then select the links of interest, via the Data Outline or the
network diagram. You can show several TDDs at once, and each one will update to show data
for the current valid selection, unless you lock it.
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.
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.
The effect of dispersion along many links is an important factor when considering progression.
Each set of signals produces a block of traffic that travels from one stop line to the next junction.
This green wave of traffic has a front and a back which is determined by the effective green
time, the cruise speed along the link and the level of dispersion.
The TDDs Show Dispersion option provides both the actual front of the green wave from stop
line to stop line and also an approximation of the back of the green wave. Therefore this feature
is particularly useful as it ensures that the full extend/breadth of the green wave is shown on the
diagram. As a result, any adjustments to, say, offsets, to improve coordination of a particular
route, can be made with good knowledge of when the majority of the traffic will be arriving at
the downstream signals. N.B. The dispersion shown is always for normal traffic.
A TDD can show progression in five different plot modes (see figures) as follows:
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.
Flow Mode: Shows flow rates (in green and grey) along the selected item at
all times of the cycle, and additionally shows queues in red. GREEN indicates
the presence of high flow rates.
The flows make use of the same information used to display animations in the
network diagram.
This mode, in some ways, gives the most traditional looking time distance
diagram and is probably the most useful.
The time-axis can be rotated in order to align different TDDs or graphs to the same time
at the origin (such as the networks arbitrary zero) to allow them to be more easily
compared
The diagram reflects the timings associated with the currently selected Analysis Set and
Time Segment. In addition to the standard locking mechanism, the diagram can be
locked to the current time segment
Since traffic on a particular traffic stream can be made up of more than one traffic type
(normal, bus, tram) the Traffic Mode option can be set to display only the flows
associated with any of the traffic types.
Signal states can either show actual or effective greens; change your preference via the
Graphs button menu or via the user Preferences screen. A TDD can be copied to the
clipboard (via right-clicking)
Because Collections, by definition and multi-link selection via the network diagram, do
not necessarily consist of contiguous links, progression of TRANSYT routes is limited to
those links that are linked to the first selected link in the chain
The Flow Threshold value sets the tolerance for the mode Flow Mode (Tolerance).
Only cells with flows greater than or equal to this threshold are drawn. Compare Figure
19-7 with Figure 19-8.
20 Generating Reports
After running a file in TRANSYT, you can choose to generate a report that summarises all input
data and results. The report is in the form of a HTML file that is automatically saved to disk.
(You can also generate reports before running the file, in which case the report will contain only
input data.)
Select what you want by ticking or un-ticking the various items in the list. To open up a section
to see its contents click on the + symbols. Tick a section heading to either select or deselect
everything within it. Once youve happy with your selections, press the Generate Report button
to close the Configurator and to generate a report. The report will appear in the Report Viewer
from where the Report Configurator is also available (section 20.3).
Generated reports are useful both a) as final reports summarising a TRANSYT file and b) a
convenient way to quickly view all data in a tabular format.
To generate a quick report, show the Report Configurator then turn off all options other than the
Final Prediction Table option. See chapter 20 for a detailed description of each of the individual
results.
Turn on Final Prediction Table and TRANSYT 12 Tables to include a set of summary tables that
resemble the main tables shown in TRANSYT 12 PRT files.
Turn on Signals and Output to include a set of tables that covers all output values in the file.
There are also some report options affecting the behaviour, contents and appearance of reports
which are set via the user Preferences screen (section 6.18)
Note that the order of links, traffic streams and nodes in reports uses the sorting and grouping
selected via the Options>Sorting section of the Data Outline and you therefore control the
ordering as an option associated with the data file, NOT as a user preference.
Under the Signals section an option to Group by Controller Stream is available. When
selected, separate signal data tables for each individual controller stream will be created. Turn
off this option to have just one table per topic for all controllers.
Some report content will not appear if it is unselected in the files Network Options.
If a company-wide definition of reports (including Data Grids) is needed TRANSYT can be set to
point to a centralised configuration file instead of the local one via the user Preferences screen
(File>Preferences), using the Import Settings From External File option.
The Report Configurator allows multiple configurations of selected and unselected sections of
reports to be saved for future use. Select the Manage Configurations tab in order to add, save
changes to, rename or delete your configurations.
The Load configuration button, which is available whenever either the Sections or Options
tab is selected, offers a convenient shortcut to load existing configurations.
Configurations are stored as part of your installation of TRANSYT, rather than in each file.
However, the particular selections that you make in a file will still stay with the file so that
anyone else opening the same file will see the same selections. The recipient of that file can then
choose to save the particular selection in it, as one of their own configurations.
The default configuration (Default prefixed to the configuration name) is used when running a
report for a new file. This is the only time the default configuration is used.
Select a configuration using the saved configuration list in order to either save it, rename it, set
it as the default (for new files) or to overwrite it with the current settings. Note that selecting
from this list does not affect the current settings. The current settings are changed only when a
new configuration is loaded.
There are various options affecting the contents and appearance of reports, available via the
Options tab.
If you use the Data Grid screen (chapter 9) to store customised grid layouts, then you can mark
each layout for inclusion in reports. To do this, you need to use the Data Grid menu item
Custom Grids Manager to set the UseInReport flag. For convenience, a short-cut to this is
provided from the Report Configurator. You must also turn on the Custom Grids option in the
Report Viewer screen (and then refresh the report if needed).
If the data file has not yet been saved and therefore does not have a filename, the name
Untitled will be used, and the report will be saved to the Windows temporary folder,
overwriting any existing untitled report.
If the report includes diagrams, they are saved as separate .gif, .jpg or .emf files in the same
location as the HTML file, and their names will be based on the HTML filename. If
moving/saving/e-mailing the report file, please be aware that you will need to include these files
as well as the HTML file itself.
Additionally, the Report Viewer contains options for converting the file to a Word or PDF
document, in which all diagrams will be embedded and the file can easily be saved, emailed, etc.
The generated PDF files are fully paginated. Some tables cannot be accommodated if your Print
orientation is set to Portrait If any of your tables are cropped on the right-hand side then
please use File > Print Setup to set your orientation to Landscape and then re-convert your
report to PDF.
If you intend to save reports as PDF files, then the HTML files are effectively only
temporary files and we recommend using the user Preferences Screen to set the
Report Folder to a temporary folder such as c:\temp folder.
Use the orange contents at the top of the report to quickly jump to sections of the report.
In TRANSYT, only one report can be viewed at a time. You can however use any web browser to
view any number of reports, whilst using TRANSYT, refreshing them as necessary.
Reports are saved in the location specified on the user Preferences Screen (section 6.18). This
can either be set to always be the same location as the data input file, or alternatively can be set
to a fixed location, such as My Reports for example. In either case, the filenames of the report
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.
Whenever you change data in the TRANSYT file, or select a different current analysis or select a
different demand set, a red message will appear in the top left-hard corner of the report (see
below). As the wording implies, this indicates that the report is out-of-date, i.e. it does not
reflect the contents of the current TRANSYT file.
Pressing the Refresh button does two things - it allows the report to reflect the current state of
the TRANSYT data AND allows the report to take account of any changes to the Report Options
(see section 20.1.2).
The Refresh button does NOT re-run TRANSYT for you. Therefore, if the TRANSYT
data has changed (or a different Analysis Set selected) and TRANSYT has not
been re-run, the results in the file will be out-of-date. These same out-of-date
results will be reflected in the report, even after a refresh of the report. To ensure
that the report shows up-to-date results you need to re-run TRANSYT before
pressing the Refresh button.
In order to ensure you dont forget, a yellow warning message is printed at the
top of the report if the report is refreshed and the results in the data file are still
out-of-date.
Note: Use the Copy, Print and Print Preview buttons on the main TRANSYT toolbar.
Use the Copy button to copy any selected to the clipboard, from where you can paste it into a
word processor or spreadsheet. (Experiment with the configuration option Spreadsheet Export
Mode) To copy the entire report, firstly select everything by pressing CTRL+A (or use the right-
click menu). Pasting the entire report may be quite slow if the report is large, depending on the
application you are pasting it into, and the formatting may not exactly match the original
formatting.
To print the report, use the Print Preview and Print buttons on the main TRANSYT toolbar. As
long as you printing to standard A4 size paper in portrait orientation, no tables should be broken
across pages. If you wish to print on other size paper, or remove the page breaks, we
recommend pasting the report into a word processor and formatting from there, or using the
report viewer Convert options to create a Word or PDF version of the report. Converting to a
PDF offers the best way to obtain good pagination within the report.
The Report Viewers Tools drop-down menu will show a menu containing a few utility functions:
Open this reports containing folder: opens the Windows folder where the report is saved.
Open this report in your default web browser: launches your default web browser and loads
the report. You can then close the Report Viewer and continue working in TRANSYT, switching
to the last run report in your default web browser as necessary.
Keep Inside Application Window: turn this OFF to have the Report Viewer disconnect from
the main TRANSYT application window, so that you can position it freely, e.g. on a second
desktop monitor.
In all cases, the files need to be loaded into TRANSYT or otherwise created (e.g. via the
File>Copy Into New File option).
File comparison is set up from outside the Report Viewer, via the Tools>Compare Files option.
This will show the screen below, which lists each file currently loaded in TRANSYT (i.e. the files
as shown in the blue file bar at the bottom of the screen). It is recommended that you save any
new files with a meaningful name; otherwise they will all appear as [New File], although this is
OK for quick comparison runs.
Tick the Compare box for each file that you wish to compare. Note that there is no limit to how
many files can be compared at once. Choose a colour for each file (by double clicking in the
Colour column) to be used when differences are found.
If the Only show differences option is turned on, values are only printed when they differ
between the files, and blanks shown otherwise. If this option is turned off, then all values for
the MASTER file (the first ticked file) are always printed, and values for the other files printed
where they differ.
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.
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.
21 TRANSYT 15 Outputs
This chapter provides a description of the TRANSYT table-based output and a description of the
main output values provided within the TRANSYT results. Many of the items (particularly the
input data items) are self-explanatory and described elsewhere, so these items are not
mentioned in any detail here.
File Info: Includes filename used; date and time the file was run; which
analysis set was run; location of file, etc.
Network Diagram > Main Diagram: A the network diagram image of the
complete network.
Network Diagram > Custom views: Any saved views of the network that
have been selected to appear in the report (see the network diagrams
Manage Views screen).
Summary: This section lists data errors, data warnings and data Information
statements. It also provides File Information such as the Run Title, file status
and units used. N.B. a Run Summary (similar to the on-screen Summary
Results) is also part of this section. The Analysis and Demand Sets specified
within the file are also listed as part of the summary.
When requesting Input (This is a collection of sub-sections which includes all of the
input data, except for signal data:
Traffic Nodes: Details node input data (N.B. does not include signal timings.)
Fuel Consumption: Details all fuel consumption data, e.g. WebTag data
used and assumed vehicle class proportions for the network
Individual Basic Data: Details of arm data, traffic stream and link data such
as lengths, saturation flows, type (signalled / give-way / etc.) and RR67 lane
data. This section includes most of the Pedestrian crossing data, but
excluding modelling and flow data.
Individual Flow Data: Details of total flows and flows per traffic type
(Normal/Bus/Tram) each traffic stream and link.
Quick Flares: Details of any quick flares within the file, e.g. saturation flow
of flare and usable length of it.
When requesting Signals (This is a collection of tables under the sub-headings Input,
Output and Diagrams. These sets of tables include all of the signal timings data AND
signal timing results):
Sub-heading Input:
Phase Data
Intergreen Matrix
Sub-heading Output:
Resultant Stages
Sub-heading Diagrams:
N.B. for this section to appear in the report when selected, it must not be hidden
by the Network Option that hides all TRANSYT 12 timings in the GUI.
This group of tables includes details of Resultant Stages, Resultant Phase Green
Periods, TRANSYT 12 style Stage Timings, Traffic Stream (and link) green times
When requesting Output (This is a collection of sub-sections which includes all of the
TRANSYT output data): It includes sets of results equivalent to the result sections of the
Data Outline.
Individual Flare
Point to Point Journey Times: A point-to-point journey time tables for each
user-defined OD Matrix.
Final Prediction Table: This is a summary table of Link and Traffic Stream
results. It includes results for every individual traffic stream, link and
pedestrian crossing as well as network totals and totals for each collection.
When requesting Custom Grids (This is a collection of user-defined tables which have
been created using a Data Grid, and then selected by the user to appear in the report):
User-defined tables
You can double-click on this item to gain access to which custom grids should
appear in the report.
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.
This is a list of the key output results that appear in either the Vehicle Summary or the
Pedestrian Summary.
Please note that these results are also repeated under their own sub-sections, namely:
In pedestrian crossing only tables some items will be labelled as Ped/hr in the
appropriate places). Where tables display a mix of pedestrian and vehicular traffic
data PCU/hour should be interpreted as PED/hour where needed.
Practical Reserve Capacity (per cent) Vehicular links and traffic streams only
Utilised storage (%) This value (new to TRANSYT 15) gives a useful estimate of how much of a
traffic stream or link is filled with traffic based on when the back of the queue is at its longest.
This helps to identify where blocking problems might occur. Values close to or over 100% are
likely to be block the upstream junction.
Flow during Gap Accepting (PCU/hr) Pedestrian crossings only streams only
Weighted Cost of stops ( per hour) Vehicular links and traffic streams only
This is the sum of the delay and stop costs for the traffic stream (or link) plus any of the following
penalties:
Excess queue penalty (see Maximum Queue Length and Penalty - 26.6.1).
Excess degree of saturation penalty (section 26.7)
Low degree of saturation penalty
Pedestrian gap-accepting penalty (see section 26.8)
The delay and stop components are also weighted by any link/ traffic stream-specific delay or stop
weights (as in Link Data, Traffic Stream Data or Give Way Data) before summing.
If you wish to include the costs given by the P.I. in any form of cost-benefit analysis, it is
advisable they you use the un-weighted P.I. instead, to ensure that the various weighting
factors on delays, stops and queues do not result in an unrealistic estimate of community costs.
In the Final Prediction Table normal (traffic) links are indicated by N, bus links by B, tram
links by T and imported pedestrian links by P in the Link ID column. Similarly, the Traffic
Stream column is also used to indicate which traffic types use each traffic stream.
Major Link
Links having shared stop lines (see Shared Stop lines description) are identified by a reference to
the major link in this column. The major links are identified by their own bracketed link number
in this column.
This is the flow counted on the link or traffic stream entry, i.e. the sum of the IN flow profile
elements. For links, usually this equals the value specified in the Links Data Screen (Outline:
Links>Link n>Link Flows>Total flow) for the link since the inflows are automatically adjusted for
compatibility after data input, to give the specified total. For traffic streams, usually this is simply
the derived total flow based on summation of the flows on all the paths passing through the traffic
stream. However, in the event that this specified flow causes a traffic stream (or link) to be
oversaturated, either with the initial signal settings or at any part of the hill-climb process,
downstream traffic streams (or links) will have reduced inflows. In such cases where the flow into
a traffic stream (or link) is smaller than the original value by more than 10 PCU/hour, the inflow
value is marked with a < symbol in Final Prediction Table>Traffic Stream (or Link) Results. An
oversaturated traffic stream (or link) itself will usually have the specified inflow and will not then
be so marked; its outflow will, however, be less than expected and this will be apparent when it is
noted that the degree of saturation (see later) is greater than 100 per cent.
The CTM restricts traffic entering a traffic stream (or link) at its upstream end if
the first CTM cell is occupied. Therefore, even for entry traffic streams Calculated
Flow Entering values can be reduced or even zero. Zero values of Calculated Flow
Entering may indicate that the traffic on that part of the network has locked up.
This is the flow counted crossing the stop line, i.e. the sum of the OUT flow profile elements. If
the traffic stream (or link) is under-saturated this will be the same as the Calculated Flow
Entering the traffic stream (or link). However, in the event that the traffic stream (or link) is
over-saturated, this results in less traffic leaving than arriving, as TRANSYT will not allow more
traffic to leave than it is physically possible to do so.
If TRANSYT encounters an oversaturated node, the flow going into the traffic streams (or links)
immediately downstream of that node reduces by a corresponding amount. This output value
indicates the value of that reduction, i.e. the difference between the specified total traffic streams
flow and the TRANSYT calculated total flow. Values over 10 PCUs are additionally indicated in the
output as having an Adjusted Flow Warning.
This value is the saturation flow associated with either a signalled traffic stream (or link) or the
average maximum possible flow at give-ways or give-way bottlenecks, e.g. if using a link structure
it is specified in the Links Data Flows Screen (Outline: links>Link n>Saturation flow)
However, at give-ways it is not simply the specified maximum flow, but is the maximum flow
possible at any particular time averaged over the cycle. If a give-way also has a separate
restricted flow value specified (i.e. a give-way bottleneck), this can result in a value higher than
the give-way maximum flow, as when the opposing traffic stream signal is at red the give-way
flow rate increases to the specified saturation flow instead of the maximum flow.
Quick flares also affect this value The calculated saturation flow of a link with a
quick flare is an average value that depends on the green time as well as
saturation values used by the flare.
For link shares data and results relating to the shared stop line are shown with the major link
referenced in a separate column, and duplicated values shown as bracketed values. E.g. queue
lengths that apply to the complete shared stop line and NOT to individual links shows the value
repeated for each link of the shared stop line. Such values should, obviously NOT be summed to
give a total it is ALREADY a total, which is simply shown more than once.
For each side of a pedestrian crossing a saturation flow is calculated. This is fully explained in
section 14.6.
The average rate at which traffic can exit the traffic stream (or link) when all effects are taken
account of, such as blocking, reduced flows, etc. This value can be used to easily calculate the
Degree of Saturation. It is equivalent to the average GO flow when including blocking effects.
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:
Calculated capacity
The reason for the second equation, which simply references the calculated capacity of a link, is
that not all of the effective green can be used e.g. due to blocking effects and furthermore the
full saturation flow is not always possible despite traffic being presented with effective green.
The calculated capacity takes account of all downstream effects, such as blocking that influences
the ability of the traffic stream (or link) to let traffic out of the traffic stream.
A DoS value of over 100 corresponds to oversaturation and a queue will grow for as long as the
specified flow conditions exist.
The Total Flow into the traffic stream (or link) is the entry flow as it takes account of
oversaturation of the upstream sources feeding that item, i.e. as the upstreams become more
oversaturated the DoS on the downstream can be seen to go down.
Demand flow corresponds to the total demand independent of when the flow arrives or whether
the flow can actually arrive onto the traffic stream (or link). The entry flow corresponds to the
flow that can actually arrive onto the link within the time period simulated; For CTM links and
CTM traffic streams, it is constrained by the downstream link traffic. The demand flow and entry
flow are normally approximately equal unless the traffic stream (or link) is over-saturated, in
which case, the demand flow is greater than the actual flow. TRANSYT reports entry flow based
degree of saturation for non-entry links, and demand flow based degree of saturation for entry
links.
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%.
The above four flow rates are shown only for pedestrian crossings using the walk-on-red
pedestrian model. The cycle is split up into four different time periods each representing a
significantly different scenario for pedestrians wishing to cross. The flows indicate the volume of
pedestrians crossing during each of these periods. The time periods are calculated internally
within TRANSYT. N.B. Green is a reference to the green man period.
This is the resultant flow over the stop line during red per cycle when nearside turning of traffic
on red is permitted.
This is the time for which the signal head for traffic on a traffic stream (or link) actually shows
green.
This is the time for which traffic behaves as if the signals were green.
All results, other than those indicated, exclude walk-on-red pedestrian crossings.
Mean cruise time per PCU (or Veh) (seconds) including walk-on-red pedestrian crossings
This is the mean un-delayed travel time along a traffic stream (or link) obtained from up to six
possible inflow cruise times specified in the Link Flow Data or Traffic Stream Flow Data these
cruise times being weighted in proportion to their inflow. If, optionally, speeds are specified,
cruise times are first calculated from the speeds and the link length.
Mean delay per PCU (or Veh) (seconds) including walk-on-red pedestrian crossings
This is the average value of delay experienced by a PCU on the traffic stream (or link). It is
obtained by dividing the total delay rate (uniform and random + oversaturation) by the flow into
link. The delay is similarly calculated for Traffic Streams, but the mean delay value is a weighted
average of the delays of the traffic on all paths passing through the traffic stream. .... For traffic
streams, please note that the delays experienced by PCUs using a particular TRANSYT path
through the network will experience their own delays specific to that path. This ability of
TRANSYT to take account of different path delays allows it to provide more accurate travel time
results.
Signalled LoS
This is the US Highway Capacity Manual (2000) signalled junction Level of Service (LoS) for a
signalled traffic stream (or link). This result is only available if the LoS option under Network
Options has been enabled.
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.
This is the uniform component of the total rate at which delay is incurred on the traffic stream (or
link). The uniform component is equivalent to the average number of PCUs queueing on the
traffic stream (or link) during the typical cycle.
The random delay rate is the component of the total delay rate which is caused by random
fluctuations in traffic arrivals on the traffic stream (or link). If the degree of saturation on the link
exceeds 100 per cent, the total delay rate includes a further oversaturation component which
accounts for the steady increase in the queue during the period, due to arrivals exceeding
departures.
The total delay rate on a traffic stream (or link) equals the sum of the values given in the
uniform column and the random + oversaturation column. This total delay rate is equivalent to
the average number of PCUs queueing on the traffic stream (or link) during the period specified in
the General Data, Simulated time (mins) (Main/Common Data).
This is the total rate at which delay is incurred on the traffic stream (or link). This is only shown
if the option to Display separate uniform and random results is switched off (see Network
Options).
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.
The total delay rate for the traffic stream (or link) is multiplied by the value specified in the Main
(Common) Data, Value of Delay and divided by 100 to give cost per hour in pounds. An asterisk
after the delay cost indicates a delay weight other than unity has been specified in the Link data
or Give Way Data for this traffic stream (or link) data equivalents).
This is the average percentage of stops per PCU entering the traffic stream (or link), i.e. 100
means that, on average, each PCU stops fully once. The estimate takes account of both uniform
and random stops and allows for fractional (partial) stops as described in section 25.3. Stops/PCU
will often exceed 100 per cent where link inflows are near to capacity because some vehicles may
have to stop twice.
This is the predicted number of stops associated with a typical under-saturated cycle
This is the predicted number of extra stops associated with the randomness of arriving traffic and
of oversaturated conditions.
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.
The total number of stops per hour is first obtained as the product of mean stops/PCU and the flow
into the traffic stream (or link). This total is then increased or decreased to allow for the kinetic
energy lost in making a full stop from the average cruise speed on the link as compared with a
standard stop from 12 m/second. The new total of equivalent standard stops per hour is then
multiplied by the value specified in Main (Common) Data, Value of 100 Stops and divided by
10,000 to give cost per hour in pounds. An asterisk after the stop cost indicates that a stop
weight other than unity has been specified in the Link Data or Give-way Data for the traffic stream
(or link) data equivalents).
All results are relevant to all links, including walk-on-red pedestrian crossings.
When the results are shown in Vehicles instead of PCU, the PCU result is converted into
vehicles using the relevant vehicle mix and PCU factors.
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.
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.
This value is similar to the Mean Maximum Queue, but is the equivalent value at the end of the
time segment (EoTS).
This is the maximum number of PCUs that can fit within the physical space of the traffic stream
(or link) (which is appropriate for the modelled time period). This can be either a user-defined
value or a TRANSYT calculated one.
This is the maximum percentage of used storage on the traffic stream (or link). This value is only
relevant if all traffic is stopped.
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.
On traffic streams and links where a queue limit has been specified, the mean back of queue is
checked against the queue limit during each step of the typical cycle, and any excess queues are
averaged over the cycle to give an average excess queue for the traffic stream (or link).
For links other than those specified with a Max Queue Storage value, TRANSYT computes:
This assumes that each PCU in a queue occupies 5.75m along a lane having a standard saturation
flow of 1850 PCU/hour of green. If the mean maximum queue exceeds the above maximum
queue storage, the printout is marked with a + symbol in the mean maximum queue column to
indicate a possible problem which the user is advised to check if the timings are to be
implemented in practice.
For links that do not have saturation flow, such as a give-way, the saturation flow is assumed to
be 1850 so that the assumed max queue storage is simply the link length divided by the 5.75m.
For Traffic Streams other than those specified with a Max Queue Storage value, TRANSYT
computes:
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 the calculated cost on the traffic stream (or link) associated with excess queue.
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
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.
This is the effective green time wasted through traffic starvation. This is shown as an absolute
value in seconds rather than as percentage so that it can be easily summed over traffic streams
and links.
This is the effective green time wasted because of blocking back from downstream links. This is
shown as an absolute value in seconds rather than as percentage so that it can be easily summed
over traffic streams and links.
This is the total number of seconds of wasted green time due to either the starvation or blocking
back effects.
As described in section 25.10, the estimates are sub-divided into three components: fuel used at
cruise, while delayed, and for stopping and starting. A user-definable network-wide composition
of seven vehicle types is used to calculate the fuel used as a rate per hour. None of these results
are relevant or shown for pedestrian crossings.
These values presented here are the link and traffic stream equivalents to those presented as part
of the Final Prediction Table output (See section 21.3.3). Results are shown for all links and
traffic streams.
The advanced output values are only accessible from the Results/Advanced sections of the
Data Outline. Results are shown for all links and traffic streams.
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.
This is an internally used penalty (i.e. not reported in final PI). This value, in normal
operational circumstances, will always be zero.
This is an internally used penalty (i.e. not reported in final PI). This value, in normal
operational circumstances, will always be zero.
Ped Gap Accepting Penalty ( per hour) shown for pedestrian walk-on-red links only
This is the penalty cost added to the PI as a result of the level of pedestrian gap accepting
set by the user being exceeded.
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.
This is a summation of all the penalty costs associated with Excess Queue Limits and DoS
limits, which are added to the PI calculation.
This is the sum of the delay and stop costs for the link WITHOUT any weightings or
penalties applied, giving the true cost on the traffic stream (or link).
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.
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.
This is interstage associated with the green time that together makes up the TRANSYT stage.
The TRANSYT stage minimum acts as a constraint on the optimiser. It includes the preceding
interstage and the minimum green time for that stage.
This set of results are part of the TRANSYT 12 tables output. This table tabulates results for
each green period of each phase of each traffic stream. These results are probably only of
interest to those already familiar with them from using earlier versions of TRANSYT.
Derived from the library stage data , this is the first stage in which the named phase runs, i.e.
the Starting Stage defines which of the stage change times starts the change to the green
period on the traffic stream (or link).
Derived from the library stage data, this is the first stage in which the named phase no longer
runs, i.e. the Ending Stage defines which stage change time ends the green period. The green
periods can run between any stage numbers, e.g. 2 to 3, 2 to 6, 7 to 3, or 4 to 4 (in the latter
case, the green period will for the complete cycle).
The start lag is the time in seconds from the stage change time to the start of green signal on
that phase. The start lags (used internally by the TRANSYT model) are derived from the user-
specified intergreens and phase delays. The TRANSYT Starting Stage number plus the Start Lag
defines the TRANSYT time at which the actual green begins.
Usually the start lag corresponds to the interstage time, as shown in Figure 21-1. TRANSYT
adds the displacement of start of effective green (see Figure 3-9) to this lag to give the time of
start of traffic flow assumed in calculating delays etc. for the traffic stream (or link).
The end lag is the time in seconds from the stage change time to the end of green signal for that
phase. Often this value is zero. The end lags are derived from the user-specified intergreens
and phase delays. The TRANSYT Ending Stage number plus the End Lag defines the TRANSYT
time at which the actual green ends.
Stage 1 actual signals
Red Red
Green Red
Demand
change to
stage 2 Start green on
stage 2
Start Start
Lag Lag
Start green on
Demand stage 1
change to
stage 1
Stage 2 actual signals
Amber Red/Amber
Figure 21-1 Lag between change demand and start of green signal
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.
Number of Stages
Stage n
Traffic Node
This is the ID of the intersection (node) at the link exit as specified in Link n>Traffic Node, or the
Arm exit as specified in Arm n>Traffic Node. This is the node which traffic from this link feeds
through. Strictly speaking it is no longer required by the TRANSYT model, but has value in
allowing links or lanes to be associated with one another as part of a particular junction, allowing
the associated items to be easily manipulated within the network diagram. Most importantly, it
also allows results to be aggregated for a traffic node, by defining the traffic node as part of a
TRANSYT collection.
The Start (time); End (time) and Duration of up to four green periods (in seconds) shown to
the traffic stream (or link) is presented. The times are the actual green times: to obtain effective
green times, add the displacements specified in Main (common) Data
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.
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.
The following network-wide results are part of the Report Summary AND part of the Report
Output:
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.
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.
An indication of how much of the network is oversaturated. A value of 0 equates to the network
being within capacity.
This is simply the link or traffic stream ID with the highest DoS within the complete network.
This is simply the link or traffic stream ID with the lowest practical reserve capacity (PRC) within
the complete network.
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.
1st line: TOTAL For all traffic streams, links and pedestrian crossings.
2nd line: BUSES For bus traffic streams and links only.
3rd line: TRAMS For tram traffic streams and links only.
5th line: OTHER (NORMAL) For Normal traffic streams and links only.
Certain lines only appear when these traffic types exist within the network
This is the product of total flow entering the link and link length, summed for all traffic streams
(or link equivalents). It represents traffic demand in the network. If any links within the network
are oversaturated, some traffic will be unable to pass on to downstream links; consequently, the
total distance value can be less than would occur in the absence of oversaturation. In practice,
such apparent reductions in travel due to oversaturation would probably be made up later as
queues disperse, but this would be after the end of the period in Main (Common) Data, Simulated
Time, for which TRANSYT calculations are made.
This is the product of the flow into the link and the sum of the mean delay time plus mean cruise
time, summed for all traffic streams (or link equivalents). Another interpretation of this value is
the average number of vehicles present in the network during the specified period. Some vehicles
will be queueing - the number estimated by the average total delay (uniform and random-
plus-oversaturation) - the remainder will be travelling between intersections.
This is total distance divided by total time to give an average speed which represents the typical
journey speed within the network.
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.
Other values in the summary are the appropriate totals of the link and traffic stream values.
Where applicable these values are multiplied by the individual weightings (indicated by an asterisk
if other than unity) before adding into the totals.
Signalled LoS
This result is only available if the LoS option under TRANSYT Network/Network Options has been
enabled. This output is part of the Vehicle Summary and Stops and Delays results tables.
This is the US Highway Capacity Manual (2000) signalled junction Level of Service (LoS)
calculated for each node. The Node LoS is based on the flow-weighted average of the total
delay of all signalled traffic streams (or links) feeding into that particular Traffic Node.
When traffic streams are used in a network, they generate an underlying network structure far
more complex than the user ever sees. This structure is made up of path segments most of
which are similar to links. Some of these form a chain that carries traffic flows from one specific
location to another. None of the path segment data is editable simply a consequence of
using traffic streams - or of any particular value to users. Path segment results however may
occasionally be useful in interpreting the network, as they reveal details of the traffic on a
particular path segment, travelling along a particular TRANSYT path. By default they are
hidden (to speed TRANSYT up), but can be revealed by enabling this option: Network Options >
Traffic Options > Advanced > Calculate results for path segments. See Outline: Traffic Streams
> Traffic Stream n > Path Segments.
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 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.
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.
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.
Use the Data Outline to navigate to Network Options > Network Timings. Double-click to
bring up the Data Editor. Click on the Network Cycle Time. Click on the Add option in the
Input Variables section of the Analyser screen to add this variable.
Use the Data Outline to navigate to Network Results > Stops and Delays. Double-click to
bring up the Data Editor. Click on the Weighted Cost of Delay. Click on the Add option in
the Input Variables section of the Analyser screen to add this variable.
The range of the input variable is set by default to the built-in range of the variable, which
in this case is 30-500. A step-size is also set automatically, but you may wish to change
this depending on the accuracy and speed required. Having adjusted the range and step-
size, the Analyser screen should now look like the below:
Press either the Line or Bar button under the X-Y Graph mode button to generate the
graph. This will perform a set of TRANSYT runs and plot the results, while also tabulating
the results as it goes. It is normal for some points to be missing; this usually occurs at
the extremes of the x-axis range.
Because TRANSYT re-runs the entire file for each data point, the process
may be slow. Do not use a small step size unless you are prepared to wait
some time for the graph to be completed.
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.
When running x-y graphs, one variable is altered while everything else in the file remains
constant. Sometimes this will be unrealistic, since there are interactions between the chosen
variables, such as give-way geometric ones. In particular, if plotting a geometric item such as
entry width as the x-axis, remember that all other geometries will be held constant. If reality, if
there is a flare, then the effective flare length would also alter as the enter width changes.
However, the x-y graphs are still extremely useful in terms of showing trends and the overall
effects on results.
It is also important to remember that each data point in the graph represents a complete re-run
of TRANSYT. Unless using un-optimised evaluation timings, this means that the actual signal
timings may be different for each data point. In some cases, consecutive data points may
represent quite different sets of signal timings, leading to correspondingly different performance
indicators. This in turn can sometimes lead to local spikes or other discontinuities in the graph.
Usually these are small in magnitude and are to be expected given the nature of the signal
optimiser. Sometimes, however, larger effects are noticeable, which may be worth investigating
further for example, by saving two or more versions of the TRANSYT file with the x-axis item
set to values either side of the spike, and studying the full set of results and link timings for
each file.
The speed of running graphs will depend heavily upon the network size and the model
parameters.
Many graphs give intuitive results, for example confirming that delay decreases as saturation
flow increases. Some graphs, however, are more complex, and the shape of such graphs may
arise from the interactions between the many variables in TRANSYT.
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.
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.
The Audit Trail facility is accessed via the main Audit Trail Window ((File>Audit Trail), which
consists of a horizontal toolbar and an event grid below that displays a single line for each
recorded event (see below). Deterioration
File status/comments
File changes
Save/run events
Each row of the event grid reports the date and time of each event, the event description, what
particular item it applies to and which user made the change. All recorded events are stored
within the TRANSYT data file.
How to record file changes and save/run events is explained in section 23.1.1. How to record
File status/comments is explained in section 23.1.2.
To start recording changes to your TRANSYT file select the Log Everything option. When active
this item will turn red (as shown) and while it is active every file change that appears in the
main TRANSYT UnDo event list will be added automatically to the top of the Audit Trail grid.
The logging of everything can be switched off and on whenever you like. Note how the
switching on and off of this facility is also recorded as an event. This ensures that any gaps
where recording has been stopped and restarted will be evident in the Audit Trail.
In addition to direct changes to the file, key actions taken by the user are also recorded and
shown with a grey background. These are events such as carrying out an evaluation or
optimised run or saving the file. These are recorded because they cause changes to important
data in the file.
If you want new files to Log Everything by default, then please select File>Preferences, and then
under the General section set the option Log Everything in Audit Trail for new files.
The toolbar Add Status & Comments option will reveal a new Window (see below) that allows
you to record a file status and to add any comments about the file at the same time. The User
data field is used to identify who is recording the status and comments. This is populated
automatically from your login name and PC ID, but can be changed before saving.
You can type anything you like into the File Status box, but for your convenience a dropdown list
of some commonly used descriptions is available (see below). Pressing Save will add the
status/comment as an event to the Audit Trail grid and close the File Status window. The
status/comment updates are shown with a blue background in the event grid.
If you want to be prompted to save a status/comment each time you save a file (excluding the
saving of Library Files), then you can tick the box Prompt on each save. Furthermore, to get
all new files to prompt you each time you save them, then please select File>Preferences, and
then under the General section set the option Prompt to save Audit Trail status for new files.
It is sometimes useful to display only the status updates, especially if the event grid is
particularly long, therefore the toolbar option Show only status update is provided to filter out
the file changes.
It may be desirable or necessary to provide copies of TRANSYT files to clients. You may wish to
give your clients files with comments and file changes stripped out of the file, while at the same
time retain all your Audit Trail events within your file for future reference. You do this in
TRANSYT using the main menu option File > Create A Customer Copy.
When you chose to Create A Customer Copy you will be prompted to provide a file name and
folder location for the new customer file. The default is the existing file location and the file
name with the words Customer Copy appended to it.
The toolbar Copy option can be used to copy either all of the events or just those you have
selected onto the Windows clipboard, ready to paste into some other application.
The toolbar Clear Events facility has three options - clear ALL events, clear up to a particular
row, or clear everything except the status/comments.
The headings of each of the columns of the event grid can be used to sort the list of events.
Use the File>Merge Network option to accomplish this. The Library File selection dialogue will
open, from where you can either select a Library File, or browse and select the TRANSYT file that
will be merged with the current file. The screen shown below will then appear.
Usually, both the current network and the network being merged, will share various IDs such as
those associated with links, traffic streams, controller streams, e.g. both will probably contain a
Traffic Stream 1. Since IDs must be unique, a prefix/suffix mechanism is used to distinguish the
items in the network being merged from the existing items. In the screenshot, the letter N is
entered as the prefix for all items requiring a unique ID. When the Merge button is pressed, all
the items from the new network will be prefixed with an N, as long as this does not cause any
other errors. You can of course rename items once the merging process is complete. To use
different prefixes de-select the Same for all option.
By de-selecting the Copy All option you can also selectively merge the different components of
a file.
You can only merge other TRANSYT 15 files. To merge files created with older
versions of TRANSYT you will need to open these files, save them as TRANSYT 15
files and then carry out the merge.
Use the 3x3 location grid to tell TRANSYT where the merged network should be positioned
relative to the existing network. In the screenshot the right-hand button has been selected, so
the new network will be positioned to the East of the existing network.
You should check carefully the Task List after merging a network and will generally want to link
up at least one traffic stream or link from the original network to the new network.
As an illustrative example, the screenshot below shows a left-right stagger Library file after
being merged with itself. In this example, the network runs successfully without requiring any
changes and gives a total Performance Index of exactly twice the value from the original
network, as would be expected.
Alternatively you can also use the Add new Junction option in the network diagram to merge
in a file. This method works subtly differently firstly you need to click where you want to place
the new item in the diagram and secondly you then need to select the file to merge. Otherwise,
this method works in the same way.
23.3 Drive-on-the-left/Drive-on-the-right
TRANSYT can model both drive-on-the-left (for UK, etc.) and drive-on-the-right (for continental
Europe, North America, etc.) situations. The driving side can be set simply by setting the
Driving Side data field in the File Description data section of the Data Outline. The driving side
can be changed at any time. Alternatively you can select File>Preferences and in the
Localisation section, adjust the option Driving Side, which will force all new files to a
particular driving side.
Throughout TRANSYT, the terms nearside and offside are used in place of left and right wherever
possible, so no actual data changes occur when the driving side is changed, other than the
automatic arrangement of nodes, traffic streams and links in the network diagram.
When merging files TRANSYT checks to see if the file being merged has the same driving side as
that of the current file. If different, TRANSYT automatically mirrors the file as it is merged so
that the whole network is consistent. Additionally, there is the Tools option - Mirror File
(Swap driving side) that can be used to instantly mirror the currently displayed file.
Importantly, this means that the supplied sample and Library files, which are in drive-on-the-left
format, can be quickly switched over.
PLEASE REFER TO YOUR PRODUCT LICENCE AGREEMENT FOR DETAILS OF THE TERMS
AND CONDITIONS OF USE OF THIS PRODUCT. ANY UK/INTERNATIONAL
RESTRICTIONS OF USE WILL STILL APPLY. YOU MUST STILL BE LICENSED TO USE
THIS PRODUCT IN THE COUNTRY IN WHICH IT IS BEING USED.
The PDM and CTM models can be applied to each individual traffic stream (or link) or across the
whole network. However the use of the Cell transmission Model (CTM) on entry traffic streams
(and links) offers no advantages and will slow down runs of TRANSYT so it is best to use PDM for
entry traffic streams and links.
For all three models the common cycle time is divided into a number of intervals called steps.
These are typically one second in length, but can be shorter. The program running time is related
to the number of steps the more steps there are the longer it will take. For any cycle time, it is
often convenient to make the number of steps equal the cycle time, by setting the Resolution
to 1. The maximum resolution (number of steps per second) is five.
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.
An example cyclic flow profile is Figure 24-1. Such profiles are useful in validating the model;
after running any file, you can see the cyclic flow profile for any link via the Graphs button on the
main vertical toolbar.
In the TRANSYT traffic model, all of the calculations are carried out by manipulation of these
profiles. No representation of individual vehicles is made. In most calculations it is assumed that
the profiles are repeated during each cycle of the signal. In practice, the flow profile during any
one cycle will vary from the average, due to the random behaviour of individual vehicles. Direct
calculations are made to correct for this effect.
The operation of the traffic signals is represented by time points within the cycle when each
stage green period ends and the change to the next stage begins. These, combined with
interstage periods, start and end time lags, and appropriate start and end displacements allow
effective greens to be determined when traffic on a link can actually flow through the junction.
40 units = 1 cycle
0 10 20 30 40
Time (seconds)
To model traffic behaviour on individual links, TRANSYT uses cyclic flow profiles. There are
three main types of profile which make use of different combinations of arriving and departing
traffic. These are illustrated in Figure 24-2.
(i) the IN-profile is the pattern of traffic that would arrive at the stop line at the downstream
end of the link if the traffic were not impeded by the signals at that stop line;
(iii) the GO-profile is the pattern of traffic that would leave the stop line if there was enough
traffic to saturate the green.
(a) IN PROFILE
(c) GO PROFILE
Figure 24-2 Definition of IN, OUT and GO flow profiles
The traffic flowing into a link is obtained by taking the appropriate fraction of the OUT-profiles
from the upstream links. The profile of traffic entering a link will be displaced in time and
modified during the journey along the link due to the different speeds of the individual vehicles.
Thus, platoons of vehicles will be partly dispersed. The amount of dispersion is determined by
applying a form of exponential smoothing, related to the cruise time along the link, to the
incoming traffic. The platoon dispersal coefficient can be modified for individual traffic streams
(or links) (see section 24.1.4). The cruise time is the average un-delayed travel time for
vehicles flowing from the upstream stop line to the downstream stop line. Cruise times (or,
alternatively, cruise speeds) are specified separately for each inflow source. Figure 24-3
illustrates the smoothing (dispersion) process.
The user specifies in the Main (Common) Data screen (Outline: Network Options>Traffic
Options) whether they wish to use cruise times or cruise speeds. The data which is then
specified in the Links Data screen (Outline: Links>Link n>Sources>Source n) must be
consistent with this.
The inclusion of a model of traffic dispersion means that TRANSYT automatically takes into
account the importance of having good progression on short links.
The calculations using the IN, GO and OUT profiles are carried out for each step of the cycle for
each network item (traffic stream and link repeatedly until a stable result is reached, starting with
an assumed queue of zero at the stop line. The pattern of queue growth and decay, and hence
delays for this stable situation, represents average traffic behaviour throughout the period being
studied.
By using the profiles as described, TRANSYT in effect simplifies traffic behaviour. Although
individual vehicles are not modelled, the technique used is equivalent to, and may be thought of in
terms of, the following description. Each vehicle is assumed to proceed un-delayed along a link
until it reaches the stop line at the end of the link. If the vehicle then meets a red signal or a
queue which has not yet discharged it is modelled as stopping instantaneously. Traffic queueing is
assumed to take place entirely at the stop line from where vehicles discharge during the effective
green with instantaneous acceleration up to cruise speed on the downstream link. This simplified
behaviour is illustrated in Figure 24-4 by the trajectory in time and distance of vehicle 1.
Realistic trajectory
D1 = Effective green displacement
at start of green
TRANSYT trajectory
D2 = Effective green displacement
Undelayed vehicle trajectory at end of green
Time
D1 D2
Effective signals
Stop- as in TRANSYT
line
Red Green Red (Actual signals)
Red/Amber Amber
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 is a number, K, which modifies the platoon dispersion factor F
as follows:
1
F=
Kt
1+
100
where t = 0.8 times the average cruise time in steps.
A negative value of K gives zero dispersion, but K = 0 gives the default value.
For details of how TRANSYT deals with dispersion associated with different source types, e.g.
buses and trams see section 25.7.
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.
Shared links are modelled in CTM in very much the same way as in the PDM. The flows, queues
and delays are calculated for each of the shared links separately. Vehicles from each link are
discharged over the stop line according to their arrival time at the stop line, but at rates and
times common to all links sharing the stop line.
However, there are some restrictions in the CTM for modelling shared links. In the CTM, each
set of shared links is treated as a single link representing one physical traffic stream / queue.
This has the following implications.
1) In the PDM, it is possible for traffic on shared links to have different cruise speeds. The
CTM, on the other hand, assumes that traffic on all links in the group of shared links have
the same cruise speed. An average cruise speed is used for all shared links for in a group
of shared links. As a result, it is not advisable to model very slow or fast traffic on shared
links with CTM. This includes mainly minor shared bus link with a bus stop, and minor
shared links carrying emergency vehicles
2) Each minor / major shared link can have its own separate upstream links. However, in
considering blocking back situations, shared links at one stop line are considered as a
whole. Suppose a downstream link has an upstream link which is a minor link. If the
downstream link is blocked, then no traffic from any of the set of shared links at
upstream can move.
3) Each group of shared links is physically one link, and so must share the same upstream-
end node as well as the same downstream-end node or stop line. They must also be of
the same length. More generally, each link (or group of shared links) must head for a
node where it meets all the downstream link(s); a link must not have a downstream link
sharing the same downstream-end node. Similarly, each non-entry link (or group of
shared links) must come from a node where the upstream link(s) end; a link must not
have an upstream link sharing the same downstream-end node.
The restrictions in item (3) in the above list to the network mean that some of the network
modelling techniques in TRANSYT cannot be used for the CTM. In the existing TRANSYT, there
are some special network coding techniques for handling special practical situations, such as
opposed turn bays, flared links, staggered junctions, and so on. These coding methods may
generate what may be referred to as non-standard network components. One example is that
link n is upstream of link m but both links n and m are controlled by the same signals node.
When the CTM is selected, TRANSYT will perform a check on the network; any non-standard
network components will be reported and it is necessary to modify the network.
TRANSYT Shared links represent different traffic sub-streams on one link, i.e., either traffic of
different vehicle types, or traffic with different origins / destinations of travel. The use of the
CTM should be aimed at keeping track of different flows of traffic, especially in terms of their
destination, and modelling their behaviour at the end of the link. Modelling mixed traffic flows
with different cruise speeds is not a strength of the CTM.
The recommended method of modelling flares is to represent the flared area using separate
traffic streams or links which are set to use a Flare Traffic Model. This option will
automatically use the most appropriate model for the circumstances. In some cases this will be
CTM, i.e. where flares are longer than can reliably modelled using the other blocking model -
CPDM. How to model flares (short bays) is fully described in chapter 16 - Working with flared
approaches
The CTM models traffic flow both in uncongested and congested situations. This has an
implication in the modelling of give-way traffic streams (or links). The original TRANSYT give-
way model assumes that the maximum give-way flow or capacity F decreases linearly with the
increase of flow q on the controlling traffic stream (or link), with the interception F0 and slope
A1. The relationship may be written as F(q)=F0-A1q. As controlling flow increases gradually
from zero to saturation flow s, the give-way capacity decreases from maximum value of F0 to
F(s)=F0-A1s. This model applies only to the uncongested situation of traffic flow on the
controlling traffic stream (or link). Note that the minimum uncongested give-way capacity is
either zero or F(s), whichever is larger.
In the congested situation for the controlling traffic stream (or link), at the onset of
oversaturation due to reducing downstream capacity, the flow starts to drop from the saturation
flow. As the controlling traffic stream (or link) becomes more and more congested, the flow
decreases eventually to zero. In TRANSYT (since version 13.1.2) the congested give-way
situation is modelled in CTM by extending the original TRANSYT give way model. It is assumed
that there is a maximum congested give-way capacity when the controlling traffic stream (or
link) is over saturated, and that the give-way capacity decreases linearly as controlling traffic
stream (or link) flow decreases. Eventually both controlling flow and the give-way capacity
becomes zero when traffic is completely jammed. This relationship may be written as F(q)=B1q,
where B1 is the slope and is given by the ratio of maximum congested give-way capacity over
the corresponding controlling flow.
Thus, there are two linear relationships - one for uncongested situations and one for congested
situations. See Figure 24-6. The minimum uncongested give-way capacity can be conveniently
taken as the maximum congested give-way capacity. This is the default value for the minimum
uncongested give-way capacity.
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.
It has the ability to model blocking effects where traffic on a particular traffic stream (or link)
will fill up with traffic preventing more traffic entering it and potentially blocking traffic entering
other links in the process, such as associated with short flares/bays. It is the feeding traffic
streams (or links) upstream of a short traffic stream (or link) that will experience the blocking
effects. This in turn can prevent traffic on these upstreams reaching other downstreams.
It is however, NOT designed or suitable for modelling the blocking of upstream junctions To
model this effect you should use the CTM traffic model.
This particular model is not directly selectable within TRANSYT. It is only one of the two traffic
models that are capable of modelling blocking back from one traffic stream or link into another
the other model being CTM. TRANSYT selects the most appropriate of the models for you.
Details of how to use this model are in section 3.12 and chapter 16.
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:
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.
Currently there are certain restrictions on the use of the CTM. If any of these restrictions are
broken, either an error or warning will be shown in the Task List.
1) Minimum length of a traffic stream or link is equal to the distance travelled in one time
step, and is therefore determined from the Network Timings Resolution and the Cruise
Speeds, e.g. if the average cruise speed is 50 km/h and the resolution is set to 2 steps
per second then the minimum length will be 7 metres.
TRANSYT generates a warning message if the link length is significantly different to that
used internally by the CTM, based on the fastest cruise speed of any source of traffic
entering the traffic stream (or link).
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.)
CTM requires all traffic on a link share to move at the same speed over the same distance (i.e.
must have the same cruise time and cruise speed, hence the following restrictions:
1) Slow buses, i.e., buses with stops are not represented / modelled by the CTM; they are
treated as having the same speed as the traffic flow on the link
2) Emergency vehicles are not represented / modelled by the CTM; they are treated as
having the same speed as the traffic flow on the link
3) It is inappropriate to model trams by the CTM. If the CTM is selected and if there is a
tram link in the network, an error message is issued to the user.
4) Time segment analysis with time-varying entry link flows is now supported by the CTM
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.
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.
On links where traffic arrivals exceed capacity, the traffic queue increases each cycle by the
amount by which arrivals exceed departures throughout the period of oversaturation. Thus, the
uniform delay during the typical cycle does not account for this additional delay due to the steady
increase in queues. In TRANSYT, the oversaturation delay rate is calculated as the average
value of this oversaturation queue during whatever period is being modelled (the modelled time
period. Thus, the queue is zero at the start of the modelled period and twice the average at the
end.
A further element of delay not accounted for in the uniform delay calculation is that due to
variations in traffic arrivals from cycle to cycle. This is known as random delay. It may be
conveniently thought of as the average number of PCUs that fail to discharge during the green
time and hence form an initial queue at the start of the following red period. On links where
arrivals exceed departures, a steadily increasing oversaturation queue will also be added to the
average random queue to give the queue at start of red.
Figure 25-1 illustrates, for a particular case, the way in which the three delay elements (uniform,
oversaturation and random) vary as the degree of saturation on a link increases.
stopline data:
60 saturation flow = 3600 pcu / hour
Cycle time = 90 seconds
Red time = 50 seconds
Duration of flow = 30 minutes
40
Oversaturation
delay
Random
delay
20
Uniform
delay
0
0 60 70 80 90 100 110
Degree of saturation (percentage of maximum discharge flow)
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:
4f
1/ 2
Random oversaturation f F f F pcu hours / hour
2 T
4
T
F = the maximum flow that can discharge from the link (PCU/hour)
T = the duration of the flow condition for which signal timings are being
considered (hours)
Where f and F are approximately equal, the random delay rate is extremely sensitive to small
errors in either of the flow values. For example in Figure 25-1 an increase in the degree of
saturation from 95 to 100 per cent will increase random delay by some 80 per cent. This
sensitivity is thought to reflect actual traffic behaviour. In such conditions it is advisable to
check the flow data being used. Even so, there are practical limits to the data accuracy that can
be achieved and the estimates of random delay may be expected to differ significantly from
actual values on links near to 100 per cent saturation.
Whilst the estimates of random and oversaturation delays correspond approximately to true
traffic behaviour, they also serve to deter the signal optimiser from selecting green durations
that have little or no spare capacity. This is important, for example, where the green time on a
side road needs to be reduced to provide better co-ordination along a main arterial road; as side
road green is reduced, random-plus-oversaturation delay increases and should prevent the
optimiser from choosing unduly short green times.
A less simplified (and hence more accurate) random delay equation is used by default by all
newly-created TRANSYT files. The choice of random delay formula is selected in
Network options>Traffic Options>Advanced. However, the Random Delay Mode option, which is
set by default to the Complex formula can be reset to Simplified (TRANSYT 12) if there is a
requirement for backwards compatibility with older runs of TRANSYT.
The Complex formula is the recommended one the simplified formula will tend
to overestimate the random component of delay, particularly for links that are well
below capacity. When comparing signalised solutions produced by TRANSYT with
unsignalised solutions produced by ARCADY, the complex formula will also
produce answers that are more comparable.
Queue lengths are average values derived by the model from traffic counts taken (ideally) over a
number of days. Obviously traffic flows can vary from day-to-day and this will, in turn, lead to
variation in queue length from day-to-day. As a result, individual observations of queue lengths
on site on any one occasion may differ considerably from those predicted. Indeed, assuming
that the average flow used to model the junction was unbiased, predicted queues will be
exceeded by observed queues half the time. Therefore, if proper validation of the TRANSYT
model is required, the junction(s) operation will need to be observed on many occasions (at least
10) and the measured queue lengths averaged. Only then could the queue lengths predicted by
TRANSYT be compared with those found on-site.
25.3 Stops
TRANSYT calculates the total rate at which vehicles are forced to stop on a link as the sum of
uniform and random-plus-oversaturation stop rates. As for delay, the uniform component is
obtained from the cyclic flow profiles and the random-plus-oversaturation component is
calculated from simple equations.
All traffic which suffers uniform delay contributes to the uniform stop rate but traffic delayed by
only a few seconds will, in reality, merely slow down and not make a complete stop.
Consequently, a correction in TRANSYT includes a fractional stop for short delays; the fraction
depends on the length of the delay.
Cruise speeds on individual links are accounted for and the fractional stop is calculated according
to the estimated proportional loss of kinetic energy. Fractional stops, for traffic experiencing short
delays, and full stops, for traffic which is delayed sufficiently to come to a halt, are accumulated as
equivalent full stops to provide the uniform stop rate component for the link. Figure 25-2 shows
the way in which full and fractional stops are valued for inclusion in the Performance Index relative
to a standard full-stop from a cruise speed of 12m/sec (43km/h).
An estimate is made of the additional stops caused by random variations in traffic arrivals from
cycle to cycle and also caused by steadily increasing oversaturation queues on links where average
arrivals exceed capacity.
As discussed in section 25.2 the random-plus-oversaturation delay rate may be visualised as the
average number of PCUs in the queue at the start of the red period. On the assumption that all
such PCUs stop each time the signals become red, then the average number of stops per PCU
can be estimated by dividing the average start-of-red queue by the average number of PCUs
which discharge from the link during each green. This quotient is the average number of red
periods which each PCU must wait before crossing the stop line and thus equals the average
number of random-plus-oversaturation stops per PCU.
On links where traffic arrivals exceed or are near to capacity, long queues will form and the
average number of stops per PCU will be large. There is some evidence that, in such
circumstances, drivers well back from the stop line will move forward at only low speeds (10-15
km/h) when it is obvious that they will have to stop again. Hence, an arbitrary upper limit of 2
random-plus-oversaturation stops per PCU is imposed to avoid unrealistically large estimates of
the kinetic energy wasted by stops in long queues. As this upper limit is approached, the
number of stops per PCU is discounted to avoid discontinuities in the relationship between stops
and the random-plus-oversaturation delay. The random-plus-oversaturation stop rate is then
calculated as the product of flow on the link (PCU/hour) and the discounted average stops per
PCU.
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.
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.
The way the blocking back time is calculated depends on the traffic model used. The CTM
(cell-transmission model) can more easily identify when blocking occurs and will generally give
more accurate wasted green results than the PDM (platoon dispersion model).
When the PDM model is being used the program estimates the amount of blocking back during
effective green using a combination of the mean maximum queues, downstream queue lengths,
and the user-defined link Maximum Queue Storage value (see section 26.6.2). If the optional
maximum queue storage is provided by the user it is used, otherwise a TRANSYT estimate of
this value (previously known as Link Capacity) is used instead. The accuracy of the wasted
green times will be improved wherever the user-defined value is present.
The ARCADY and PICADY products are specialised tools recommended for the
evaluation and modelling of isolated unsignalised roundabouts and priority
junctions. Both ARCADY and PICADYs capabilities extend well beyond that of the
original two research reports, having been added to over many years. They are
easier to use than TRANSYT and offer a comprehensive set of design, modelling and
evaluation capabilities some of which are beyond that of TRANSYT, e.g. queue
variability, accident prediction. However, within the context of a network,
particularly a signalised one, the modelling of give-ways and roundabouts is best
done within TRANSYT, due to the existence of the determinable traffic patterns
within the network which can significantly affect junction performance.
At priority junctions a traffic stream that has right of way is considered to suffer no delay. It is
referred to as a controlling traffic stream or link. The rate at which traffic can enter from a
minor road that gives way depends on the controlling link flow which, in general, varies from
step to step during the cycle. TRANSYT calculates, during each time step, the maximum flow
which can leave the give-way traffic stream (or link) as a function of the flow on one or more
controlling links. This calculation produces the GO-profile for the give-way link. This profile is
then used in the same manner as that for a signal-controlled link to obtain delays, stops, and an
OUT-profile.
The same basic facility can be used to represent traffic on a traffic stream or link which,
although signal-controlled, must also give way to an opposing flow. Such situations occur
frequently at signalled junctions where offside traffic turns without a separate signal indication
(see section 17.14).
Give-way junctions (priority intersections) that have their performance affected by the presence
of nearby upstream signal controlled junctions, (due to give-way drivers knowledge of the signal
states, are also catered for within the give-way model. See section 17.16 on Indirect traffic
control.
1000
q
FR 2
Major road q
1 FL
800
q =q
1 2
Minor road
400
200
Figure 25-3 shows two examples of typical linear relationships between major (controlling) and
minor (give-way) traffic flows. Figure 25-4 gives the most basic TRANSYT representation of a
T-junction that is controlled by a priority rule. The junction is represented as a either a traffic
stream or link with an unrestricted flow or as a bottleneck both of which will give a continuous
green for main road traffic, thereby providing the necessary cyclic flow profiles to control minor
road give-way links.
Please note that when using the CTM traffic model, congested give-way situations can also be
taken account of. See section 24.2.4 for full details.
Give-way traffic streams (or links) are specified in the same general way as signal-controlled links
within TRANSYT, but with the addition of those parameters which determine their GO-profile.
Signalled Signalled
node node
It is assumed in TRANSYT that the maximum flow (F) from a give-way link through a flow (q) on a
single controlling (priority) link is given by the linear relationship:
F = F0 - A1q
where F0 is the maximum flow from the give-way link when the controlling flow is zero; A1 is a
constant. The user must specify F0 and A1.
F = F0 - A1q1 - A2q2
(i) all of the traffic gives way to both of the controlling links; e.g. a lane of right turners across
a two way road,
(ii) some of the traffic gives way to only one of the controlling links and some of the traffic
gives way to both of the controlling links; e.g. where there is a lane of mixed left and right
turners.
Thus, to cater for the various possible situations, it is necessary to specify the F0, A1, A2 values,
and also define the TRANSYT link or lane structure to model to take account of the fact that some
of the mixed traffic is opposed by one movement and some by two. Details of how to set up the
various movements and conflicts is described in chapter 17.6.
When a give-way is controlled by more than one controlling link, these links can be either
signalised or unsignalised - The TRANSYT model allows mixed types of opposing links as well as
allowing many more conflicts to be defined.
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,
F0 = 715 PCU/h
A1 = 0.22
These values are related to the following situation: give-way traffic is queueing in a lane of
width w = 3.65m (averaged over the last 20m of the approach), visibility for this give-way
traffic is V = 80m towards the controlling flow, and the width of the roadway occupied by the
controlling flow is W1 = 4.5m.
F0 changes by about +10 per cent per metre increase or decrease in w, and by about +1 per
cent per 10 metres increase or decrease in V. The slope (A1) varies similarly with w and V but
also varies inversely by about -10 per cent per metre change in W1.
Now, consider a give-way link on which the traffic is queueing in a single lane and must give
way to traffic flows approaching from two separate directions. An example of this is the
right-turning stream from the minor road in Figure 25-3. The give-way capacity is determined
by the flows (q1 and q2) on the two controlling links as follows:
F = F0 - A1q1 - A2q2
These values relate to site characteristics w and V as described above: w = 3.65m and V =
80m. They also relate to the total main road width (W2) occupied by both controlling flows,
where W2 = 9m. Coefficients F0, A1 and A2 vary by +10 per cent per +1m in w, and by +1
per cent per +10m in V. The slopes (A1 and A2) also vary inversely by about +5 per cent per
+1m in W2.
The above relationships apply only where give-way traffic forms one queue. Sometimes,
however, traffic on a give-way link will form two or more separate queues in adjacent lanes,
each lane giving way to the same controlling links. The coefficients F0, A1, A2 should then be
estimated for each lane individually and the overall link coefficient for use in TRANSYT obtained
by adding together the two or more corresponding lane coefficients. For example:
Sometimes give-way traffic in a single lane contains some vehicles which must give way to only
one controlling link flow and other vehicles which must give way to two such flows, as, for
example, a mixed give-way stream of left and right turn vehicles rather than separate turning
streams as in Figure 25-3. The user can allow for this in TRANSYT by modelling the mixed traffic
using two separate shared links which allows the correct give-way coefficients to be applied to
each shared link (hence movement) separately. This is the recommend method of modelling this
situation.
Alternatively (using a retained functionality from earlier TRANSYTs), the proportion of give-way
traffic which gives way to only the first controlling link flow can be specified ; the remaining
proportion of the traffic is assumed to give way to both controlling link flows.
The most recent versions of PICADY provides slope and intercept values as part of
its report. Flow-weighted averages of these values can be used as required in
TRANSYT or elsewhere.
These two parameters define the assumptions made by the traffic model of how traffic arrives
and queues at give-ways and stop lines. Full details of these two important modelling
parameters are in section 18.2.
This facility was initially developed for use in BUS TRANSYT (see section 25.7). The facility has
subsequently proved suitable for other purposes such as the production of timings for signalised
roundabouts.
The shared stop line facility allows up to seven separate classes of vehicles to be represented in
any one queueing situation where, in reality, the classes of vehicles are mixed together. The
classes need not be different types of vehicles but may consist of vehicles which, for example,
entered from different roads at the upstream intersection. There may also be separate classes for
buses or trams that follow particular routes and service different bus/tram stops. The user of the
program must decide how many classes of vehicles are necessary to represent the conditions
being studied. Each class of vehicle at a common stop line is represented by a separate link. For
vehicles in a given class at the shared stop line, TRANSYT calculates the delay for that class taking
into account delay caused by the interaction between all vehicles using the shared stop line. The
number of stops is also calculated. The procedure is as follows:
a) For each class of vehicle, the average arrival flow profiles (IN-profiles) are calculated
separately.
b) Vehicles from each class are discharged over the stop line at rates and times common
to all links sharing the stop line. Saturation flow across the stop line is divided between
the different classes of vehicles according to their arrival time at the stop line. This
means that the order in which the vehicles in the different classes join the queue is
preserved. A separate OUT-profile is calculated for each class of vehicles.
c) The rate at which uniform delay is incurred by each class of vehicle is calculated from
the average queue on the link in the normal way. The random-plus-oversaturation
delay rate is calculated initially as a total for all traffic sharing the stop line and is then
apportioned to each class in proportion to the flow in the class.
Links forming a shared stop line group are defined as one master or main link and up to six
other minor links. The grouping of these is done in the Links Data Screen (Outline:
Links>Link n>Is Minor Shared Link?). See Figure 25-5. The definition of which link in a
group is the master is arbitrary, and does not affect the calculations of queues, delays, etc.
It does have some effect on the output listing; this differing slightly between the master and
minor links in a group.
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.
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.
The effect of representing buses or trams separately from other traffic can be illustrated by an
example. Figure 25-6 is a time distance diagram showing a one-way progression between two
signals which are assumed to operate on a common fixed-time cycle. The movement of a platoon
of traffic is represented by the dotted band and a bus is shown crossing signal 1 in the centre of
the platoon. The cruise speed of the bus is less than the average platoon speed. There is a bus
stop between the signals. As a result of stopping, the bus arrives at signal 2 after the main
platoon. If the bus behaviour is not represented, the green period of signal 2 would be optimised
to give unimpeded progression to the platoon of other traffic and the bus would be delayed by the
red period. In Figure 25-6, the green period is offset to reduce the delay to the bus even though
the platoon of other traffic then suffers some delay.
In real traffic situations, the interactions between buses and other traffic are more complex than in
this simple example. For this reason, bus behaviour is modelled in TRANSYT using the shared stop
line facility, together with a special bus dispersion formula. This is used for both link and traffic
stream/lane network representations the difference being that the underlying structure is largely
hidden in the latter case.
The dispersion formula takes account of the variation in the journey times of buses along a link.
Bus journey times vary due to differences in their cruise speeds and in the time spent at bus
stops. The formula is a modified version of that for general traffic dispersion). For buses, the
dispersion coefficient is given by:
1
F
1 0.7b 0.15t
Time
Bus
Distance
SIGNAL 1
Green Red
SIGNAL 2
Red Green
Bus
A platoon
of traffic
Once delays and stops have been calculated separately for buses and for other (normal) traffic, by
using the shared stop line facility or traffic streams, total passenger delay can be estimated by
weighting the results for each class by using either link weighting factors (see section 26.1.3) or
special traffic stream weighting factors which are applied to either all traffic or to individual OD
Paths on each traffic stream (see section 26.1.3.1). Weightings can be applied proportional to an
assumed number of passengers. The optimising routine will then attempt to find signal settings
which minimise total passenger delay.
This method of optimising specifically to take account of the different behaviour of buses within the
network and their value in terms of passenger numbers, is likely to be most effective where bus
flow rates are relatively high (more than 10 to 20 buses per hour) and the average time spent at
bus stops is considerably less than the cycle time of the signals. When the method was tested in
Glasgow by TRL, it produced bus journey times which were, on average, 8 per cent less than those
measured with signals co-ordinated to minimise delay to vehicles rather than people. The dis-
benefits to other vehicles were too small to be measured reliably.
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.
Although initially the same by default, the bus and tram sets of coefficients are stored separately
and can therefore be changed independently (Outline: Network Options > Traffic Options >
Advanced > Bus/Tram Parameters). These coefficients are as follows:
Dispersion coefficient2 (which is the dispersion factor parameters for running time)
Acceleration (ms-2) (which is the assumed acceleration of the vehicle moving off from
rest)
Travel time coefficient1 (which is the dispersion factor parameters for stops)
Travel time coefficient2 (which is the dispersion factor parameters for running time)
Although individual traffic streams and links can use their own individual
dispersion settings, these are only available for Normal traffic. Only network-
wide settings are available for buses and trams.
To specify zero dispersion for buses or trams, the two user-definable dispersion coefficients
should be set to zero (Outline: Network Options > Traffic Options > Bus Parameters or >
Tram Parameters).
Full details of the equations used are given in TRL Laboratory Report LR666.
While shared stop lines allows you to separate classes of vehicles which are part of the same
queueing situation, the Traffic Type (Outline: Links > link n, or Traffic Streams > traffic stream
n) allows you to define what category of traffic is using these links or traffic streams (see Figure
25-7)
There are currently three traffic types Normal, Bus and Tram. The default Normal is the
name given to a link which is assumed will not be modelling buses or trams.
Traffic streams can be set to contain any combination of traffic types. In TRANSYT 15 links can
only contain one traffic type. Previous versions of TRANSYT did allow mixed links Please see
section 25.7.4.2 on what happens to imported files that have mixed links.
In place of the normal cruise speed / cruise time entry for the Source data of normal links and
traffic streams, the model requires for the representation of buses, the following information:
Specifying these parameters differs depending on whether or a link or traffic stream network
structure is being used These differences are described in sections 25.7.4.1 and 25.7.4.3.
The average free-running speed and average time stationary at bus/tram stops are set in the
Link Data (Outline: Links > Link n > Source n)
Bus links are marked in the output with B, and are separately totalled. The same applies
to trams, with the output marked with a T. Imported pedestrians links are marked with a
P.
Traditionally the traffic type of a link was defined by what traffic entered it from its
upstream sources, rather than defining the link itself. This method allowed some links to
be fed by more than one traffic type e.g. buses and normal traffic. This is no longer
permitted for new files in TRANSYT 15.
However, existing files that are imported will retain this method of defining link types. The
Link Traffic Type will be set to By Source (see Figure 25-9). If this value is changed to
a different setting, e.g. Normal, Bus or Tram it cannot then be reset back to By
Source as this option will have been removed.
If ALL sources for a link are BUSES or TRAMS, then the Dispersal Type for the link is best
set to DEFAULT simply to avoid any confusion over what dispersion is being modelled.
The Car Dispersal Coefficient will then appear as 35 but will be ignored by TRANSYT
because it only applies to normal traffic.
If the sources of a link are of different types, then the GUI will show a warning to check
that the user is aware of this mixed traffic.
The average Bus free-running speed is defined for each source of the traffic stream (Outline:
Traffic Stream Data > Sources > Source n).
The average time stationary at bus/tram stops is defined within the traffic stream data under
whichever traffic type it is, i.e. Bus and/or Tram (Outline: Traffic Streams > Traffic Stream n
> Buses/Trams).
A traffic stream containing any bus flow is identified as a bus traffic stream by the program
and all such traffic streams are marked on the output with B, and are separately totalled.
Mixed traffic is allowed, as the different traffic types are still kept separated within the
internal model. The same applies to trams.
For convenience, resultant traffic flows for each traffic type is shown, e.g. Source Normal
Flow, Bus Flow and Tram Flow. These are read-only resultant values since they are
derived from the OD Matrix used to define normal, bus and tram traffic flows.
The separate modelling of buses that stop and those that dont can easily
be accommodated, since most of the time they will be on different
TRANSYT paths. If buses on the exact same path have, say, 10 percent
or more that dont stop while the rest do it may be advisable to add an
extra path manually so that one path can represent stopping buses and
the other non-stopping buses.
You can, if you wish, create collections of traffic streams (or links) that are consistent with a
route through the network, and some tools within TRANSYT also generate collections for you
that are essentially routes through the network.
Collections consist of an ID, name, description and a list of existing items within the network.
If using this method, various options have provided to make it easy to select all the traffic
streams or links associated with a particular controller stream or the controller stream
associated with a particular link.
2. Using a combination of multiple-selection (e.g. via the network diagram) and the menu
item Tools>Collections>Store New Collection from currently selected Items
3. The menu item Tools>Collections>Calculate all routes in network, which will replace all
existing routes. The term route is used here as the collections generated are in fact
routes through the network. For example, collections that are also routes are a good way
to store Time Distance Diagrams.
3. Groups of traffic streams or links can be identified graphically within the network diagram
or filtered using the data grids.
4. Allow specific parts of a network to be associated with a specific feature, e.g. bus route,
congestion charge zone, controlled parking zone, etc.
5. The TRANSYT output calculates, for each collection, the same metrics as calculated for
the whole network, such as distance travelled, time spent, mean journey speed.
6. To provide aggregated results for each individual traffic node, controller stream, or
junction.
As many collections as required can be specified and a name assigned to each collection. The
name helps to identify the particular collection. You can add a list of road names, a description
of the start and end points, the number of the bus using that collection for example. The
description can also be left blank.
The Include In Report option can be used to present the collections results in the Collections
section of the TRANSYT Report (see below).
The collections do not have to make any logical sense as they can be any
combination of resultant links and controller streams, e.g. links and traffic streams
do not have to be contiguous, i.e. they dont have to be routes.
Items can also appear in more than one route and can also appear in a route more
than once.
The defining of collections has no effect on the calculations only on how the
results are collated.
For details of how to find the shortest route between two links or locations/traffic streams see
Section 23.4.
The original principles behind these estimates are explained in LR 934, (Robertson et al, 1980).
However, the latest equations and associated coefficients are now taken from the more up-to-
date DfT WebTag: TAG Unit 3.5: The Economy Objective Vehicle Operating Costs Fuel3
The equations used to estimate the fuel consumption at constant cruise speed, and that due to
stopping and starting, both depend upon the cruise speed for the link being considered. Figure
25-13 shows these relationships for the average UK car (as of March 2010). Details of the
revised fuel consumption equations and coefficients are in section 25.10.1
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.
Where:
3
WebTag is the Transport Analysis Guidance Website, provided by the UKs Department for Transport (2010) to provide
detailed guidance on the appraisal of transport projects and wider advice on scoping and carrying out transport studies.
TRANSYT, not only provides parameters for each of the vehicle categories (Outline: Network
Options > Fuel consumptions) for the base year (currently 2010), but also includes the
parameters for future years too. To use the internally stored parameters the Generate
Extrapolated Fuel Parameters button on the Common Data Screen must be used. Having
pressed the button, the year for which you wish the fuel parameters for, is requested. A new set
of Fuel Parameters will be added to the data file marked as having been Extracted (read-only),
with the Year set as the ID, and a Description (read-only) describing what base data the
extrapolation process made use of, and the WebTag publication of that data e.g. Base Year
2010, (WebTag, October 2013).
New files automatically start off with using the extrapolated fuel parameters for 2010. This set
of parameters can be replaced or added to, i.e. you can store more than one set of parameters
in the one file. The Use Fuel Parameter (Outline: Network Options > Fuel Consumption)
references the ID of the parameter set that will be used by TRANSYT to produce the results (see
Figure 25-12). Reference to a non-existent set of parameters will result in an error on the task
list. Generally, extrapolated parameters are available with TRANSYT for any future year within
the same range as published data is available in WebTag.
Alternatively the parameters can be entered directly (rather than extrapolated from the specified
year), therefore allowing updated or alternative values to be used if necessary. To use your own
values, simply add a new set of parameters via the Data Outline. The Extrapolated option will
be de-selected and read-only.
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.
The fuel used as a result of stops is formulated to take account of the wasted kinetic energy as a
consequence of having to slow down and accelerate back up to the cruise speed. This requires
the average weights of each of the seven categories (see Figure 25-12). Again, defaults are
provided, but your own values can be specified directly. If you wish to bypass the calculation
you can specify the E parameter directly by changing the ECoefficent Mode from ByWeights
to Custom for each vehicle category.
2
L = E.V
The calculations used in the fuel model always use traffic flows (and saturation flows) in PCU/hour.
If you enter flows in vehicles/hour the program uses the relevant vehicle mix and PCU factors to
calculate the flows in PCU/hour and provides the model with flows in PCU/hour.
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.
The assignment method performs a number of iterations of cost calculations and flow allocations
in order to find an equilibrium point for the traffic flows. During these iterations costs are
recalculated given the latest flows and traffic is transferred from path to path based on the
objective - which is to find the lowest cost. N.B. more than one run of TRANSYT is also run in
order to establish certain capacity values such as those at give-ways.
The cost function used makes use of traditional TRANSYT costs such as LR909. The costs are
derived from uncongested travel time, signal uniform delay and random plus oversaturated
delay (LR909). The delay calculations also take account of the TRANSYT traffic (model) options
Type of Vehicle-in-Service and Type of Random Parameter values. Weighting factors such as
delay weight multipliers and limit penalties such as excess degree of saturation penalties do
not affect the assignment process, as their purpose is to influence the signal timing optimiser.
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.
26 Optimisation in detail
As explained in section 3.4, co-ordination between signal-controlled intersections requires a
convention which relates the green periods of any one junction to those at the other junctions in
the network. In TRANSYT this is achieved by relating all stage change times to a common,
although arbitrary, zero time as shown earlier in Figure 3-8. The offset of an intersection is defined
as the start of stage 1 (based on the standard definition of stage start). In this way the offset may
be thought of as the start of the cycle for the controller stream concerned.
TRANSYT obtains its optimum settings by using the selected optimisation process. Whichever
optimisation technique is used, the optimisation process searches for a set of timings for the
network, which in its simplest case, minimise queues and delays. The optimiser alters both the
signal offsets, which affect the co-ordination between signals, and the durations of the individual
stage green times (the green split) at each junction.
Cycle time is not automatically considered by the signal optimisers, but TRANSYTs Cycle Time
Optimiser tool, can be used to evaluate a range of cycle times, from which the optimum can be
selected. The operation of, and output from the Cycle Time Optimiser is described in section
26.11 which also discusses issues related to the choice of cycle time.
The controller streams which are to be optimised are listed in the Optimisation Order (Outline:
Network Options > Optimisation Options > Advanced). If a controller stream is omitted from the
list its initial settings will not be altered. Thus, a network can be studied in which one or controller
streams within the network do not have their initial settings altered and act as a constraint on the
optimisation of the remaining controller streams. If the Auto Optimisation Order option is
enabled, all controller streams will automatically be included in this list.
Individual traffic streams, links and pedestrian crossings can also be excluded from the calculation
of the Performance Index by setting the modelling option Exclude from Results Calculation
(Outline: Links > Link n > Modelling or Outline: Traffic Stream > Traffic Stream n > Modelling or
Outline: Pedestrian Crossings > Pedestrian Crossing n > Modelling). A global setting to exclude all
pedestrian crossings from the results calculation (no matter what the above option is set to) is also
provided (Outline: Network Options > Traffic Options > Advanced).
Nv Np
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.
TRANSYT evaluates the P.I. in monetary terms ( sterling - by default) and the user is required to
select values Monetary Value of Delay and Monetary Value of 100 stops (in Network Options >
Economics), for the coefficients Wv and K that they judge are most appropriate. The values of Wv
and K appropriate for a traffic stream of average composition, at the time of release of the
product, are set as the defaults within the software. A lower valuation of delay (Wv) would be
more appropriate if the cost of non-working time was to be considered negligible. Clearly the
proportion of heavy goods vehicles and buses within a traffic stream may also affect the cost of
delay. Occasionally it may be advisable to use a traffic stream (or link) specific coefficient wi to
correct the estimates of the delay costs on traffic streams (or links) where, for example, there is a
high proportion of goods vehicles.
Similar arguments apply to the selection of a value for K. This value is for a standard full stop
from a cruise speed of 12 metres/sec; stops on links with other cruise speeds are automatically
increased or decreased in value by the TRANSYT program in proportion to the loss of kinetic
energy. The relationship between the K and Wv values has for many years been maintained at
the values developed for LR 888. This relationship between stops and delays has been dropped
in favour of a system that allows users to update their own values using the UK Governments
web-based Transport Analysis Guidance known as WebTag. As a consequence of the revised
method users will notice how little the cost of stops has become in relation to delay. This
reflects the far larger increases in the cost of peoples time compared with the costs associated
with stops. If it is thought that accidents are partly caused by vehicle stops or some cost is
placed on the nuisance value of a stop then the user might wish to increase K.
The signal optimisation procedure is affected only by the relative values of Wv and K and not by
their absolute values (assuming no other penalties have been applied). Further, where signals
are initially uncoordinated or badly co-ordinated, then both stops and delay can usually be
reduced by the TRANSYT optimisers. However, the balance between delay and stops that is
finally achieved by the signal optimiser is likely to be affected by the relative values chosen for W v
and K (Robertson et al, 1980, also describes how Wv and K may be chosen to minimise the overall
fuel consumption).
With the addition of the pedestrian behaviour (walk on red) model TRANSYT 15 now allows both
the explicit specification of pedestrian flows and an associated pedestrian delay cost. The
pedestrian monetary value of delay (WP), at the time of release of the product is to the same as
that for vehicular traffic.
The cost associated with pedestrian delay is very much dependant on the value of time you wish
to attribute to the pedestrians in your network relative to vehicular traffic. Due to the high
saturation flow values associated with crossings generally, the delays to pedestrians for all but the
busiest sites (in terms of pedestrians and vehicular traffic) is likely to be relatively small compared
with vehicular delays. However, it could be argued that even relatively modest delays to
pedestrians could encourage red-running of pedestrian signals, discourage walking generally
(which could lead to increased vehicular traffic) and also reduce the distances of journeys that
pedestrians are willing to make on foot. The type of pedestrians and the reasons for their
journeys may also be important factors in determining suitable values of their time, and hence the
delay costs you may wish to use.
Please note that there are also facilities to suspend the addition of pedestrian delay costs to the
overall P.I. either for individual pedestrian crossings or for all crossing in the network, giving you
control over which crossing costs influence the optimiser.
Stop and delay weightings are applied differently to depending on whether it is a link or a traffic
stream. To understand how weightings apply to traffic streams you should read both the text
below and the additional section 26.1.3.1.
The link stop weighting is a number representing the percentage of the stop valuation used when
calculating a links contribution to the Performance Index The stop valuation is set in Network
Options > Economics > Monetary Value of Stops (per 100 stops). The default stop weighting of
100% means that the specified cost will be used unchanged; a value of 0% will mean there will be
no stop costs incurred. Negative percentage weightings will cause the optimiser to seek settings
which increase stops on this link.
Similarly, the delay weighting is a number representing the percentage of the delay costs (uniform
+ random-plus-oversaturation) used when calculating the links contribution to the Performance
Index. The default delay weighting of 100% means the specified cost will be used unchanged; a
value of 0% will mean there will be no delay costs incurred. Negative percentage weightings will
cause the optimiser to seek settings which tending to increase delay on this link during
optimisation.
Stop and delay weightings allow the user to place a different emphasis on specific links. For
example, a large delay weighting factor on a particular link or series of links will ensure that the
optimiser will derive greater benefit from reducing delay on those links and thus delay will tend to
be reduced more on those links than others.
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.
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 those using a particular path on a
particular traffic stream.
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.
TRANSYT offers a choice of four Optimisation levels (Outline: Network Options > Optimisation
Options). These are:
Offsets only
Offsets and Green Splits (default)
Extended Offsets and green splits
Custom.
Of course, optimisation can also be switched off entirely, for when you simply wish to evaluate
an existing set of timings by switching off Enable Optimisation.
Selecting Offsets only allows TRANSYT to optimise only the offsets between controllers, i.e. the
start of stage 1 on each controller, without changing any of the red and green split times.
Selecting Offsets and green splits allows TRANSYT to vary green split times as well as the
offsets. Please note how green split optimisation cannot be select on its own. This is simply
because offset optimisation is inherent within any green split optimisation.
Extended - Offsets And Green Splits is provided specifically for use when using out links to
micro-simulation models (e.g. Aimsun, VISSIM). This option can however be used for any
situation. Runs take longer than usual, but may be slightly better as a result of using it. More
details available in section 26.5.2.
The combined effect of the network-level settings and the local setting determines what
optimisation occurs for each individual controller. This resultant effect of the two sets of
restrictions is reflected in each controllers own Optimisation Level This value is not editable
directly, as it simply reflects the various optimisation options that have been set.
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.
When allowed, TRANSYT is capable of optimising the durations of the greens for the various
signal stages, by shifting stage change times individually, in an attempt to reduce the network
Performance Index. Such re-allocation of green time is not allowed to break any constraints,
e.g. reducing any green time below its specified minimum value or taking it over its maximum
value.
The green times associated with a particular controller stream can also be locked while still
allowing the offset (start of stage 1) to be optimised for that controller. N.B. if all controller
streams were disallowed from optimising green split times this way, it would be equivalent to
setting the network-wide optimisation level to Offset only and de-selecting the Auto
Redistribute option.
If a controller streams green times are locked to an invalid set of timings, e.g. broken
intergreens, TRANSYT will fail to run.
Each controller stream can have a single stage constraint. The stage constraint locks the start,
end, or start and end of any stage on the controller containing the constraint to any stage on
another controller. Stage constraints are specified from within the controllers optimisation data
(Outline: Controller Streams > Controller Stream n > Optimisation) by selecting Enable Stage
Constraint.
Setting the Lock Type defines whether it is the start time, end time or start and end times of the
two referenced stages that will be fixed relative to each other. You then need to specify the
following data:
Library Stage to Lock, i.e. the stage you wish to lock on the current controller
Controller Stream to Lock to, i.e. the other controller you wish to lock the first one to
Library Stage to Lock to, i.e. the stage on the other controller you are locking the first
stage to
Optionally, you may also set the start and/or end of a stage to start earlier or later than that of the
other stage it is locked to. To do you this you will need to change the Locked Start Offset and/or
Locked End Offset from their default zero values. N.B. the offset is a positive offset for the
current stage relative to the other stage. For convenience the current start and end offsets are
reported. When manipulating timings manually and running evaluation runs of the model this
information is useful, as it allows you to see what offset data needs to be specified, in order to
retain the current offsets.
When setting a constraint, the current signal timings are likely to become invalid as they probably
wont satisfy the constraint that you have just set. If the optimisers Auto Redistribute option is
switched OFF, this will result in an error message on the Task List. To turn this into a warning
message (so that you can run TRANSYT) switch auto-distribute on. Auto Redistribute is required
as TRANSYTs optimiser must start with a valid set of timings, and it is the auto-redistribute
process that does this for you.
The setting of stage constraints influences the behaviour, and hence performance,
of the TRANSYT optimiser. Like any of the features that influence the behaviour
optimiser, such as delay weights and queue limits, the use of stage constraints will
result in an optimised solution that is further from the optimum solution in terms of
the P.I. that would be have been achieved without such constraints being applied.
Therefore, stage constraints should be used only where and when necessary.
Stage constraints can be used in combination with the controller grouping facility
but it is unlikely that the combined use will ever be needed in practice. Remember
that controller grouping will lock all of the stages on the grouped controllers
together and will also lock their green splits.
Constraints that form a loop (e.g. a stage on controller 1 locked to one on controller
2 and a stage on 2 locked to 3 and a stage on 3 locked to 1) should be avoided as
this is likely to lead to unpredictable results as it will severely restrict the optimisers
ability to find a good solution.
This example illustrates just one of the possible uses of a stage constraint between two controllers.
It is a pedestrian crossing controlled by one controller stream linked to the controller of the
upstream junction. The link is used in this case to ensure good coordination between the two,
typically to place the pedestrian green man at the quietest point in the signal cycle. In this case, i
has been deemed appropriate to allow the minor arm to be given a green while pedestrians are
also given a green. This means the movement of traffic from right to left on the main road is
disrupted by both conflicting movements simultaneously, thus avoiding having to stop twice.
A small offset of minus 4 seconds (Figure 26-8) has been set to ensure that the right-turning
traffic from the minor road does not hit a red signal as it approaches the crossing. This is
illustrated in Figure 26-9 using the network diagrams Traffic (Queues and Occupancy) overlay.
The choice of optimiser is basically a balance/choice between speed and performance. Hillclimb
is the fastest optimiser and although it generally gives good results, the other options can give
better ones. Simulated Annealing is the slowest but has the best performance, while Shotgun
Hillclimb is somewhere in the middle it terms of both speed and performance. The actual speed
and performance of shotgun hill-climb and Simulated Annealing is determined by a number of
user parameters and by the particular network being modelled. Because of this, it is inherently
difficult to predict the differences between optimisers in terms of speed and performance for a
particular network file.
First, TRANSYT calculates the Performance Index of the network for an initial set of signal timings
which has either been provided by the user or generated using either the auto-redistribute
calculation.
Any set of timings that do not violate any of the constraints, such as minimum green requirements
and are capable of handling the traffic are suitable. Next, the program alters the offset of one of
the signals by a predetermined incremental change (time units) and recalculates the P.I. of the
network. If the P.I. is reduced, the offset is altered successively in the same direction by the same
incremental change until a minimum value of the P.I. is obtained. If the initial change increases
the value of the P.I., the offset of the signal is altered in the opposite direction until the minimum
value is obtained.
The offset of each signal in turn is adjusted in this way; the signals are dealt with in the order
which is specified in the Optimisation Order (Outline: Network Options > Optimisation Options).
The process of optimising the offsets of each signal in turn is repeated a number of times, to
obtain the final signal settings.
It is a characteristic of hill climbing methods, such as the one just described, that the optimum
they find is not necessarily the best one; it may just be a local minimum. To reduce the
possibility of finding a poor local optimum, TRANSYT normally uses both large and small timing
alterations for the successive optimisation of each signal. The size and type of alterations are
defined using hill-climb increments. It is unusual to need or want to change these from their
defaults. Please read section 26.5.2 if you wish to know more about these.
The size of the incremental changes made to the controller stream timings by the hill-climb
process is determined by the Hill Climb Increments (Outline: Network Options > Optimisation
Options > Advanced). These are only editable if you have chosen the Custom Optimisation
Level in Optimisation Options.
The increments are listed as percentages of the cycle time. The number of increments must not
exceed 15. The increments must be less than 50 per cent. The program automatically
multiplies the percentages by the cycle time specified in Network Options > Network Timings. In
this way, a list of increments in 1-second units is obtained. To ensure that the increments list
can contain a 1-second increment for optimisation to the highest accuracy possible, a value of 1
input on Hill climb increments is interpreted as 1 second - not as a percentage.
The hill-climb process takes the first increment (in seconds) from the list and adjusts all stage
change times of the first controller stream on the optimisation order list for a local minimum of
the Performance Index. The second controller stream is then adjusted in the same way and so
on until the end of the list. At this point, the second increment is used and each controller
stream re-optimised in turn. The process ends when all controller streams have been
optimised for all increments. Green times are not affected by this offset optimisation. The
increments used are chosen to give a good global minimum in least computing time.
The recommended (and default) values for use on Hill climb increments for the optimisation
level, offsets only optimisation are:
15 40 15 40 15 1 1
The 15 per cent increments find an approximate local minimum of the Performance Index whilst
the 40 per cent increments avoid getting trapped in that minimum. The unity values, interpreted
as 1-second increments, give the final settings.
Green times can be optimised by selecting the optimisation Level Offsets And Green Splits
introducing 1 increments into the list, in which case each stage change time at a controller
stream is altered by one second at a time, whilst the remaining stage change times stay fixed.
This has the effect of varying the durations of the green times. The recommended (and default)
values for use on Hill climb increments for offsets and Green Splits optimisation are:
15 40 -1 15 40 1 -1 1
A fourth level of hill-climb optimisation (Extended - Offsets And Green Splits) is provided which
introduces larger negative increments into the list (see Figure 26-11)., in which case each stage
change time at a controller stream is altered by several seconds at a time, whilst the remaining
stage change times stay fixed, i.e. green split optimisation. There are more hill-climbing
increments demanded by this level of optimisation and this results in longer run times. The
default values for use on Hill climb increments for Extended - Offsets And Green Splits
optimisation are:
15 40 -1 15 40 1 -1 1 -15 -5 -1 15 1
TRANSYT uses the default values as described above, automatically choosing the relevant
sequence depending upon the selected level of optimisation chosen in Network Options >
Optimisation Options. However, if the optimisation level is set to Custom the sequence can
be edited directly by the user, to suit whatever circumstances they may have. As with the
default cases described above, the absence or presence of negative numbers in the custom list
of parameters dictates whether or not green times are optimised or not.
The Optimisation Steps, OUT Profile Accuracy parameters field enables the user to specify the
percentage changes in the OUT-profile below which downstream effects are ignored. The values
specified must lie within the range 0.05% to 100%. One such accuracy value must be specified
for each hill-climb increment.
The Accuracy Parameters are only editable if you have chosen the Custom Optimisation Level
in Optimisation Options.
It is not necessary to calculate results particularly accurately whilst the hill-climb increment is
large. Thus, small changes in flows on a traffic stream (or links) can be ignored until the signal
settings are close to optimum. This fact is reflected in the different default values that are set
for each of the different optimisation levels. Accuracy parameter values greater than 1% are not
recommended for the calculation of final signal settings. The initial signal settings are always
calculated with an accuracy parameter value of 0.05%
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.
The benefits are file-specific, so there is no guarantee that different starting points
will produce significantly better results. However, the process will often produce
significantly better results and it will never produce worse results.
For full details of how the hillclimb optimisation process works please read section 26.5.1 on the
Hillclimb Optimisation Process.
Choosing this option changes the main part of the TRANSYT optimisation process to use this
alternative optimisation technique as part of its overall optimisation process. It is a technique
which can be effective at finding an acceptable set of good signal timings within a reasonable
time period, rather than necessarily finding the best timings. The name comes from metallurgy,
in which by heating up a material and letting it cool down it allows more initial freedom of
changes within the structure (while it is hot).
Just like the other optimisation processes, TRANSYT calculates the Performance Index of the
network for an initial set of signal timings. Any set of timings that do not violate any of the
constraints, such as minimum green requirements and are capable of handling the traffic are
suitable.
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.
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.
You may have particular situations where it is necessary to prevent a queue from reaching back
from one junction to another, thereby blocking the upstream junction. This complex effect is not
4
The use of the above queue-reduction facility, and indeed the use of large weighting factors on
link delays or stops, may result in the optimiser being unable to find satisfactory signal settings.
Consequently the TRANSYT output should be examined most carefully, looking, for example, for
poor co-ordination which seems unreasonable; the cyclic flow pattern graphs (Section 19.4) can
help in this process. To improve the ability of the optimiser to find acceptable timings and thus
to lessen the need for such checking, the user is recommended to use a node optimisation
sequence which includes more than once any nodes connected by affected links. The nodes will
thus be listed once individually, again in pairs of adjacent nodes, and possibly in larger groups,
using the facility described in Section 26.5.1.
modelled when using the traditional platoon dispersion model in TRANSYT which assumes that all
vehicles queue at the stop line. (See section 24.2 on CTM for how to model blocking effects)
TRANSYT does, however estimate a mean maximum queue (PCU) for each link.
It is then optionally possible to specify a queue limit for selected traffic streams (or links) so that
the signal optimiser attempts to find settings which make it less likely that the mean maximum
queues will exceed the limit values. The limit is set in the Modelling tab of either the Links Data
screen or Traffic Stream Data screen (Outline: Traffic Streams > Traffic Stream n > Modelling) or
(Outline: Links > Link n > Modelling).
As part of the queue-limit process, TRANSYT computes an average excess queue (PCU) for
links where a queue limit has been specified. The mean maximum queue is checked against
the queue limit during each step of the typical cycle. During any step of the cycle when the
limit is exceeded, the excess queue is totalled and hence an average excess queue is computed
for the link. In this way, it is intended that the excess value will relate not only to the amount
by which the limit is exceeded (in PCU) but also to the duration of the blocking back.
It is then necessary to encourage the signal optimiser to avoid settings which cause any limit
queues to be exceeded. Thus, the average excess queues are weighted by a value specified by
the user as Excess Queue Penalty, and are added to the Performance Index.
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.
In order to assist in the identification of links which may have problems storing the number of
vehicles in the queue on that link TRANSYT estimates a maximum queue storage value for all links
in the network. N.B. previously known as Link Capacity. The calculation for vehicular links is as
follows:
maximum queue storage (PCU) = link length (m) x saturation flow (PCU/h)
5.75 x 1850
This assumes that each PCU in a queue occupies 5.75m along a lane having a standard saturation
flow of 1850 PCU/hour of green.
If the mean maximum queue exceeds the above maximum queue storage, this is indicated in the
output, e.g. the Link Results table is marked with a + symbol in the mean maximum queue
column to indicate a possible problem which the user is advised to check if the timings are to be
implemented in practice. The amount by which the MMQ value exceeds the mean queue storage
is also calculated.
For pedestrian crossings sides the maximum queue storage defaults to a value of 10 pedestrians
if it is not specified. This may equate to the typical storage available on a smallish central refuge.
For Traffic Streams the automatic calculation of maximum queue storage is different:
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.
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).
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.
(a) so that fixed relationships can be maintained between adjacent controller stream
Controller Streams are generally identified by positive numbers. However, in the Controller
Stream (Optimisation) List the number may be prefixed by a negative sign. In this case the
controller stream will be grouped with the next positive controller stream in the controller stream
list and the controller stream s in the group will be optimised together. For example in Figure
26-15 controller stream list of (1,-2, -3, 4, 5, 6, 7) will result in controller streams 2, 3 and 4
being grouped and optimised together.
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.
Choice of cycle time interacts with other fundamental decisions such as whether to divide the
signals in an area into two or more sub-areas within which different cycle times are used.
Multiple sub-areas may produce benefits by allowing signals to operate on shorter cycle times
than would be possible with the whole area on a common cycle time, but this may be at the
expense of a loss of co-ordination across sub-area boundaries. Further complications occur
when multiple cycling and repeated green possibilities are explored; for example, all signals in a
sub-area may be able to operate on a 70 second cycle, but a smaller Performance Index might
be possible by operating the sub-area on a 90 second cycle with several controller stream double
cycling.
In the absence of a satisfactory formal procedure for choosing cycle times, a considerable
amount of ingenuity can be exercised by the traffic engineer in choosing a combination of
sub-areas, cycle times, double cycling, repeated greens, and also of stage sequences. Using
TRANSYT to test a variety of options is likely to provide worthwhile improvements compared with
simply using a common cycle for all controller streams in an area; 10 per cent reductions in
delays and stops have been obtained.
As an additional aid in this difficult choice process, the Cycle Time Optimiser Tool
(Section 26.11) provides information for a wide range of cycle times; it shows a graph of the
Performance Index for the complete network against cycle time. Suitable cycle times for the
complete network are quickly discernible. Multiple cycling options can also be investigated using
this tool.
It is relevant to comment that when altering signal cycles (and green time durations) the
random-plus-oversaturation delay term (Section 25.2) has a most important part to play; the
main limitation when using shorter signal cycles is the increase to higher saturation of the green
times. This is reflected in an increase of random-plus-oversaturation delay with shorter cycle
times. It is also worth noting that networks with a high proportion of flared approaches (short
lanes) will also be seen to benefit from cycle times that allow flares to only just clear by the end
of their green. Longer cycle times will then increasingly reduce the efficiency of the flares
beyond this point. In some circumstances longer cycle times may also result in longer queues
which may then block upstream junctions, particularly when link/lane lengths are short, such as
those at signalised roundabouts.
The calculations are based on full runs of TRANSYT, i.e. all controller
streams, traffic streams, links and pedestrian crossings are assumed to
be part of the coordinated network. As a result, all but the smallest of
networks will take some time to run. To speed up analysis you can try
the following:
Dont use the default cycle time range set your own limits.
The Cycle Time Optimiser is opened by clicking the CYOP button located on the vertical toolbar.
The screen can be resized to whatever size you wish.
The program makes use of the currently selected TRANSYT file. The screen is split into three main
areas a Controller Stream Table on the left; the graph, and graph options bottom right.
The contents of the list of controllers is determined (filtered) by the Cycle Time Source. This is
set, by default, to network default, so that all controllers that are using the network cycle time will
be listed in the gird below.
The cycle time source list is populated with any controller stream that has its own manual cycle
time. Any controllers that also make use of that cycle time by referring it will also appear in the
filtered list of controllers below. The current cycle time of each controller is listed, and double-
clicking on that column of the grid for a specific controller will bring up the Data Editor so that you
can make changes if required.
The cycle time source determines which cycle time is going to be varied when plotting the Cycle
time graph.
The Controller Table indicates which controller streams are currently single, double, triple, or
quadruple cycled. The controller table can be hidden using the Hide button.
Pressing the Run Graph button creates a graph of Performance Index against a range of cycle
times. A full run of TRANSYT is carried out for every cycle time in order to produce the results.
Points are plotted for every chosen step (in seconds) within the chosen range.
Although the cycle time that is being varied may only affect a sub-set of
controllers in the network the whole network is still being run.
Using the dropdown list below the graph, the reported P.I. on the Y-axis can
either be set to display the Network P.I. or the Cycle Time Source P.I. The
graph will need to be re-run when this option is changed. When Network P.I. is
selected the graph will display the total P.I for the complete network. When
Cycle Time Source P.I. is selected the graph will show the P.I. of just the sub-set
of items whose cycle time is being changed. This allows you to investigate the
performance of each cycle time zone within your network.
The graph displays one or two sets of results. These sets of data are selected using the options
below the graph. A key can optionally be included on the graph using the Show key option.
The vertical bars show the P.I. values based on the proposed set of cycling options.
This data set also indicates the proportion of traffic streams or links exceeding the user-defined
degree of saturation threshold by colouring (in red) the same proportion of the length of the
vertical bars. The proportions not over-saturated are in green. All green indicates that the
whole network is within the defined DoS threshold.
The orange coloured line graph indicating the P.I. values of the current multiple cycling options.
The cycle time producing the lowest P.I. is indicated with a purple outline while the minimum
practical cycle time is indicated with a blue outline.
The Cycle Time Graph for the proposed multiple-cycling options shows the P.I. for a range of
cycle times assuming these suggested changes have been implemented for the complete range
of cycle times.
Having examined the graphs the required cycling changes to the existing TRANSYT file can be
made by selecting Use Proposed Cycling Options and pressing <OK>. For those controller
streams whose cycling status is changing, the relevant controller stream and traffic stream (or
link) data will be changed. It is usually wise to back up the original data file prior to
implementing cycling changes, in case the original proves more suitable.
Similarly, the minimum practical cycle time can also be implemented in the current file by
selecting Use Min Practical Cycle Time. This is applied only to the currently selected cycle time
source.
The Min Practical Cycle Time is defined as the lowest cycle time which will result in no traffic
streams (or links) exceeding the DoS threshold, i.e. an all green bar chart.
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.
The effect of multiple-cycling at particular controller streams can be tested using repeat runs of
TRANSYT with first single then double-cycling, etc. on the controller streams in question. This
process can also be carried out using the Cycle Time Optimiser.
The ability to set a controller to its own manual cycle time cannot be used
to help identify multiple cycling opportunities as you might expect, as
TRANSYT does not currently identify the fact that adjacent controllers are
running on multiples of each others cycle times, and therefore continues to
flatten the flow profiles between them. Therefore any benefits of such
coordination will not show up in the results. However, this does not negate
the usefulness of the Cycle Time Optimiser in optimising cycle times within
each sub-network and the Proposed settings can still be used to investigate
multi-cycling opportunities instead.
Multiple cycling can also be of use when attempting to model specific stages that come in only
every second, third, or fourth cycle (e.g. a pedestrian stage). In order to model this effect you will
of course need to double, triple or quadruple the cycling on all the controller streams which are
running during EVERY cycle while leaving those not coming in every cycle as single-cycled. Also
an alternative method using repeated greens See section 26.12.3.
The TRANSYT optimiser can be constrained to only allow equal length multiple cycling, e.g. the
cycle of a double-cycled controller stream is divided into two equal-length halves. There are
however, occasions where it is advantageous to allow the cycle to be split into two unequal
halves, for instance the traffic arriving at a junction may be split into a large platoon from the
main through movement at the previous junction followed later by a small platoon from the
turning movement. Unequal cycles can also be useful in tidal flow situations, where the platoon
from the dominant direction arrives in one half of the cycle, and the minor direction in the other.
Allowing unequal multiple-cycling gives the optimiser more flexibility to find good timings, and of
course does not stop the optimiser selecting identical timings for each set of repeated stages
within the cycle. The option that prevents unequal double-cycling is called Equal Length Multiple-
cycling, and is an option of each stage sequence (Outline: Controller Stream n> Stage Sequences
> Stage Sequence m).
TRANSYT re-creates these virtual repeat stages every time TRANSYT is run. On the Timings
Diagram the virtual stages are shown slightly greyed-out.
Virtual (non-base stages) can be converted into real stages via the Timings Diagram option
Tools > Convert All stages to base stages. This system allows the user to retain the original
stages, while still being able to see the newly created repeat stages, AND be able to edit the
repeat stages if and when needed.
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.
A vehicle flow scaling factor can be applied to all vehicular flows throughout the network (Outline:
Network Options > Traffic Options) or to individual links (but not Traffic Streams) using the Link
Sensitivity Multiplier (Outline: Links > Link n > Flows > Advanced).
A pedestrian flow scaling factor can be applied to all pedestrian flows throughout the network
(Outline: Network Options > Traffic Options).
The facility is useful in the study of the sensitivity of the optimum signal settings to changes in
flow. Flows for the whole network can be scaled within the range 10% to 500%. Flows for
individual links can be scaled within the range 5% to 2000%.
The global vehicle flow scaling factor and the local Link Sensitivity Multiplier effects are added
together.
A cruise time / cruise speed scaling factor can be applied to all traffic streams and links in the
network in Network Options > Traffic Options > Advanced or to individual traffic streams in Traffic
Steam > Modelling > Advanced. A cruise time / cruise speed scaling factor can also applied to
individual links in Links > Link n > Flows > Advanced.
The facility allows a signal plan to be tested for sensitivity to the accuracy of cruise time / cruise
speed data. Cruise times / speeds for the whole network and for individual traffic streams (or
links) can be scaled within the range 50 % to 200%.
The effect of any local cruise scaling factor and the global cruise scaling factor is combined.
The traffic stream (and link) stop and delay weightings specified affect the Performance Index
and signal timings. Switching off the Use Link Stop weightings and Use Link Delay
weightings options, located in Network Options > Traffic Options > Advanced can be used to
negate the effect of any weightings specified. Thus, it is possible to investigate the effects of
changes to these weightings upon the Performance Index and timings.
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.
27 Modelling Examples
This chapter describes an example file to assist users to familiarise themselves with all the
various key aspects of TRANSYT, and to give assurance that they are using the software in
correct way. The example described in this chapter makes use of the Platoon dispersion Model
(PDM). For CTM examples see chapter 28, Modelling Signalised Roundabouts.
The Chapter 28 examples also include the use of Local OD Matrices as well as a detailed
explanation of modelling signalised roundabouts.
The files supplied with the software may show some small differences with those
described here as a result of creating and running the files with a more recent
release of TRANSYT.
For further examples and documentation that may be added following product release, please
see the TRANSYT 15 section of our website at www.trlsoftware.co.uk. (Select Products from
the top menu and then select TRANSYT) The Knowledge Base button links to product-specific
articles and FAQs that may be of interest.
facilities in TRANSYT, while NOT suggesting normal values for any of the parameters used.
Explanation of certain aspects of the TRANSYT model, data and results is made while the data
file (containing results) is supplied with the software (TRL1 optimised LANES.T15, a link
equivalent file TRL1 optimised LINKS.T15 and also a variation using a Wide-Area OD
Matrix (TRL1 optimised LANES with ASSIGNMENT.T15 ).
Signal controlled junctions are controlled explicitly by the Controller Stream network diagram
object. There are four controller streams, numbered in an arbitrary manner, each controlling a
different junction, and one priority junction. The priority junction is modelled using a T-junction
Priority Object (see chapter 17).
Controller Streams 1 and 4 operate on a single cycle and nodes 2 and 3 are double cycled within
the common cycle time for the network of 92 seconds.
Controller Stream 1 has three stages: (1) Phases A (western arm) and C (eastern arm), (2)
Phases B (northern arm) and E (southern arm, nearside lane only straight ahead movement)
and (3) an early cut-off stage running phases E and D (southern arm, offside lane right-turn
movement)
Controller Stream 2 has three separate stages serving each of the three approaches one after the
other the western arm, then the northern arm and then the eastern arm. Each approach
receives two green periods per cycle as the controller stream is double-cycled.
Controller Stream 3 controls a signal-controlled pedestrian crossing and this has two stages: (1)
eastern arm vehicular traffic and (2) pedestrians in both directions. Pedestrians and vehicles alike
receive two green periods per cycle.
Controller Stream 2 has three separate stages serving each of the three approaches one after the
other the western arm, then the northern arm and then the eastern arm.
Controller Stream 4 has two stages: (1) Phases A (northern arm) and C (southern arm), (2) Phase
B (eastern arm)
The network contains one priority junction (Node P1) operating without signal control. There is no
need to use a P prefix, but doing so does help to quickly identify priority nodes within your
network. The north arm gives way to the controlling flow from the western arm.
In this example the approach on the main road from the right (C1/1) would be described as a Full
Blocking situation in PICADY. This means that traffic that a proportion of traffic going straight-on
will get blocked by right-turning traffic. However, in this case the flows that are turning are tiny so
the predicted queue at this point of the network is correspondingly very small.
At node 1, right-turning traffic from the South (Traffic Stream 17/2) is given a green signal during
stage 2 but must also give way to opposing flow (Traffic Stream 13/1) from the North. During
stage 3 an unopposed right-turn for Traffic Stream 17/2 traffic is provided.
An arm is a one-way section of the network between intersections. It acts like a container for
the traffic streams along that section of the network. Traffic Streams are the most important
modelling item. A separate traffic stream is used for each distinct queueing situation of interest,
as discussed in section 3.3.
There are approximately 21 arms, 23 traffic streams and a total of 27 lanes. Generally, the arms
have been numbered for convenience so that the first digits correspond to the node number which
the exit flow travels through and the last digit corresponds to the alignment of the link, numbering
in a clockwise direction starting from the West. The arms entering the priority junction have been
named such that they correspond to the naming convention of PICADY. This is purely down to
choice, and is not a requirement of the model. Furthermore, unrestricted arms that exist within
the network have been prefixed with x for easy identification. Again, this is not a necessary
convention.
Traffic Stream A1 is unrestricted, i.e. has no saturation flow as the traffic on it is not opposed to
anything and the nature of the road space does not change along its length. Cutting the road
space between nodes 1and 2 is necessary in order to provide the cyclic flow profile of the
controlling traffic flow at the priority junction where Arm B1 traffic must give way.
Traffic Stream C1 is modelled as a give-way as right-turning traffic gives way to traffic turning
from Arm A1 into the side road.
Traffic Streams 11/1, x13/1, A1/1, xB1/1, 21/1, x24/1 and x25/1 carry buses as well as normal
traffic (see Traffic Type). None of the buses stop. All other traffic streams carry just normal
traffic.
The buses share common stop lines with the other traffic. The queues on shared traffic streams
intermingle and, for example, buses may be delayed by a queue of other traffic which arrived
earlier and is sharing the stop line.
The pedestrian crossing at Node 3 is modelled using TRANSYTs new bi-directional pedestrian
crossing object (P1) and the new walk-on-red pedestrian behaviour model. In previous TRANSYT
you would have used two separate pedestrian links to model both directions of pedestrian flow
across the road.
Although this example uses the walk-on-red model, this can be easily switched off if you do not
want to model this behaviour.
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.
The approach from the East (Arm 25) flares out into two lanes (modelled using two Traffic
Streams 25ab/1 and 25ab/2). The nearside is for left turning traffic and the offside for straight
ahead traffic. Both these traffic streams are set to us a Flare traffic model in order to model any
blocking that may occur due to one or the other lanes filling up.
The inflows to each traffic stream and the total flows are shown on the diagram in units of
PCU/hour (or Veh/hour). Flow consistency is provided by the compulsory use of Local OD
Matrices. Discrepancies due to missing paths are quickly identified by examining the Resultant
Flows.
The flow allocation simplifies assigning traffic flows to traffic streams, links and pedestrian
crossings for small networks, such as this one, or for individual junctions. But there are some
situations that need to be dealt with carefully when automatically calculating all possible paths
through the network. In this example, several unrealistic paths are generated where traffic does
more than a complete circuit of the network. The option Allow Looped Paths on Arms is switched
off. This reduces the unrealistic paths to just one from location 4 to 5 travelling around the
whole network, rather than simply turning left. Therefore, this path has been disabled. The right
turn movement out of the side road has also been disabled as, in reality it does not exist and by
disabling it any traffic accidently put onto it will show up in the resultant flows tab.
Traffic travelling from location 5 to 6 can take one of two paths. For this example it has been
deemed more likely that one path will be more popular and hence the percentage allocation type
has been employed to favour the more southern path over the other one.
Although a single OD matrix has been used in this example, it can be more
appropriate in some circumstances to use more than one matrix if knowledge of the
traffic flows is limited to the individual junctions. This is because the accurate
assigning of traffic to the correct paths (location to location) through the network
requires knowledge of the paths traffic will take - something TRANSYT does not
provide. For networks larger than this, multiple matrices MUST be used.
Pedestrian crossing flows can only be allocated to the network using an OD Matrix. In this case it
uses the same one that is used for vehicular traffic. You can choose to use a separate one, but
there is no need.
The saturation flows for each stop line are shown in units of PCU/hour of green. Saturation flows
would normally be measured on-site or estimated from local knowledge of stop line width, gradient
or other site factors. If they are to be estimated, saturation flows can be calculated by specifying
the required data for each lane, and then letting TRANSYT sum the saturation flows of each lane to
give the overall traffic stream value.
The pedestrian saturation flow is calculated by the walk-on-red pedestrian behaviour model. If
this model is not used you would need to specify your own.
Traffic Stream lengths are shown in the data editor at TRANSYT Network > Traffic Stream n, in
this case, shown in the chosen units of metres. The lengths specified on external links are
arbitrary. Although not used in this example TRANSYT 15 now offers the option to let TRANSYT to
automatically calculate the lengths from the network diagram. Obviously, if you choose to do this
you will need to scale the diagram so that the lengths are realistic.
Average cruise speeds are set mainly in the range 30-36 km/h as seen in Traffic Stream n >
Sources > Source n, with some variations for longer, higher-speed links and lesser speeds on
bus-only links or links with turning traffic or parked vehicles.
Specific traffic stream weightings (on stops and delay) are used on certain links (see Traffic
Stream n > Modelling); PCU delay and stops weightings on bus links are set to 1000% (i.e. ten
times higher than normal); this corresponds to a factor of 20 per bus, since each bus is
represented by 2 PCUs (Outline: Traffic Stream n > Buses).
For each pedestrian crossing side (P1: sides 1 and 2) delay weightings are set to 100%.
Pedestrian delay weights allow you to change the relative cost between each crossing (and side of
crossing). The relative cost of pedestrian delay to vehicle delay is affected by not only these
delay weightings but also by the now separate global costs of delay for vehicles and pedestrians.
Although the default cost of pedestrian delay is set to the same as vehicles, you might want to
consider setting the pedestrian costs lower on the basis that a smaller proportion of pedestrians
than vehicle occupants could be assumed to be working. Average occupancy of vehicles by those
wishing to travel (i.e. exclude taxi drivers, but include their passengers) may be another factor
you might want to consider when setting costs. For pedestrian crossings there is no such thing as
stop costs, and hence no stop weightings.
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.
All plots on the graphs use full runs of TRANSYT to calculate the Performance Indices values, so
the values you see are the same as you would get if you implemented any of the particular cycle
times plotted, or any of your multiple-cycling choices.
N.B. to run the Cycle Time Optimiser, the optimisation option Auto-Redistribute must be
enabled.
27.2.13 Optimisation
A standard sequence of change increments is used to optimise offsets and green durations as
specified in the Network Options > Optimisation Options > Advanced. The Use Enhanced
Optimisation option and the Optimisation Level Extended Offsets and Green Splits could be
used to seek a further improvement in the final P.I. These options increase the time that
TRANSYT needs to run, but for a small network using the PDM model, the extra time needed
would be small. Alternatively the new Simulated Annealing and Shotgun Hillclimb methods could
be employed. Both of these take considerably longer to run, but both have a good chance of
improving the result.
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.
A number of graph plots of cyclic flow patterns (as described in section 19.4.1) are defined to
appear in the report. The graphs are laid out so that progressions can be followed on adjacent
diagrams.
To aid interpretation, some of the CFP graphs are shown here annotated to illustrate some of the
many characteristics which the graphs display.
Using the GoFlow and Outflow options, it can be seen that the peak outflow from the give-way (B1/1) is during low-
flow periods on the main controlling (A1/1). You will also notice the capacity of the give-way occasionally dips low
enough to affect the traffic on the give-way (see below). However, most of the queueing on the give-way is due to
random traffic behaviour predicted by TRANSYT.
Note although the saturation flow is shared between normal traffic and buses on links such as 11 and 21, the cyclic flow
profile of the traffic stream is a combined one, and hence shows the typical flat OUT-profile plateau.
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.
A link is a one-way traffic stream between intersections; a separate link is used for each distinct
queueing situation of interest, as discussed in section 3.4.
There are 27 links. Generally, the links are numbered for convenience so that the first digits
correspond to the node number which controls exit flow from the link and the last digit
corresponds to the alignment of the link, numbering in a clockwise direction from the West.
Furthermore, unrestricted links that exist in the network have been prefixed with x for easy
identification. Again, this is not a necessary convention.
Links 10, 1, 21, and 22 and x26 are bus-only links. Buses on link 1 share a common unrestricted
carriageway (see section 3.5.7) with the other traffic on link 2. These unrestricted links break the
carriageway (in modelling terms) between nodes 1 and 2, in order to provide the cyclic flow profile
of the controlling traffic flow at the priority junction where link 3 traffic must give way.
All the buses share common stop lines with the other traffic. The queues on shared links
intermingle and, for example, buses on a bus-only shared link may be delayed by a queue of
other traffic which arrived earlier and is sharing the stop line.
This variation of the original TRL1 small network example has several noticeable differences.
Firstly, there are six wide-area locations which provide the mechanism to feed traffic (assign)
onto the network from the wide-area OD matrix. As with the local OD matrices it can contain
bus and tram flows as well as normal traffic flows. Four local matrices provide the mechanism
to allocate traffic to each smaller area in two out of three cases (Local ODs 1 and 3) these are
single junctions, while Local OD 2 covers three junctions, and OD 4 covers the pedestrian
crossing This is NOT the only way of defining the local matrices it has been defined this way
to illustrate the flexibility of TRANSYT. You may, for example, have just one local matrix
covering more-or-less the complete network or one per junction. It all depends on what flow
data you have and how you wish to assign traffic to the network. Of course, the use of a wide-
area matrix is also purely optional.
You may also notice that there are two entry points to the network that are not included in the
wide-area these are the two locations associated with the pedestrian crossing at Traffic Node
3. Wide-area matrices are purely for use with the vehicular network so cannot be used to
populate the pedestrian flows of a Local OD Matrix.
Although the flows specified in the wide-area matrix are the same as those in the one local OD
matrix of the TRL1 example files. The wide-area assignment process has resulted in different
flows through each junction (local OD matrices). Therefore, TRANSYT results are also different.
However the general performance is similar due to the limited choice of routes that exist within
the network.
One significant change that makes life much easier in building a model is the direct
representation of lanes since the release of TRANSYT 14. It is still necessary to decide
how to model lanes in terms of streams, which is a similar concept to deciding which
lanes to model with a link.
To maintain backward compatibility with previous versions of TRANSYT which use a link
structure, an example of this is retained here. This allows users of TRANSYT 15 to
understand the way in which previous models have been built.
28.2 Introduction
At roundabouts, it is common practice to signalise one or more entry arms in an effort
to reduce delay and increase capacity. TRANSYT can model any roundabout, even
those with no signals (i.e. wholly priority). This is likely to be of values where such
roundabouts exist within a signalised network.
Signalling roundabouts to prevent queues blocking the junction was first studied in
1959 (Webster 1960), and the technique has been selectively applied over a range of
circumstances. Several authors have shown that the performance of three arm
roundabouts could be improved by traffic signals (Davies 1980, Flanagan 1983).
Other authors have studied junctions in London (Huddart 1983, Wright 1984) and
Sheffield (Bull 1983) with success. The Sheffield study used TRANSYT to provide
initial signal timings for a six arm junction. Hallworth (1992) examined the factors
that affect the capacity of signalised roundabouts using an example from Bradford (a
three-arm roundabout) and another from Bristol (a four arm roundabout). Following
on from Hallworths article, Jones (1992) examined the techniques used in the design
of signalised roundabouts and strategies for their control.
Roundabouts where most or all the entries are signal controlled will normally benefit
from coordination of the traffic signals. TRANSYT can be used to optimise the signal
timings in such cases. However, roundabouts do need to be considered carefully as
there will often be short internal circulating links that may be prone to filling up and
blocking back, and in general it will be important not to let too much traffic enter the
circulating section if locking up is to be avoided. By using various facilities available in
TRANSYT such as traffic stream (or link) weighting, the shared link facility, and queue
penalties, the program can be used to model traffic behaviour on the roundabout,
control queue lengths, and find signal timings such that queues do not form to block
upstream junctions. Using either of the models that are capable of modelling blocking
back situations (CTM or CPDM) can also assist in finding a good solution.
Note that many signal controlled roundabouts operate using MOVA or SCOOT. Indeed
the Highways Agency has issued a directive that MOVA shall be used on all trunk road
installations (see TD35/2006). However, in many cases it is important to understand
the way a roundabout operates before installing MOVA as SCOOT as it helps with
commissioning and validation of these systems, and should lead to a better solution.
Modelling such roundabouts in TRANSYT should help with understanding the operation
of a roundabout.
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.
The units used throughout the report are passenger car units (PCU) or
vehicles. The units selected should be set to reflect the data provided.
Switching units does not convert the data. Saturation flows are always
specified in PCU.
In networks which contain some short links (such as roundabouts), severe problems
can arise if traffic queues fill these links and block upstream junctions. If this blocking
continues for any significant time, the capacity of the network will fall dramatically
and traffic queues can block back and lock up around a roundabout. One of the most
important methods of keeping queues short is to keep the length of the red time
short. Achieving this is helped by having a short cycle time.
TRANSYT has a Cycle Time Optimiser that can be used to help select the lowest
possible cycle time at which the roundabout can operate satisfactorily The ability to
plot PI versus cycle time can be used to identify the best predicted cycle time by
making full runs on a range of cycle time. Using the default range is likely to result in
you making too many runs, many of which will be unnecessary. Therefore, it is
advisable that you change the range to something more suitable before running the
cycle time optimiser.
A traffic stream in TRANSYT can be used to represent one lane, or it can represent
more than one lane if queues form in equal lengths. Where queues do form in equal
lengths over two or more lanes, it is more accurate to represent them as a single
traffic stream. However, even if in theory queues could equalise across two or more
lanes, they will not always do so. In this situation, separate traffic streams should be
used and the proportion of traffic in each must be measured or estimated separately.
Unequal use of lanes will occur when for example lane markings direct vehicles
making a left turn into the nearside lane, and other traffic onto the offside lane, as
shown in Figure 28-1 (node 2). In this case, only one lane has been marked with a
left turn arrow because further downstream left turning traffic has only one exit lane.
This means that it is unlikely that any left turning traffic would be in the centre lane,
so unequal length queues could form and two separate traffic streams are required.
At nodes 1 and 3, the central circulating lanes have been marked for both straight
ahead and left turn traffic. It should be acceptable for left turning traffic to use the
middle lane because it exits onto a two lane road. As the centre lane is therefore
likely to contain both left turn and straight ahead traffic, it is possible that the queues
on all lanes will form at the same rate. Queues at the circulating stop line could
therefore form equally for all lanes and one traffic stream having two lanes, or even
three lanes in this case can be used (because straight-ahead traffic also has a choice
of lane to use).
This assumption is only valid, however, when the arriving flow is reasonably balanced
between the turning and the straight ahead movements. If, for example, during any
part of the cycle more than 67% of the flow arriving at the stop line wished to turn
left, then the queue in the left and centre lanes would be longer than that in the
offside (straight ahead only) lane. Equally, if in another part of the cycle less than
30% of the arriving traffic was turning left, then the queue in the left lane would be
smaller than the queue in the centre and outside lanes. In this situation, it would be
necessary to use one traffic stream for each lane.
[Skip to section 28.4.4 if you are not interested in using a network link structure.]
Prior to TRANSYT 14, the network structure consisted of links. A link-share (i.e. a
major link and set of associated minor links) is directly equivalent to a traffic stream.
Because there will be many existing TRANSYT network models, TRANSYT 15 retains
the ability to use links. When modelling roundabouts, there are some well-established
methods for using links. In order to contrast the use of links and traffic streams, both
are presented in the following two Figures (Figure 28-2 and Figure 28-4)
The link diagram in Figure 28-2 shows one main circulating link for node 1 (link 11),
and two main circulating links for node 2 (links 21 and 25) where left turn traffic uses
the nearside lane exclusively. The link structure for node 3 is similar to node 1, and
the link structure for node 4 is similar to node 2. For nodes 2 and 4, where there are
two main links for the circulating traffic, one main link is used to model traffic
continuing round the roundabout and through to the next downstream junction (e.g.
link 21), and a second main link models traffic that turns left, leaving the roundabout
prior to the downstream junction (e.g. link 25). Vehicles on these second links have a
free left turn before they reach the subsequent node (e.g. node 3 for link 25), and
are not considered again by TRANSYT.
It is also necessary to represent traffic on an entry arm by more than one link where
one lane is exclusively used for traffic making a specific movement. For example, the
two lane entry at node 2 is split into two links, the nearside lane is modelled using link
29 for traffic making an immediate left turn before node 3, and the offside lane is
modelled by link 20 for other traffic.
The use of shared links can improve the modelling of the junction significantly when
using the tradition link based modelling, especially if origin/destination flows are
available. More accuracy is obtained as more information is added to the TRANSYT
model (providing the information is good). See section 25.6 for a detailed description
of shared links.
TRANSYT models traffic flows in a series of time intervals or steps, and the number
of steps per second is chosen by the user, but would normally be 1 step per second.
When modelling a discharging queue, TRANSYT calculates the proportion of flow that
continues into each downstream link from its knowledge of the total flow on the
discharging link and the total flow required to enter the downstream link. For
example, if 75% of the upstream link flow continues into the downstream link (with
25% turning off), then for every step in the cycle, three quarters of the discharging
flow is taken as the entry flow into the downstream link. This is repeated for every
step in the cycle. The remaining flow is assumed to have turned out of the network
and is not considered further.
In many cases, this simplified model is not accurate, as in reality there will be
predominant movements across the roundabout. While on average one vehicle in four
will exit, it is probable that these turning vehicles will not be evenly distributed
throughout the cycle. It is not uncommon that for most of the cycle, there is little
traffic turning out at a given node, but then, for a short time, a platoon arrives of
which the majority exit.
Figure 28-1, Figure 28-2 and Figure 28-3 illustrate this for a simple four-arm
roundabout. Consider the flows arriving at the stop line X--X at node 2. Some
vehicles will have come from the entry at node 4, heading for node 3 (f 43), and will
exit before the stop line Y--Y at node 3. The remaining vehicles arriving at X--X will
have entered at node 1 (f13 and f14) and a proportion of this (f13) will also exit before
stop line Y--Y at node 3. The vehicles from nodes 4 and 1 enter the circulating
carriageway between nodes 1 and 2 at different times in the cycle and so will form
two distinct platoons at the stop line X--X. The platoons are illustrated in Figure 28-3
(a). Of the two platoons only the proportion which entered at node 1 and continuing
to node 4 (f14) will continue to stop line Y--Y. This traffic alone should flow into the
downstream link 32.
It is possible to model two entry flows separately using the shared link facility in
TRANSYT. If vehicles that are turning out of the roundabout before the next node
(f43) are modelled as a minor shared link, then the fixed proportional reduction for
circulating traffic can be applied to the newly entered traffic only (f13 and f14). This
will give significantly improved modelling compared to taking a (smaller) fixed
proportion of the total traffic on a single link between nodes 1 and 2.
This is further illustrated in Figure 28-3. The two platoons arriving at stop line X--X
are shown in graph (a), and their departure in graph (b). Graph (c) shows the flow
along links 31 (circulating flow) and 32 (entry flow), and it can be seen that flows f 13
and f43 have turned out of the roundabout. Graph (d) shows what would happen if
only one link was used to model all the flow between nodes 1 and 2 (f 13 + f14 + f43) -
TRANSYT simply reduces the flow leaving stop line X--X by the proportion which is
turning out of the roundabout. Hence arrivals downstream would be earlier in the
cycle than in real life. This can have a significant detrimental effect on the co-
ordination of the final signal timings, and wherever possible the shared link model
described above should be used. The shared link model does require complete
origin/destination flow data.
Use of the shared link facility is required to separate circulating traffic such that, on
each section of circulating carriageway, either:
The option (a) is described above - the equally acceptable alternative (b) is illustrated
in Example 2, section 28.6.
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.
From (Figure 28-4) it can be seen that each lane is modelled separately. However,
within that, traffic streams are used to model lanes that can be equally used. In this
example there are situations where all three lanes have been combined as one traffic
stream (e.g. Arm 11) and where they have been split with the two offside lanes as
one traffic stream and the nearside lane as another (e.g. traffic streams 21/1 and
21/2). Underneath the representation of lanes, the actual model still uses links.
Hence, the use of shared links to model the different origins and destinations within
each traffic stream is handled completely automatically in TRANSYT 15, and is largely
hidden from the user.
The model using links above (Figure 28-2) has not included the modelling of exit
traffic. However with the ever-improving graphical representation of the network the
modelling of exiting traffic has become more relevant. The modelling of exit traffic is
required if the OD matrix flow entry method is to be used. Exit arms are
demonstrated in Figure 28-4. As shown here, the exit arms allow pictorial
representation of the exiting. However, the model could be extended such that the
interaction between the exiting and circulating traffic can be modelled. A way of
doing this is given in (Figure 28-5). Arm 24a would have to be modelled with either
CPDM or CTM to ensure any blocking effects are included. However, there will be
occasions when the ability to model such situations in this way will be useful.
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 are common on roundabout entries where extra short lanes are
often added. In these situations, the saturation flow will start at a high level and then
drop after the flare has emptied. For example where two lanes flare to three, the
saturation flow would begin at a rate determined by the three lanes, but once the
three lanes have discharged, the rate would reduce to two lane saturation flow the
rate being determined by the fact the discharge is now from a two-lane queue.
Flares improve capacity and this can achieve this at shorter cycle times. TRANSYT
has a flared-approach model in which this stepped saturation flow which is described
in chapter 16 can be represented. The Flare traffic model may also be useful for
more explicit modelling of flares where the lanes at the stop line cater for different
movements or even controlled by different phases for example. The lanes are added
as they appear on street, connected as necessary to one-another as shown (e.g. Arm
42 representing the three lanes at the stop line, and Arm 42f representing the two
feeding lanes which will feed traffic into the flared are in (Figure 28-4). The blocking
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.
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.
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.
(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;
(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.
The use of a short cycle time is important, as described in section 28.4.1. The use of
the limit-queue facility and the effect of increased demand are discussed below.
If blocking cannot be removed entirely then a blocking model such as CTM, of course,
can be used to more accurately model the situation as it stands. By modelling the
blocking it will then be possible to minimise that blocking through optimisation of the
timings.
When choosing penalty values it should be remembered that the penalty is added to
the TRANSYT Performance Index only during those parts of the cycle when the limit
queue is exceeded. This is likely to be a small proportion of the cycle, but even this
short time can be critical when the link becomes full enough to affect the entry rate
from upstream links. Penalty factors should therefore be quite large, and values in
the range 30 to 60 /PCU-hour (see section 26.6.1) are often appropriate.
There may be occasions when, despite a high penalty, the limit queue on circulating
traffic streams or links is still exceeded. This can occur because in order to reduce
queues on a given traffic stream, TRANSYT must increase the green time for the stage
in which the circulating traffic streams receive green. This can only be at the expense
of entry traffic streams that run in the other stage, and some of these entry traffic
streams may then be forced into oversaturation. This oversaturation causes the
Performance Index to increase considerably, and the optimiser will attempt to reduce
the oversaturation to lower the Performance Index. This in turn will cause the limit
queue to be exceeded, and even a very high excess queue penalty may not keep the
queue below the limit in situations where entry traffic streams running in the other
stage have high degrees of oversaturation.
In such cases, a low delay weighting for oversaturated entry links which can usually
accommodate a long queue may help to force the critical circulating queue below the
desired limit, but the consequences of having an oversaturated traffic stream should
be carefully considered. Sparing use of the facility is also advisable. Use limit queues
only where they are needed to minimise unwanted queuing.
Note that with CTM there will be less need for setting limit queues as queues that
block back will be more naturally avoided. However, keeping queues below a certain
level is not guaranteed and limit queues will still be useful for this. It is more
important to ensure they are applied selectively and the consequences understood.
This can be achieved by making sure all entry arms are running at a high degree of
saturation (typically 85 to 95 percent). This will ensure that, even if demands double,
flows on circulating traffic streams cannot increase by more than about 10%
minimising the chances of blocking back and locking up the roundabout.
When modelling a normal urban network, TRANSYT will calculate the delay and
number of stops on each traffic streams in the network. It then multiplies these by
the value of delay and the cost of stops for each traffic streams to produce an overall
Performance Index for the optimiser to minimise. Unless specific action is taken to
weight particular approaches, this process treats them all as being equally important
and, for individual nodes, will distribute spare green time between approaches.
This low weighting factor may not be appropriate where the entry approach is a
motorway slip road, as it may be dangerous to form large queues which could block
back onto the motorway. In this situation, a larger weighting factor may be used or
perhaps no weighting factor at all. This means that at these nodes, queues are more
likely to form on the circulating traffic streams, which could lead to blocking back,
although the queues on the entry slip roads should not be excessive. Fortunately,
there is usually more room to store on the circulating traffic streams here because
they span the distance between the on and off-slips.
Once the signal timings have been found using the suggested weighting factors and
queue penalties etc, the network should be run with flows increased by about 10-15%
with the timings set to those found without the flow increase, to check the network
will continue to operate in higher than average flow conditions. The results should be
carefully checked to ensure queue lengths remain short on circulating and other
critical traffic streams, with degrees of saturation below 90% ideally, so that blocking
back to upstream nodes is unlikely to occur. To do this in TRANSYT, after completing
the optimisation runs, simply switch off optimisation, de-select the Auto Distribute,
and re run: this will run the file with the timings from the last run. Check the results
to see that oversaturation is stored on the entries rather than circulating traffic
streams.
This happens because the TRANSYT model assumes that vehicles form a vertical
queue at the stop line, rather than a linear queue back along a traffic stream. The
model can then release traffic into a blocked traffic stream believing that by the time
the traffic reaches the stop line, the (vertical) queue will have discharged. Thus, the
model does not correctly take account of the green starting wave and the physical
length of the queue.
When timings are implemented it is possible that some traffic stream can therefore be
poorly co-ordinated. In such situations signal timing offsets between adjacent signals
may have to be adjusted manually - This is a situation where the network diagram
timing wheels can be used effectively. The use of low limit-queue values and high
queue penalties will generally keep queues shorter and prevent this happening (see
section 28.7.4.1).
Where two nodes are particularly closely spaced and the signal timings need to be
fixed in relation to each other, it is possible to model both nodes as one junction (i.e.
as a single controller stream). The stage sequence, hence the offsets can then be
fixed, but the green times can still be optimised relative to the rest of the roundabout.
However, for most signalised roundabouts, the use of CTM should ensure that the
signal timings minimise problems with unsuitable offsets.
Individual platoons should be followed from entry traffic stream, round the
roundabout, to final exit to see where red signals are encountered. Graphs are also
useful to check traffic stream which require special co-ordination.
If using CTM the graphical options are different. However, studying them should
reveal information about queuing and discharge patterns. Additional graphical
options, such as the animation of the cell occupancy and the time-distance diagrams
will also aid in the understanding of how a roundabout might function in practise.
TRANSYT offers a number of animation options which can offer a better insight into
how the roundabout is operating. To understand better both how the roundabouts
described below have been modelled and to see the way they behave, it is worth
loading the sample data files and library files supplied with TRANSYT and experiment
with the available facilities.
The roundabout has been modelled using a mix of traffic models PDM, CTM and
Flare models in order to model the junction portrayed in the most accurate
manner.
The two flared approaches at nodes 3 and 5 have additional traffic streams to model
the additional short lanes, one traffic stream for the nearside flared area and a single
traffic stream for the remaining two lanes at the stop line. This is the recommended
method for modelling flared approaches with the Flare traffic model as it correctly
models lane use (provided the flows are allocated correctly).
The circulating arms are separated into traffic streams largely as determined purely
by the lane markings. In practice, it may prove necessary or desirable to separate
out lanes which also have other destinations, in addition to their common destination.
E.g. the two nearside lanes at node 6, where there is the common left-turn
movement, but also the separate straight-ahead movement in the middle lane. It
depends on the balance of turning movements and on the way the lanes are used in
practice. An example of this is given at node 3 where the four circulating lanes, which
could in theory be treated as one traffic stream, have been separate into two.
28.6.1.2 Flows
The Origin/Destination flow matrix is given in Table 28-1. This shows the flow from
each entry to each exit during the period under consideration.
To Node
1 2 3 4 5 6 Total
An OD Matrix has been used to assign flows to traffic streams. When using the tool it
is necessary to be careful that the flows allocated to traffic streams or lanes are
realistic, and to adjust them if they are not.
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.
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.
Please note that because some graphing facilities require multiple runs of TRANSYT,
such runs may be quite prolonged, but this depends largely on the size of the
network, the chosen level of optimisation, and the traffic models chosen.
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.
that the MMQ value is an average and is therefore exceeded approximately half of the
time.
The motorway roundabout example described above has been modelled using
primarily the Cell-Transmission Model (CTM). The flared approaches are modelled
explicitly, using the Flare traffic model - due to this models ability to take account
of blocking back into the feeding narrower approaches to the roundabout and take
account of random effects. This involves using a bottleneck traffic stream upstream
of the flared area that feeds two traffic streams representing the lanes at the stop line
(see Figure 28-7). This is more accurate than using the quick flare feature (as used
in previous versions of TRANSYT) as it can model the effects of having separate
movements at the stop line (and, although not a feature in this example, can also
model situations where the lanes are separately signalled).
Exit arms must either have the restricted flow option turned off, and optionally exit
arms can be removed from the performance index calculation altogether, although
their contribution to it should be minimal with the restricted flow option turned off.
At the entry on node 3 there are two lanes on the approach and a third short lane at
the stop line. This has been modelled with one two-lane bottleneck arm (Arm 30f)
with the restricted flow option turned off, feeding both a two-lane traffic stream
(30/2) and the nearside flared area (30/1) at the stop line. The length of the short
lanes is crucial if the capacity and characteristics of the flare are to be modelled
accurately. N.B. the three lanes at the stop line could have been modelled as single
stream with a three-lane saturation flow since each adjacent lane shares a common
movement, but for this example it is thought (due to local knowledge of the junction)
that queues will not be evenly distributed as most left turns will use the nearside lane.
Where two or more lanes share a destination, but also have a non-common
movement, the Allocation Mode in the OD table can be changed to even out the flows
to achieve the expected or observed queuing behaviour.
There are two 200 metre internal traffic streams where platoon dispersion could be
noticeable. The extent to which this matters or not will depend on how the queues
form and discharge. If it matters and these longer traffic streams (or links) are
unlikely to block back these can be modelled as PDM traffic streams (as is the case in
this example). The ability to mix traffic models within the same network is new to
TRANSYT 14. If blocking was evident/predicted it would be best to model them using
CTM.
The roundabout is triangular in shape (see Figure 28-12) with four main junctions,
plus a signalised pedestrian crossing on the exit to the north. The longest circulating
link is 150 metres and the shortest just 40 metres.
The diagram in Figure 28-13 and the TRANSYT input data (see TRANSYT file TRL4 -
Walton Street - AM peak.t14) show how the roundabout has been modelled. A Local
OD Matrix has been used to input the flows. In all cases apart from one, each lane
has been modelled as a separate traffic stream. The exception is Arm 31, where two
lanes have been modelled as one traffic stream. Here, most of the traffic is exiting
towards O-D 4 to the west, where there are in fact two lanes, so both lanes on Arm
31 are equally used. As with all the exits, there is no need to model separate lanes
(unless they are internal to a larger network) as long as they are modelled without
any exit restrictions.
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).
The main consideration is to keep the circulating links free from blocking-back.
Achieving the lowest Performance Index is of secondary importance. Therefore, the
choice of cycle time depends on the ease with which queues on the circulating traffic
streams can be kept under control, particularly on the critical lanes (Arm 21 stream 1,
and to a lesser extent Arm 31). In particular, this depends on the co-ordination
between nodes 1 and 2 and 2 and 3. Fortunately, there is only one platoon of any
importance between nodes 2 and 3 and it contains the traffic entering from link 25,
most of which crosses the stop line at node 3 en route to node 4.
A compromise must be made when choosing the cycle time between presenting traffic
with short reds (by keeping the cycle time short) and keeping the proportion of lost-
time in the cycle low (by keeping the cycle time long). In this case (and for most
signalised roundabouts for that matter), the balance will be in favour of short reds
(hence a short cycle time). The cycle time of 70 seconds was used as this is short
enough and the entries were oversaturated where necessary. All the internal links are
under-saturated with queue lengths being within the space available
The queue length on arm 21, stream 1 is arguably the most important issue on this
roundabout under the modelled conditions. To explore possible ways of minimising
any problems, the X-Y graph plotting facility could be used. For example, the effects
of alternative cycle times could be tested by plotting cycle time versus queue length
on traffic stream 21.
The output from a TRANSYT run with a cycle time of 70 seconds is given in the
TRANSYT file TRL4 - Walton Street.t14. Studying the degree-of-saturation on each
traffic stream shows that the aim of giving spare green to circulating traffic streams
has been achieved. If any internal traffic streams had been over-saturated it would
have been necessary to put this oversaturation onto the entries so that the amount of
traffic entering the roundabout is restricted, thus reducing the possibility of blocking
back.
For these predictions to depict accurately on-street behaviour, the simulation time
should equal the length of time over which the flow conditions have been averaged.
In this case, the flows are averaged over one hour, so the simulation time is 60
minutes.
The circulating lanes for node 3 (arm 31) also need to be well coordinated if queues
are to remain under control. The graphs for traffic stream 31 show the large platoon
made up of traffic entering the roundabout from arm 20. With just the one platoon,
good co-ordination between node 3 and the upstream node (node 2) is easily
achieved. Hence, queue lengths are comparatively short. However, a small error in,
say, cruise speed, could result in some of the on-street platoon being stopped and it
would not take much of an error to give rise to large on-street queues. This
highlights the importance of correct information for critical nodes.
For the remainder of the roundabout, the graphical output shows that it has been
possible to co-ordinate well for all the platoons around the roundabout. On Arm 31,
good co-ordination plays a major role in keeping the queues on circulating links short.
To check that the gyratory continued to function without locking up under conditions
of higher than average flow, the final signal plan was tested with flows increased by
10 per cent of their modelled values. Under these circumstances, the increase in
circulating traffic was small, but, as would be expected, the queues predicted for
entry traffic stream 20 and 27 were large. This was tolerable at this roundabout since
no significant hazard was caused by large queues on these two approaches, and this
is preferable to the roundabout blocking up, possibly reducing capacity to a fraction of
that expected.
On the oversaturated links, the flow into the roundabout was controlled by the green-
time. If the green-time had been too long, too much traffic would have entered the
roundabout, probably leading to locking-up.
28.8 Recommendations
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.
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.
Use the Flare traffic model to model flared approaches, but watch out for
modelling inaccuracies.
Use the Flare traffic model on traffic streams to model lane-gains that occur
well back from the stop line, i.e. extra-long flared sections.
Make use of the TRANSYT cyclic flow pattern (CFP) graphs, queue graphs, time
distance diagrams, and the queue analysis features of the network diagram to
check co-ordination and queueing behaviour.
Compare flow patterns, degrees of saturation and cyclic flow patterns with the
on-street behaviour (and re-model the junction if necessary).
29 Definitions / Glossary
29.1 TRANSYT GUI Terms
Data Item
Every TRANSYT data file is made up of Data Items, most of which are shown as
entries in the Data Outline screen. Data Item is a generic term meaning any of the
various 'objects' used in TRANSYT. Total Flow is an example of a data item, as is
Node 1. Most data items belong to a 'parent' data item for example, Sources may
contain several data items such as Source 1 and Source 2. Data items also include
general areas such as Traffic and File Description.
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 Outline
A screen that shows the current data file in outline form, with an entry for each data
item, and allows the adding/deleting of data items. See Data Outline for details.
Library File
A TRANSYT file which has been saved for future use as some form of template.
Library files have the same file extension as ordinary TRANSYT 15 files, but are stored
in a special folder to differentiate/filter them from ordinary TRANSYT files. Library
files can be selected and merged into an existing network from within the network
diagram. Several Library building block files are supplied with TRANSYT. See
Library Files for more details.
LTS
An abbreviation for the phrase Link and/or Traffic Stream. Occasionally used as
short-hand in both TRANSYT and the User Guide.
Padlock
This is a mechanism that allows specific screens to be locked to specific types of data
and/or specific items of data while navigating around the network.
Stage Library
This is a mechanism that allows multiple stage definitions to be stored within the one
TRANSYT file for convenience. It allows the user to quickly swap between different
possible solutions. Multiple stage sequences can also be stored for convenience.
Task List
A screen that shows any warnings and/or errors detected in the current data file. See
section 7.7 for more details.
TS
An abbreviation for Traffic Stream. Occasionally used as short-hand in both
TRANSYT and the User Guide.
A1 and A2 coefficients
No longer used in TRANSYT. See Slope coefficient instead.
Analysis Set
An analysis set is data within a single TRANSYT file which contains signal plan (+
other relevant signal related data) for a single network. Several analysis sets can be
stored in a TRANSYT file. Analysis sets also allow different signal information to be
associated with the different demand sets, e.g. different signal timings for am and pm
peak periods.
Arm
A TRANSYT Arm is a one-way section of the network. An Arm consists of one or more
traffic streams and one or more lanes. An arm usually stretches from one junction (or
modelling feature) to the next. The grouping of traffic steams and lanes within an
Arm allows easy identification of these components of the network as well as easy
manipulation of them within the network diagram.
Blackout Time
This is the blackout period used at some signalled pedestrian crossings (e.g. Pelicans).
This value is used to calculate the effective green time for pedestrians for use by the
pedestrian behaviour model. It extends the end of the effective green period.
Bottleneck
A bottleneck is a LTS with 100% green. It is modelled as an unsignalled link with a
Restricted Flow. The facility can be used to model links which have reduced
saturation flow along their length or at a particular point. They can be used to
represent the controlling flows at a priority junction since they have no signals and
hence have 100% green, but often a fully unrestricted link or traffic stream will be
more appropriate.
Bus TRANSYT
This is a method of optimising the signals in a network to favour buses.
Bus link
This is a special type of link used to model buses. For buses on such links the user
must specify the average free-running speed and the average time stationary at bus
stops. The performance of buses is given separate consideration in the output.
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.
(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.
Controller Stream
The TRANSYT controller stream contains all the signal control data associated with the
junction (or part thereof) it is controlling. The controller stream is a replacement for
the TRANSYT 13 signal node which no longer exists in TRANSYT 15. It is equivalent
to a single stage stream, within a traffic controller.
Cruise time
This is the average time it takes for a vehicle to progress down a link.
Demand Set
Several sets of traffic flows can be stored in TRANSYT, and then combined as needed
when the file is run. Each set of flows is a demand set. A typical use is to store flows
for morning and evening peak periods separately and then select the desired set to
run. Demand sets can be combined to model e.g. base flows plus development flows,
which are stored separately.
(Queueing) Delay
This is delay incurred by vehicles on a traffic stream (or link) as a result of them
having to queue up and stop because of the signals at the junction at the downstream
end of the traffic stream (or link), or because of having to give-way at a priority
junction.
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.
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.
Flared approach
This is an approach which flares out towards the stop line to provide an extra short
bay or bays (or pockets) - Now modelled in TRANSYT using the CPDM model.
Give-way bottleneck
A give-way traffic stream (or link) that operates under two different conditions as a
standard give-way AND also operates during a period of the cycle where the opposed
traffic is only restricted by a (usually higher) saturation flow, such as when opposed
traffic technically gives way but it knows that the opposing traffic is not present, due,
say, to the presence of nearby upstream traffic signals which are on red. Give-way
bottlenecks are modelled as a give-way with a restricted flow (i.e. has a separate
saturation flow)
Give-way link
A link that must give way to another link, link share, or links which have priority over
it. It can be at a priority intersection or a signalised intersection.
GO-profile
The GO-profile is the cyclic pattern of traffic that would leave the stop line if there was
enough traffic to saturate the green.
Graph analyser
The part of the GUI program which plots a variety of pre-defined graphs, such as CFP,
Queue and P.I.-versus-offset graphs that can aid in visualising these aspects of link
performance.
HDV
Heavy-duty-vehicle. This term is used in the vehicle composition for the exhaust
emissions model.
Hill climb
One of TRANSYTs signal optimisation processes.
(Phase) Intergreen
A phase intergreen is the length of time (in seconds) that is the minimum between
the end of one conflicting phase and the start of another, defined mainly for safety
reasons. The Intergreen Matrix specifies the intergreen between each conflicting pair
of phases. N.B. now that phases are specified directly in TRANSYT, the TRANSYT-
specific term Link intergreen is no longer used.
Initial offset
The offset from the arbitrary starting time of the start of stage 1. Unlike previous
versions of TRANSYT, initial offsets are now only set by dragging the timings (using
the timings Diagram) to the required starting point. The no longer necessary Initial
Offset data item has been removed.
Interstage
The interstage is defined as starting from the termination of the first green in a stage
(which also signals the end of the stage) to the commencement of the last green
starting in the next stage.
IN-profile
The IN-profile is the cyclic pattern of traffic which would arrive at the stop line at the
downstream end of the link if the traffic were not impeded by signals at the stop line.
Lane
A lane is used to define in the model, the physical number of lanes that are on-street.
As a result generally, there will one TRANSYT lane for every real lane. One or more
lanes are always part of a traffic stream. Most of the modelling data is associated
with traffic stream and not the lane. In a similar way that link shares are used,
TRANSYT traffic streams represent the modelling situation for lanes. See traffic
streams for more information on this. The use of lanes is not compulsory as TRANSYT
allows a link structure to be used instead, and TRANSYT will allow a mix of links and
lanes to be used, with defined restrictions only at the boundaries between the lane
model parts and the link model parts of the network.
Late Release
An arrangement of stages whereby the phase for opposing traffic starts after that for
the opposed traffic. In other words, opposed traffic initially gets a clear run, but later
on has to give way to oncoming traffic.
Level of Service
A subjective description of traffic performance measured at intersections. It indicates
the quality of the service afforded by any junction. TRANSYT uses the Level of
Service thresholds from the US Highway Capacity Manual 2000.
Link
A link is a one-way traffic stream between junctions. A separate link is used for each
distinct queueing situation. Thus, for example, two straight ahead lanes can form
part of the same link providing traffic queues equally in them. (This can only occur if
a movement is shared, and the exit(s) are largely unrestricted).
Link Share
This is a collection of links (one or more minor and one major) which have been
defined as sharing a combined saturation flow. Although this particular term is new
to TRANSYT 14, the concept of the shared link system is not. The term is used
wherever reference to a particular link share is required; such when defining the
controlling type of a conflict.
(Local) Location
A traffic entry and exit point which acts as both the origin and destination for flows
defined in a Local OD Matrix. At least two locations will normally be required.
(WIDE-AREA) Location
A traffic entry point which acts as the origin for flows defined in a WIDE-AREA OD
Matrix using the WIDE-AREA Assignment Tool. At least two WIDE-AREA locations will
normally be required.
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.
Network
A network is a collection of links, traffic streams, lanes and controller streams
modelled within TRANSYT.
Timing Wheel
This is a network diagram item that displays stage timings for the controller stream
it belongs to. It allows offsets and stage times to be edited directly from within the
network diagram. Optionally, cycle split times can also be displayed.
(Traffic) Node
This is a TRANSYT graphical representation of an intersection. In modelling terms it
less relevant in TRANSYT 15 than in versions prior to TRANSYT 14. Its main use is
to assist in identifying and automatically disabling paths through the network.
They are also useful in identifying the physical junction that traffic passes through,
allowing the junction to be manipulated more easily in the network diagram, and
provides a mechanism to get TRANSYT to produce results for each junction.
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.
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:
For the purposes of modelling pedestrians they too can be given a PCU value.
(Pedestrians never mix with any other type of traffic so there is no need to assign a
value relative to vehicle types etc.)
Path
This is a form of continuous route. A TRANSYT Path is a defined path, in terms of a
specific sequence of underlying links, between an OD pair (i.e. between one origin
Location and one destination Location) within a section of the network relating to a
particular OD Matrix. It therefore contains only underlying links which are consistent,
i.e. each link is downstream of the previous link.
Path Segment
Part of the underlying network structure created when there are traffic streams using
in a network. None of the path segment data is editable, or of any particular value to
users of TRANSYT. Path segment results can be useful at times and can be enabled
via TRANSYT Network > Options > Calculate results for path segments.
PCU length
This is the amount of space each PCU takes up on average in a single stationary
queue, i.e. front bumper to front bumper distance. It is a global user-defined value
used by TRANSYT to estimate the maximum number of PCUs that could fit within a
traffic stream, when this information is not provided by the user. It is not used for
links.
Pedestrian Link
Link Sources (upstream links) can be defined as pedestrian only links in TRANSYT.
These links are treated more-or-less the same as normal traffic links except that
they can be excluded from contributing to the Performance Index calculations. They
are now obsolete in TRANSYT 15 - See Pedestrian Crossing Object.
Performance Index
This value represents the overall costs incurred by vehicles on traffic stream and links.
The costs are made up of queue and stop costs, plus any penalty costs, such as queue
limit or DoS penalties.
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.
*Platoon dispersion
TRANSYT data inputs a single cruise speed or cruise time for traffic travelling along a
traffic stream (or link). In reality, some traffic travels faster, some slower, than this
average. To take account of this, the TRANSYT model takes flow entering a traffic
stream (or link) and disperses the platoon as it travels down the traffic stream. This
models the variation in vehicle cruise speeds as they progress down the traffic
stream.
Priority Object
A priority object is a TRANSYT data item that stores the geometric properties of either
a priority T-junction, Crossroad or a Roundabout.
Queues
Queues are streams of stationary traffic at a stop line or other constriction, such as a
give-way line or bottleneck.
QUEPROB
A component of TRANSYT GUI (previously an independent supplementary program)
that estimates the average number of vehicles able to use a flare during each green.
It is not needed if using the TRANSYT Flare model instead of quick flares.
Random Parameter
This is a modelling coefficient that relates to the calculation of vehicle delay. The
term defines the randomness of the queueing situation on a traffic stream (or link).
In TRANSYT this item is often set to 0.5 (partly random) for signalised networks and
to 1.0 (fully random) for unsignalised junctions, although there is scope to set it
directly.
Repeated greens
This is the situation where one (or more) stages receive more than one green during
any one cycle.
RFC
Ratio of demand flow to capacity (see also Degree of Saturation).
Route
A user-defined subset of the links within the network. Unlike Paths, Links within a
route can be duplicated and do not adhere to any ordering rules.
RTIA
Road traffic impact assessment
Saturation flow
This is the maximum rate of discharge from a queue when the traffic signal is green.
It can be obtained by measurement or calculation based on stop line width and other
site factors. (See RR 67)
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 Phase
See Phase definition. This is the direct equivalent in TRANSYT. Also see TRANSYTs
Signal Phase 2.
Signal Phase 2
A second signal phase can be defined. This allows a particular traffic stream to be
controlled by more than one phase, as in the case of a right-turn indicative arrow
situation. If either Signal Phase or Signal Phase2 is green the link is deemed to be
green.
Simulated Annealing
Choosing this option changes the main part of the TRANSYT optimisation process to
use this alternative optimisation technique as part of its overall optimisation process.
It is a technique which can be effective at finding an acceptable set of good signal
timings within a reasonable time period, rather than necessarily finding the best
timings. The name comes from metallurgy, in which by heating up a material and
letting it cool down it allows more initial freedom (while hot) of changes within the
structure.
Slope coefficient
A coefficient used in the TRANSYT give-way model. It is a measure of how much
traffic can cross a give-way link through another stream of traffic. This coefficient can
be calculated using ARCADY or PICADY or directly through the new TRANSYT
Priorities model.
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.
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.
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.
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.
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.
30 References
ANON. (1968). SIGOP traffic signal optimisation program users manual. New York,
(Peat, Marwick, Livingston and Co.).
BURTENSHAW G L and X Zhang (2006). OSCADY PRO User Guide. TRL Application
Guide AG 59. Crowthorne: Transport Research Laboratory.
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.
VINCENT R A (1972). Area traffic control in Bern. Traffic Engineering and Control,
Vol 13, No 10.
References (CTM)
Crabtree M. (2002). Modelling opposed right-turn movements in TRANSYT Part 1.
Traffic Software News, 20. TRL.
Daganzo C. (1995). The cell transmission model, Part II: network traffic.
Transportation Research-B, 29 (2) 79-93.
During the import process you may be shown one or more warning messages or given
options about how to import certain items.
Most data items that existed in TRANSYT 14 still exist in TRANSYT 15 and
therefore will be brought into TRANSYT 15. Their location within the data
structure may have changed. Please consult the TRANSYT 15 User Guide and
use the Data Filed Finder if you have difficulty finding a particular item.
Where the TRANSYT 14 traffic model chosen is CPDM this will be translated
into the Flare Model in TRANSYT 15
Report options will not be imported Imported files will use your default
settings within TRANSYT 15.
During the import process you may be shown one or more warning messages or given
options about how to import certain items.
TRANSYT 12 files using T12mode do not contain intergreens, but use start lags
to define the interstages/intergreens instead. It is safest that TRANSYT 15
does not derive intergreens from these values, so TRANSYT adds equivalent
phase delays instead, in order to ensure that the imported file retains the
signal timings it is importing. Without these, the interstages would be lost
altogether. Subsequently, users can choose to remove the phase delays and
replace them with intergreens as required.
TRANSYT 13 did not allow the CTM cell saturation flow to differ from the stop
line saturation flow. Therefore, when importing a give-way link with control
type None the TRANSYT 15 cell saturation flow is set to the highest value
of the TRANSYT 15 default (for the cell sat flow) and the imported maximum
flow value.
Due to the extended options that TRANSYT 15 now offers you may wish to
review/examine your imported file to ensure that you making best use of
TRANSYT 15 and that you are modelling your network in the best way possible.
To import Dutch .IN TRANSYT files you can use File>Import>From TRANSYT 7-
SET/10/11/12, and changing the Files of type: from TRANSYT 12 (*.dat) to
TRANSYT 7-SET.
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 network diagram (.nce) file, it
will be found and loaded automatically. Otherwise, you will be prompted to locate the
.nce file; simply Cancel this screen if you need to.
If a TRANSYT 12 network diagram (.nce) file was supplied, then TRANSYT 15 will load
this in and position nodes and links according to this file. Given the difference in
appearance between the network diagram in TRANSYT 12 and TRANSYT 15 however,
the network may not appear exactly as it did in TRANSYT 12.
If no network diagram file was supplied, then showing the network diagram window in
TRANSYT 15 will auto-arrange the network into a circular shape, making it easier to
re-position the diagram items.
Check the Task List after importing, as there may be warnings and errors that would
not have shown up in TRANSYT 15. In general, TRANSYT 15 checks for more
problems than does TRANSYT 12, therefore a file that ran in TRANSYT 12 may show
errors or warnings in TRANSYT 15.
N.B. Data items that are represented differently in TRANSYT 15 will be automatically
converted on import to the new representation, e.g. -9999 (zero) delay weightings
will be converted to the equivalent 0% weightings.
Importing a file from TRANSYT 10/11/12 will automatically set the random delay
mode to Simplified (TRANSYT12) mode.
It is recommend that you check the Task List after importing, as there may be
warnings and errors that would not have shown up in TRANSYT-7F. In general,
TRANSYT 15 checks for more and different problems than does TRANSYT-7F.
Furthermore, due to differences in the two products, TRANSYT 15 interprets rather
than simply reads many of the TRANSYT-7F data items. Therefore, a file that ran in
TRANSYT-7F may show errors or warnings in TRANSYT 15.
A summary of, to what extent data is imported from each TRANSYT-7F Record Type is
as follows:
Fully
2 Optimisation Node List
7 Shared Lanes
1X Controller Timing
18 Controller Timing
2Y Phasing Data*
28 Link Data
36 Volume Multiplier
42 Arterial Routes
61 Route Link
70 Node Coordinates
Partially
1 Run Controls
10 Network Parameters
9X Termination Instructions
Not at all
3 Movement Numbering
5 Associated Links
8 Model Coefficients
33 Throughput Weighting
41 Bandwidth Constraints
43 Arterial Weighting
5X Run Instructions
60 Route Parameters
71 Link Curvature
TRANSYT 15 will load in and position nodes and links according to this file.
TRANSYT 15 interprets both the TRANSYT-7F standard link numbering
scheme and the NEMA scheme in order to minimise any differences
between the layouts. However, it does not attempt to interpret custom
numbering schemes.
Given the differences in the data items and appearance between TRANSYT-
7F and TRANSYT 15, the network may not appear exactly as it did in
Sneakers are not imported. It is down to the user to manually add back in
the capacity benefits of sneakers either by explicitly modelling the space in
front of the stop line or adding equivalent phase relative end
displacements at a suggested rate of 2 seconds per sneaker.
Imported files are brought into TRANSYT as a link structure rather than a
lane/traffic stream structure. However, where a link represents multiple
lanes it is relatively easy to identify this situation from the links high
saturation flows.
You may notice some visual disparities between the TRANSYT-7F Lane
Configuration screen and the network diagram. This can be due to the
following:
Yellow and Red intervals are converted into TRANSYT gaining delays on
each link to represent the interstages. Users may wish to replacer these
and populate the intergreen matrix instead. Also note that the Red and
Yellow intervals associated with a particular TRANSYT-7F phase is
associated with the following TRANSYT 15 stage due the difference in how
All TRANSYT imports assume that traffic flows are in PCU. TRANSYT can be
changed to interpret values as vehicles, and a mix of traffic types can also
be added. This however, can be done AFTER importing the assumed PCU
flows.
Finally, there are many modelling options that are in one product but not the
other, e.g. the Cell Transmission Model in TRANSYT 15 and the various permitted-
movement models in TRANSYT-7F. Therefore, consideration should be made of
the impact these differences will have when comparing results between the two
products. Having said that, there is considerable commonality in both the data
specified and the modelling features of these products, hence essentially they can
be used to do the same job.
File>Import>From Synchro 7 CSV (Beta) and then browse to your .CSV file. During
the import process you may be shown one or more information messages or given
options about how to import certain items. The import process brings in as much
data from the CSV file as it can, i.e. what is compatible with TRANSYT and also makes
sense within the context of a TRANSYT network.
TRANSYT 15 contains new data items compared to TRANSYT 14 and so clearly not all
data can be successfully exported to TRANSYT 14, e.g. priority crossroads object.
Some data items that are represented differently in TRANSYT 14 will be automatically
converted on export to the equivalent representation, e.g. traffic streams or links
using the flare traffic model will be set to use either CTM or CPDM based on their
length, so that they continue to use the same model as before.
SCOOT coordinates the operation of all the traffic signals in an area to give good
progression to vehicles through the network. Whilst coordinating all the signals, it
responds intelligently and continuously as traffic flow changes and fluctuates
throughout the day. It removes the dependence of less sophisticated systems on
signal plans, which have to be expensively updated.
TRANSYT 15 has a facility to assist in the transfer of flow data from SCOOT into
TRANSYT. This facility is accessed from Tools>SCOOT>Import SCOOT Link flows.
TRANSYT obtains the flow data from SCOOT M02 messages (see Figure 33-2),
therefore within SCOOT, M02 messages must be set up to be produced. The rate at
which these are generated (usually every 5 minutes or every cycle length) is decided
by the SCOOT operator.
The SCOOT flow data is reported in units that are most closely match
those of a PCU, rather than a vehicle. You can tell TRANSYT what
traffic flow units you are using (PCU or vehicles), and therefore we
recommend that you indicate that the flows are in PCU when you are
importing SCOOT data, and that saturation flows are also specified in
PCU. Switching units does not change the data entered.
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.
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.
TRANSYT 15 has a facility to assist in the transfer of flow data from SCATS into
TRANSYT. This facility is accessed from Tools>SCATS>Import SCATS Volume flows.
Note that TRANSYT links must be used rather than TRANSYT traffic streams.
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.
On pressing the Import button, TRANSYT will import flow data from all relevant files
and will report what files (Controllers) it has imported data from (see screen shot).
Some advice on how to create the required data files is given in section 34.1.
From the window choose a REGION from the drop down list.
From the Period fields use the drop down calendars to select the same Start
date and End date.
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.
Choose File>Save As from the menu and save the file to a folder containing
the traffic volumes for use with TRANSYT.