RTM Network Coding Draft V 08 Final - (Changes Highlighted)

Regional Traffic Models
Network Coding Manual
Date: 11 December 2015 Version: 0.8
Registered office Bridge House, 1 Walnut Tree Close, Guildford GU1 4LZ
Highways England Company Limited registered in England and Wales number 09346363
Document Control
Document Title Regional Traffic Models

Author
Owner Alison Cox
Distribution
Document Status Draft
Revision History
Version Date Description Author

0.1 16 July 2015 Draft for comment AMC
0.2 6 August 2015 Inclusion of agreed SFC AMC
0.3 25 September Include Network Development ANH
Group’s comments
0.4 9 October 2015 Final Draft ANH, AMC, MB
0.5 10 October 2015 Flare Coding Update WW
0.6 30 October 2015 Include Network Development ANH
Groups comments
0.7 3 November 2015 WW Comments (table 28) ANH
0.8 11 December 2015 Include Network Development MB
Groups comments
Reviewer List
Name Role
Nhan Nyugen Network Consistency Group North
Hossein Farsi Network Consistency Group Northern Powerhouse
Adam Hall Network Consistency Group Midlands
Tom Oldershaw Network Consistency Group Northern Powerhouse
Suzanne Pritchard Network Consistency Group South West
Wei Wang Network Consistency Group South East
Ian Wright Atkins
Approvals
Name Signature Title Date of Version

Issue
The original format of this document is copyright to the Highways England.
RTM Network Coding Draft V 08 Final - Copy.docx Page 2 of 97

Created by: Alison Cox 16/07/15
Table of Contents
1
1. Introduction 7
2. Regional Model Coding Principles 8
2.1. Network Density and Coding Principles 8
2.2. Node and Zone Numbering Convention 9
3. Network Assignment Parameters 11
3.1. Introduction 11
3.2. Logical Parameters 11
3.3. Integer Parameters 12
3.4. Real Parameters 13
4. SATURN Simulation Network Coding 15
4.2. Signalised Junctions 15
4.3. Priority Junctions 18
4.4. Roundabouts 22
4.5. Gyratories and ‘Exploded’Roundabouts 24
4.6. Motorway Main Carriageway and Slip Roads 26
4.7. Flare Lanes 27
4.8. Speed Flow Relationships 28
4.9. Methods for representing Cruise Speeds and Fixed Speed Links 28
4.10. Default Speed-Flow Curves 30
4.11. HGV Free Flow Speeds 31
4.12. Gap Acceptance 32
4.13. Capacity Reductions for Merges 32
5. Motorway Network Coding 33
5.2. Motorway Merge Coding 33
5.3. Motorway Diverge Coding 41
6. Zone Connectors 47
7. Bus Routes 48
8. Trafficmaster Data 49
8.2. Data Available 49
8.3. Journey Time Calculations 49
8.4. RTM Data Processing 49
Appendix A 50
Appendix B 60
Appendix C 67
Appendix D 83

List of Tables
Table 1: Principles of Network Coding 8

Table 2: RTM Node Numbering Convention 9
Table 3: RTM Zone Numbering Convention 9
Table 4: Signalised Junction – Straight Ahead Saturation Flows (PCU’s per
hour) 17
Table 5: Signalised Junctions – Range of Turn radii (metres) 17
Table 6: Signalised Junction –Turn Saturation Flows (PCU’s per hour) 18
Table 7: Priority Junctions – Range of Turn Radii (metres) 20
Table 8: Priority Junctions – Range of Unopposed Turn Saturations Flows
(PCU’s per hour) 21
Table 9: Priority Junctions – Give-Way and Opposed Turn Saturations
Flows for 1 lane approaches (PCU’s per hour) 21
Table 10: Priority Junctions – Give-Way and Opposed Turn Saturations
Flows for 2 lane approaches (PCU’s per hour) 22
Table 11: Roundabouts – Generic Geometric Parameters 23
Table 12: Roundabouts – Range of Saturation Flows (PCU’s per hour) and
GAP values 24
Table 13: Exploded Signal Controlled Roundabout Saturation Flow Values
Table 14: Exploded Roundabout Priority Controlled Saturation Flow Values
Table 15: Motorway Main Carriageway – Saturation Flow Values (PCU’s per
hour) 26
Table 16: Motorway Slip Roads – Saturation Flow Values (PCU’s per hour)
27
Table 17: Speed/Flow Relationships 31
Table 18: Taper Merge Node and Link SATURN Coding 35
Table 19: Parallel Merge Node and Link SATURN Coding 36
Table 20: Merge with Ghost Island Node and Link SATURN Coding 37
Table 21: Lane Gain Node and Link SATURN Coding 38
Table 22: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain)
Node and Link SATURN Coding 39
Table 23: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge)
Table 24: Taper Diverge Node and Link SATURN Coding 41
Table 25: Parallel Diverge Node and Link SATURN Coding 42
Table 26: Ghost Island Diverge Node and Link SATURN Coding 43
Table 27: Lane Drop at Taper Diverge Node and Link SATURN Coding 44
Table 28: Lane Drop at Parallel Diverge Node and Link SATURN Coding 45
Table 29: Lane Drop Ghost Island Diverge Node and Link SATURN Coding
46


List of Figures
Figure 1: Signalised Junction Movement Descriptions 16

Figure 2: Priority Junction Movement Descriptions 18
Figure 3: Taper Merge Schematic Diagram (Source: TD22/06) 35
Figure 4: Taper Merge Node and Link SATURN Coding 35
Figure 5: Parallel Merge Schematic Diagram (Source: TD22/06) 36
Figure 6: Parallel Merge Node and Link SATURN Coding 36
Figure 7: Merge with Ghost Island Schematic Diagram (Source: TD22/06) 37
Figure 8: Merge with Ghost Island Node and Link SATURN Coding 37
Figure 9: Lane Gain Schematic Diagram (Source: TD22/06) 38
Figure 10: Lane Gain Node and Link SATURN Coding 38
Figure 11: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain)
Schematic Diagram (Source: TD22/06) 39
Figure 12: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain)
Figure 13: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge)
Schematic Diagram (Source: TD22/06) 40
Figure 14: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge)
Figure 15: Taper Diverge Schematic Diagram (Source: TD22/06) 41
Figure 16: Taper Diverge Node and Link SATURN Coding 41
Figure 17: Parallel Diverge Schematic Diagram (Source: TD22/06) 42
Figure 18: Parallel Diverge Node and Link SATURN Coding 42
Figure 19: Ghost Island Diverge Schematic Diagram (Source: TD22/06) 43
Figure 20: Ghost Island Diverge Node and Link SATURN Coding 43
Figure 21: Lane Drop at Taper Diverge Schematic Diagram (Source:
TD22/06) 44
Figure 22: Lane Drop at Taper Diverge Node and Link SATURN Coding 44
Figure 23: Lane Drop at Parallel Diverge Schematic Diagram (Source:
TD22/06) 45
Figure 24: Lane Drop at Parallel Diverge Node and Link SATURN Coding 45
Figure 25: Lane Drop Ghost Island Diverge Schematic Diagram (Source:
TD22/06) 46
Figure 26: Lane Drop Ghost Island Diverge Node and Link SATURN Coding
46

1. Introduction
This document sets out the methodology and assumptions which will be applied during the
development of the five regional traffic models. The methods employed here have been derived
from a variety of different sources, following guidance where available, best practice in all
aspects and professional judgement.
As the values defined here are generated at the outset of the model development process they
should be considered as appropriate starting values. It is anticipated that during model
calibration the values will be modified to better fit local circumstances. Any deviations from
these guidelines will be monitored, recorded and, where appropriate, reported in the individual
Model Validation Reports.
The document covers a variety of different aspects of network coding which will be discussed in
detail in the following sections:
 Section 2 provides detail on the coding principles to be adopted by the Regional

Transport Models;
 Section 3 details the SATURN Network Assignment Parameters;
 Section 4 discusses SATURN simulation network coding such as saturation flows, GAP
parameters, the treatment of Flare lanes and the representation of “exploded”
roundabouts, definition of speed flow relationships;
 Section 5 describes the approach to modelling motorway merging;
 Section 6 describes the zone coding procedures including the identification of centroid
locations and options for connecting the zones into the simulation and external
networks;
 Section 7 describes the methodology for coding of bus routes; and
 Section 8 describes the process of using the Trafficmaster data for the regional model
development.

2. Regional Model Coding Principles
2.1. Network Density and Coding Principles

As a basic principal a tiered approach to coding has been agreed as set out in Table 1.
Area 1 Area 2 Area 3 External

Coverage  SRN  Rural roads that  Urban  Roads outside
 Roads are not areas the region of
connected connected to outside the focus (e.g.
to/parallel with SRN influence neighboring
SRN area of RIS regions,
 Roads schemes Scotland,
considered and the Wales)
important to RIS SRN
scheme network
appraisal
Level of  Detailed junction  Template  Dummy  Buffer Network
Coding coding (accurate signalised Nodes
layout, sat flow, junction coding
signal timing)  Less detailed
junction coding
(e.g. flare lanes
may not need to
be considered,
etc.)
Speed  Links with  Links greater  No  No
Flow greater than 1km than 1 km
Curves for rural roads
Fixed  In urban area 
No - free-flow  Yes -  Yes, taken
Speeds (from speed taken taken from from
Trafficmaster) from speed-flow Trafficmast Trafficmaster
curve er JT data JT Data
Table 1: Principles of Network Coding
As described in Table 1 above all rural areas away from Strategic Road Network (SRN) should
be coded by junction type using standard template coding described in this manual. This
method of coding will reduce potential for trips routing through the rural areas to avoid
congestion near SRN. A technical note detailing signalised junction coding template to be
adopted for regional traffic models development is attached in Appendix A.
In urban areas outside the influence of the SRN and RIS schemes, network detail will be
reduced, only including key routes and maintaining zone connectivity. Given the skeletal nature
of the RTM networks, detailed junction coding is not proposed and dummy nodes will be used,
in effect allowing infinite junction capacity. Routing through the urban areas will be controlled by
fixed model speeds derived from observed Trafficmaster journey time data by time period. At
the calibration stage, trip demand and routing through the urban areas will be reviewed to
ensure they are modelled correctly. In addition, dummy nodes near SRN and one-way links in
urban areas will be reviewed to ensure they are operating suitably. At this stage, flat (fixed
speed) speed flow curves may be used to introduce capacity restraint where needed. At the
forecasting stage and to model the impact of increased demand on the speed of such links, a
procedure currently developed by the Traffic Forecasting Technical Consistency group will be
used to adjust the speed of the links with fixed speed to represent changes in trip demand.

2.2. Node and Zone Numbering Convention
Node Numbering Convention
The node numbering convention to be adopted for the different RTMs is summarised in Table 2
below.
Region Region ID Sample Simulation Node ID
South East 1 10001 to 19998
East of England 2 20001 to 29998
Greater London 3 30001 to 39998
East Midlands 4 40001 to 49998
West Midlands 5 50001 to 59998
South West 6 60001 to 69998
Yorkshire and Humber 7 70001 to 79998
North West 8 80001 to 89998
North East 9 90001 to 99998
Wales 10 100001 to 100998
Scotland 11 110001 to 199998
Table 2: RTM Node Numbering Convention
Please note that regional modelling teams need to confirm node numbers with each other in
order to ensure that two neighbouring regions are not using same node numbers.
Zone Numbering Convention
The order proposed for zone numbering convention in Table 3 ensures the zone IDs being
named by the node IDS with at least one region in between. This can help to avoid occurrence
of same node and zone ID in each of the regional model.
Sample Simulation
Region Region ID Sample zone IDs
Node ID
South East 1 10001 to 19998 80001 to 89998
East of England 2 20001 to 29998 60001 to 69998
Greater London 3 30001 to 39998 70001 to 79998
East Midlands 4 40001 to 49998 60001 to 69998
West Midlands 5 50001 to 59998 90001 to 99998
South West 6 60001 to 69998 20001 to 29998
Yorkshire and
7 70001 to 79998 30001 to 39998
Humber
North West 8 80001 to 89998 10001 to 19998
North East 9 90001 to 99998 50001 to 59998
Wales 10 100001 to 109998 90001 to 99998
Scotland 11 110001 to 199998 50001 to 59998
Table 3: RTM Zone Numbering Convention

Regional modelling teams need to confirm zone numbers with each other to ensure that two
neighbouring models are not using the same zone numbers.

3. Network Assignment Parameters
3.1. Introduction
This section looks at the proposed settings for global parameters contained within the SATURN
network. These settings do not detail all the parameters available within SATURN, and the
values of these parameters may require further investigation through the process of model
calibration.
It is proposed that the default parameters in SATURN v11.3.12F with revisions as mentioned in
this section should be considered as suitable starting point for the SATURN network
development. Release of v11.3.12U in November 2015 replaces v11.3.12F for regional traffic
models.
3.2. Logical Parameters
The following does not detail the recommended values for all the logical parameters within
SATURN, but lists some of the key parameters that should be considered when setting up a
SATURN network.
 AUTNUC, AUTOK and AUTONA: These should all be set to TRUE. These parameters
allow SATURN to set automatic values that should lead to improved model convergence
and reduced model run times. (AUTONA available in versions 10.7 onwards.)
 BB109: It is recommended that this is set to TRUE to implement the revised procedures
for calculating blocking-back within the assignment. This allows blocking-back to be
phased in from the value of BBKING, which should improve model stability. (BB109
available in versions 10.9 onwards.)
 CLIMAX: If modelling fixed maximum speeds for vehicles classes (such as HGVs) this
parameter should be set to TRUE (FALSE allows the use of time penalties to reduce the
speed of a vehicle class at all points on the speed-flow curve). WebTAG Unit M3.1
Appendix D suggests the used of fixed maximum speeds for HGVs, particular for
motorways and A-roads.
 DUTCH: This should be set to TRUE as 5-digit node numbers are used within the RTMs
highway networks. Note that this will alter the spacing in certain other sections of the
network file.
 FIFO: If set to FALSE, when a data item appears twice, the first data entry is used. As
the RTMs are adding the latest network changes on the top of 11111 card, FIFO should
be set to FALSE.
 FOZZY: This parameter should be set to TRUE. If true, the program will try to interpolate
unconnected nodes in bus routes.
 FREEXY: This parameter should be set to TRUE. If true then the supplementary node
data in the 55555 records are input as free format.
 FUNNEL: This parameter should be set to FALSE. If set to true, turns coded with a
merge priority marker are assumed to ‘funnel’ into a single exit lane with their ‘major’
turn. See SATURN Manual section 6.4.2.3 and 8.8.4 for further discussion.
 M108: This should be set to TRUE to implement revised rules for merge priority
markers. (M108 available in versions 10.8 onwards.)
 MULTIC: This parameter allows the assignment to use multi-core processing, therefore
reducing run times, and therefore should be set to TRUE.
 MONACO: This parameter should be set to TRUE. This means that the number of right-
turning PCUs that are required to sit at the head of a queue in order to block ahead

traffic is set to the value of TAX +1. This helps to improve model convergence.
(MONACO available in versions 10.8 onwards.)
 RAGS: This parameter should be set to TRUE. This parameter introduces extra delays
to “give - way” or “minor” or “major” traffic movements, as V approaches C.
 SECRET: Currently, this is set to the default of FALSE, but may be changed to TRUE
upon completion of the final network to prevent network editing without authorisation
from HE.
 SPIDER: This parameter should be set to TRUE. This process creates an ‘aggregated
network’ which should reduce model run times during an assignment.
 UFC109: This parameter should be set to TRUE. Rather than running an additional
SAVEIT assignment to create a UFC file, UFC109 stores all cost paths used during the
model run. This provides a much higher level of accuracy of select link analyses and
skims. Important to consider NITA_C when using UFC109. (UFC109 available in
versions 10.9 onwards.)
 WRIGHT: This parameter should be set to TRUE. This upgrades certain warnings,
serious warnings and non-fatal errors to semi-fatal (NAFF) errors. This reduces the
likelihood of serious network coding errors in the final model. (WRIGHT available in
versions 10.7 onwards.)
3.3. Integer Parameters

As with the logical parameters, this section does not detail recommended values for all integer
parameters contained within SATURN, but lists some of the key parameters that should be
considered when coding a SATURN network.
 IEPSG: This parameter defines the coordinate system upon which the SATURN
coordinate system is based and should be set to 27700 for UK networks.
 ISTOP: This is used as a test for convergence of the assignment / simulation loops
(depending on the choice of KONSTP). The convergence criteria are met when the
percentage of links whose flows changes by less than PCNEAR is above ISTOP
between two successive iterations. The value for ISTOP should be at least 99% should
be used where these can be attained. (if this is not practically achievable at least 98% as
suggested by WebTAG Unit M3.1 Table 4)
 KLUNK: This should be set to 1. This allows for different maximum speeds to be set on
modelled default speed-flow curves by vehicle class. This means, for instance, that all
HGVs can be set to have lower speeds than cars / LGVs on motorways and dual
carriageways. A correctly formatted FILVSD file is required for this parameter to correctly
function. (KLUNK available in versions 10.8 onwards.)
As speed for HGVs is now different for single carriageways and dual carriageways/
motorways, appropriate coding method should be adopted to reflect this.
 KONSTP: This parameter allows for different assignment stopping criterion monitoring
methods to be set. The possible values for this parameter are:
0 = convergence based on ISTOP criteria;
1 = convergence based on %Gap criteria;
2 = convergence based on CPU time criteria;
3 = convergence based on ISTOP with an upper limit on CPU time;
4 = convergence based on %Gap with an upper limit on CPU time;
5 = convergence based on both ISTOP and %Gap criteria; or
6 = convergence based on either ISTOP or %Gap criteria.

It is recommended that the value of KONSTP is set to 1, 5 or 6, with 5 being the

preferred option. The use of option 5 allows the assignment to satisfy both the %Gap
and %Flows criteria within WebTAG simultaneously. This convergence criterion, along
with the associated values of STPGAP, ISTOP and PCNEAR (where applicable) should
be considered to balance model convergence and assignment run times. (KONSTP
available in versions 10.7 onwards, with options 3 onwards only available in version 11
onwards.)
 LTP and LRTP: These should all be set to the length of the modelled time period in
minutes, in the case of RTM Base 60 minutes.
 MASL: This is the maximum number of assignment / simulation loops undertaken in an
assignment. Generally it is not desirable for this limit to be reached, therefore terminating
the assignment prior to reaching the desired convergence criteria. A high value of 100 is
recommended with a low value of NITA in the hope that convergence would be achieved
in far fewer than 100 loops.
 NISTOP: This is generally set to 4. This parameter determines the number of successive
iterations that the stopping criteria (ISTOP, STPGAP or STPPCU) need to be achieved
in order for a model to converge. A value of 4 is suggested within WebTAG Unit M3.1
(Table 4).
 NITA: Refers to maximum number of assignment iterations and should be set to 30 but
will be overwritten by AUTONA.
 NITA_C: This is the number of loops that are saved within the SATURN UFC file when
using UFC109. The default value of 256 is generally exceeded in larger models (such as
the RTMs), and in this case the model reverts back to a SAVEIT assignment. A value of
2500 for NITA_C is recommended to avoid this occurring.
 NITA_S: This value is ignored if UFC109 is set to true.
However, should a SAVEIT be adopted this value determines the level of accuracy of
the SAVEIT assignment (the number of iterations that will be run). In general, 50 may be
considered a suitable value for a normal model, 150 if high-level analysis (select links,
cordoning) are required and in excess of 250 if the model outputs are to be used for
economic analysis, e.g. TUBA.
 NITS: Refers to maximum number of simulation iterations and should be set to 50.
 NOMADS: This value should be set equal to the number of modelled user-classes
defined in the generalised cost (88888) cards.
3.4. Real Parameters

Finally, this section details some of the key ‘real’ parameters that should be considered when
setting up a SATURN network.
 APRESV: This parameter controls the ‘weight’ assigned to merging traffic in terms of the
lane choice by the ‘major’ traffic for turn priority markers M. This in effect is the weight by
which the mainline traffic at a merge is willing to move out of the inside line to allow
merging traffic to join the carriageway, and is a way of attributing a portion of the merge
delay to the mainline flow. This should be set to a value of 1.0.
 BBKING: This defines, in conjunction with BB109, the ratio of queue to stacking
capacity at which blocking back begins to be phased in. It is suggested that this
parameter be initially set to 0.95, and adjusted within model calibration if necessary
depending on whether the model produces excessive or insufficient delays at known
locations of queuing, and on the convergence level of the assignment.

 FISTOP: This parameter is wardrop assignment stopping parameter for monitoring the
fractional improvements in the objective function and should be set to 0.05%
(0.5*STPGAP) (will need be reviewed again if not practical to achieve).
 GAP: This parameter should initially be set at 2.0 seconds. This determines the required
gap in oncoming traffic for right-turners at a priority junction or signals to be able to make
a turn. This value can be reduced or increased as appropriate in model calibration, but is
best determined based-upon an average from observed values (if available).
 GAPM: This parameter should initially be set at 1.0 seconds. This determines the
required gap for traffic to join the main carriageway where a merge turn priority marker
has been coded. The actual value used is best determined based upon an average of
observed values (if available).
 GAPR: This parameter should be set at 2.0 seconds. 2.0 seconds is the GAPR value for
a ‘normal’ roundabout. Ideally, all roundabouts will explicitly have their own GAPR value
defined in the node coding based on the type of roundabout as shown in Table 14. This
global value is used as a default if no value has been coded specifically at a node.
 GONZO: This is a factor that is applied to the matrix prior to assignment. This is
generally only used for PassQ assignments which represent the pre-peak hours.
PCNEAR: This parameter is used in conjunction with ISTOP to determine model
convergence. This parameters sets the percentage change below which a link ‘passes’
ISTOP convergence criteria. WebTAG Unit M3.1 (Table 4) suggests that a value of 1%
should be applied.
 PMAX: This parameter sets the maximum value of the power used in the simulation
flow-delay curves. A value of 5 is recommended to constraint the simulation flow-delay
relationship.
 PPK/PPM: This parameter converts the distances/times into generalised costs and
should be consistent with TAG Databook.
 QDMAX: This is the maximum delay that can be calculated at a Q-node. This should not
be changed from the default value of 226.
 QVMIN: This is the minimum volume-to-capacity ratio at which delays are applied to Q-
nodes. This should not be changed from the default value of 0.75.
 STPGAP: This is the required %GAP value by which model convergence should be
monitored. This parameter should be set to a maximum of 0.05 and should be
achievable for most models; with lower targets being aimed for if model run times and
assignment convergence allow (WebTag Unit M3.1 Table 4 suggests a maximum value
of 0.1%). This value should be reviewed at the forecasting stage.
 TIJMIN: This sets a value below which demand movements are ignored in the
assignment. Setting this parameter to a value above 0 can have significant impacts on
the model run times; however it can also have significant impacts on the assigned
volumes. On this basis this parameter should be set to 0 so that it is not applied within
the assignment.
 UNCRTS: This parameter sets the stopping criteria for the assignment stage on its own
should be less than STPGAP, otherwise the overall convergence will be restricted by the
assignment convergence. This should be set to a value of 0.025% (0.5* STPGAP)
 XFSTOP: This parameter is Wardrop assignment stopping parameter for minimum step
length and should also be set to a value of 0.025% (0.5* STPGAP)

4. SATURN Simulation Network Coding
4.1. Introduction
This section of the manual provides a description of how the turn saturation flows can be
calculated and applied for each junction included within the SATURN simulation network.
Saturation flow is defined in the SATURN User Manual Section 6.4.6 as “the maximum number
of pcu’s per hour which could make that particular turning movement PROVIDED there were no
other vehicles on the road, no red lights to oppose it, etc.”
The calculation of the turn saturation flows is therefore based upon the physical characteristics
of the junction incorporating standard attributes such as:
 Junction type – including signalised junctions, roundabout and signals.
 Major or minor arm
 No of lanes
 Lane Width
 Turning Radius
 Position of lane – nearside and offside
 Visibility and finally
 Inclination (on hills)
The regional models are strategic and therefore it is appropriate to calculate a range of standard
values, comprised of a mean, a minimum and a maximum value, for each type of junction. The
starting point is likely to be the mean value and the model developer has the flexibility to modify
between the minimum and maximum value during the model calibration process to reflect local
conditions. If values are to be used which fall outside of the range these should be reported in
the Model Validation Report.
Please note that the tables in Section 4 include reference to nearside and offside lanes.
Evidence shows that these lanes have a slightly lower saturation flow than other lanes at
junctions. Saturation flows “including nearside” should be applied where the movement can
make use of the lane adjacent to the kerb. Saturation flows “excluding nearside” are for
movements which do not use this lane. These saturation flows are only available for straight
ahead and right turn movements, as a left turn will always use the nearside lane. If the nearside
lane is shared between several movements, all those movements should use the “including
nearside” saturation flow, even if they can use other lanes as well.
The following sections provide the generic calculations which have been used to define the
standard saturation flows used for each junction type in the simulation network. There also
follows a brief explanation of how flare lanes are dealt with.
4.2. Signalised Junctions
Saturation flows for signalised junctions have been based on calculations given in Research
Report 67 (Kimber, McDonald and Hounsell, Transport Research Laboratory, 1986). All
movements at signalised junctions are assumed to be unopposed by other traffic due to
appropriate movements enabled during each phase of the signal cycle. Error! Reference
source not found. below describes the different possible movements at a priority junction for
which saturation flows need to be calculated.

Figure 1: Signalised Junction Movement Descriptions
Straight ahead movement (Movement B) saturation flows are calculated using Equation 1
defined below:
Equation 1
Sa = (2080-(140*C)-42*C*B)+100*((A*(1+R)/2)-3.25)
Where:
Sa = straight ahead saturation flow in PCU’s per hour
A = lane width (entry width) in metres
B = gradient (% incline)
C = nearside (1) or offside (0)
R = R factor (exit width/entry width)
Turn saturation flows (Movements A and C) are calculated based upon a relationship between
the straight ahead saturation flow and the radius of the turn. Equation 2 defined below is used:
Equation 2
Sr = Sa/(1+1.5/R)
Where:
Sr = turn saturation flow in PCU’s per hour
Sa = straight ahead saturation flow in PCU’s per hour
R = radius of the turn in metres
Assuming an average value for B of 0% incline, Table 4 below provides the saturation flows for
straight ahead movements for a range of wide to narrow roads. For one lane approaches the
standard lane width is assumed to be 3.65m with the narrow and wide lane assumptions set to
2.50m and 5.00m respectively. For two or more lane approaches the standard lane width is
assumed to be 3.00m with the narrow and wide lane assumptions also set to 2.50m and 5.00m
respectively.

Lane Width 1 lane 2 lanes 3 lanes 4 lanes

Nearside Offside Nearside Offside Nearside Offside Nearside Offside
Single Lane Approach
Narrow Lane 1,870
(2.5m)
Standard 1,980
(3.65m)
Wide Lane 2,070
(4.5m)
Multiple Lane Approach
Narrow Lane 2,010 3,870 4,010 5,880 6,020 7,880 8,020
(2.5m)
Standard (3.0m) 2,060 3,970 4,110 6,030 6,170 8,080 8,220
Wide Lane 2,210 4,270 4,410 6,480 6,620 8,680 8,820
(4.5m)
Table 4: Signalised Junction – Straight Ahead Saturation Flows (PCU’s per hour)
To avoid measuring the geometry of every individual junction a series of standard values have
been derived which can be selected for use at each junction based upon available data. A
reasonable range of turning radii for left and right turning movements at a signalised junction
could be considered as follows:
Turn Radius Left Turning Movement Right Turning Movement
Tight 5 7.5
Standard 10 15
Wide 20 30
Table 5: Signalised Junctions – Range of Turn radii (metres)
The application of this range of values and the use of the standard 3.65m lane width leads to
the saturation flows presented in Table 6 below.
In the case of an opposed right turn then a standard turning saturation flow should be assumed.
In these instances a comment should be placed in the DAT file for review during calibration.

Turn Radius 1 Lane 2 Lanes 3 Lanes 4 Lanes

Left Right Left Right Left Right Left Right
Inc Exc Inc Exc Inc Exc Inc Exc Inc Exc Inc Exc
Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns
Single Lane Approach
Tight 1530 1650
Standard 1730 1800
Wide 1850 1890
Multiple Lane Approach
Tight 1480 1600 3060 na 3310 3430 4640 na 5030 5140 6220 na 6740 6850
Standard 1670 1750 3460 na 3610 3740 5240 na 5480 5610 7030 na 7350 7480
Wide 1790 1830 3700 na 3790 3920 5610 na 5740 5880 7520 na 7700 7830
Table 6: Signalised Junction –Turn Saturation Flows (PCU’s per hour)
4.3. Priority Junctions
Priority junction saturation flows are calculated in a similar way to signalised junctions. Figure 2
below describes the different possible movements at a priority junction for which saturation
flows need to be calculated.
Figure 2: Priority Junction Movement Descriptions
The unopposed straight ahead (Movement E) saturation flow is calculated using Equation 1
defined above. The unopposed left turn (Movement D) saturation flow is calculated using
Equation 2 above.
Figure 2 describes a particular type of priority junction. There are also likely to be examples at
other junction layouts where unopposed right turns from major arm to minor arm and left and
right turns from minor arm to major arm exist. Equation 2 is still applied when calculating the
saturation flows of these turns although different assumptions regarding turn radii are proposed
as described in Table 2.4 below.

For opposed from major to minor turns (Movement F) or give-way minor to major turns
(Movements G; H and I) alternate equations have been derived which are identified in DMRB
Volume 6 Section 2 Part 6 TD42/95. These equations are again based upon the geometric
layouts of the intersections.
The major to minor arm opposed right turn (Movement F) saturation flow is calculated using
Equation 3 defined below:
Equation 3
Sr = Z*(745-0.364*(1-0.0345))
Where:
Z = geometric parameter based on the following calculation:
Equation 4
Z = (1+0.094*(D-3.65))*(1+0.0009*(E-120)
Where:
D = lane width in metres
E = visibility to the right in metres
The minor to major give-way left turn (Movement G) saturation flow is calculated using Equation
5 defined below:
Equation 5
Sr = Y*(745-(1-0.0345)*(0.364+0.144))
Where:
Y = geometric parameter calculated based on the following equation:
Equation 6
Y = (1+0.094*(D-3.65))*(1+0.0009*(E-120))
Where:
The minor to major give-way straight ahead (Movement H) saturation flow is calculated using
Equation 7 defined below:
Equation 7
Sr = X*(627-(1-0.0345)*(0.364+0.144+0.229+0.52))
Where:
X = geometric parameter calculated based on the following equation:
Equation 8
X = (1+0.094*(D-3.65))*(1+0.0009*(E-120))*(1+0.0006*(F-150))
Where:


F = visibility to the left in metres
In situations where the major arm has a central reservation the minor to major give-way straight
ahead (Movement H) saturation flow is calculated using Equation 9 defined below:
Equation 9
Sr = X*(627+(14*Wcr)-(1-0.0345)*(0.364+0.144+0.229+0.52))
Where:
X = as defined in Equation 8
Wcr = width of the central reservation in metres
The minor to major give way right turn (Movement I) saturation flow is calculated using
Equations 7 and 8 defined above.
In situations where the major arm has a central reservation the minor to major give way right
turn (Movement I) saturation flow is calculated using Equations 8 and 9 defined above.
The default saturation flow values for unopposed movements are similar to those for signalised
junctions with the exception of right turns since right turns would tend to be tighter at signalised
junctions than an equivalent priority junction with the same layout, due the stopline being further
forward at a signalised junction.
A suggested set of generic turning radii for priority junctions is shown in Table 7 below.
Turn Radius Left Turning Movement Right Turning Movement
Tight 5 5
Standard 10 10
Wide 20 20
Table 7: Priority Junctions – Range of Turn Radii (metres)
Applying these standard turn radii would result in the following set of saturation flows for priority
junctions for a range of wide to narrow roads. The saturation flows are rounded to the nearest
10 pcus.
Turn Radius 1 Lane 2 Lanes 3 Lanes 4 Lanes

Left Right Left Right Left Right Left Right
Inc Exc Inc Exc Inc Exc Inc Exc Inc Exc Inc Exc
Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns Ns
Single Lane
Tight 1530 1530
Standard 1730 1730
Wide 1850 1850
Multiple Lanes
Tight 1480 1480 3060 na 3060 3430 4640 na 4640 4750 6220 na 6220 6330
Standard 1670 1670 3460 na 3460 3580 5240 na 5240 5370 7030 na 7030 7150
Wide 1790 1790 3700 na 3700 3920 5610 na 5610 5740 7520 na 7520 7650

Table 8: Priority Junctions – Range of Unopposed Turn Saturations Flows (PCU’s per
hour)
For the opposed and give-way movements, assuming a standard visibility set to 120 metres to
the left and 150 metres to the right, poor visibility with a 50% reduction, good visibility with a
50% increase, and a range of different road widths the saturation flows for a 1 lane approach
and a 2 lane approach are provided in Table 9 and Table 10Table below. As described under
Section 3.2 above for one lane approaches the standard lane width is assumed to be 3.65m.
For two or more lane approaches the standard lane width is assumed to be 3.00m.
Minor to Major Give-Way (G) Major to

Minor (X)
Geometric Data Left Ahead Right Right
Without CR With CR Without CR With CR
Poor visibility (to left 60m and to right 75m)
Narrow Lane (2.5m) 640 510 540 510 540 610
Standard Lane (3.65m) 720 570 620 570 620 680
Wide Lane (4.5m) 780 620 680 620 680 730
Average visibility (to left 120m and to right 150m)
Narrow Lane (2.5m) 690 570 600 570 600 670
Standard Lane (3.65m) 770 640 690 640 690 760
Wide Lane Width (4.5m) 830 690 760 690 760 820
Good visibility (to left 180m and to right 225m)
Narrow Lane (2.5m) 730 630 660 630 660 740
Standard Lane (3.65m) 820 700 760 700 760 830
Wide Lane (4.5m) 880 760 830 760 830 900
Table 9: Priority Junctions – Give-Way and Opposed Turn Saturations Flows for 1 lane
approaches (PCU’s per hour)
NB: CR = Central Reserve

Minor to Major Give-Way (G) Major to

Minor
(X)
Geometric Left Ahead Right Right
Data Without CR
With CR Without CR With CR
Poor visibility (to left 60m and to right 75m)
Narrow Lane 1280 1020 1070 1020 1070 1210
(2.5m)
Standard 1350 1070 1140 1070 1140 1270
Lane (3m)
Wide Lane 1550 1230 1360 1230 1360 1460
(4.5m)
Average visibility (to left 120 metres and to right 150 metres)
Narrow Lane 1370 1130 1190 1130 1190 1340
(2.5m)
Standard 1440 1190 1270 1190 1270 1420
Lane (3m)
Wide Lane 1660 1370 1510 1370 1510 1630
(4.5m)
Good visibility (to left 180m and to right 225m)
Narrow Lane 1460 1250 1320 1250 1320 1480
(2.5m)
Standard 1540 1310 1400 1310 1400 1560
Lane (3m)
Wide Lane 1760 1510 1660 1510 1660 1800
(4.5m)
Table 10: Priority Junctions – Give-Way and Opposed Turn Saturations Flows for 2 lane
approaches (PCU’s per hour)
4.4. Roundabouts
Roundabout capacity is based on a range of ARCADY based roundabout capacities which take
into account the following physical characteristics:
 Inscribed circle diameter
 Approach half width
 Entry Width
 Flare Length
 Entry Angle
 Entry Radii
Table 11 provides the characteristics of the different roundabouts types for a range of different
approach lane widths.

Roundabout Lane Approach Entry Flare Entry Inscribed Entry

Type Width Width (m) Width Length Radii Diameter Angle
(m) (m) (m) (m) (degrees)
Mini roundabout Narrow 3.00 3.00 0.1 7 20 35

Standard 3.65 3.65 0.1 7 20 35
Wide 4.50 4.50 0.1 7 20 35
1 lane approach Narrow 3.00 6.00 12 15 50 35
2 lanes at stop
Standard 3.65 7.30 12 15 50 35
line with flare
Wide 4.50 9.00 12 15 50 35
3 lanes at stop
Standard 3.65 10.95 12 15 50 35
line with flare
Wide 4.50 13.50 12 15 50 35
2 lane approach Narrow 6.00 6.00 0.1 25 70 35
2 lanes at stop
Standard 7.30 7.30 0.1 25 70 35
line
Wide 9.00 9.00 0.1 25 70 35
3 lanes at stop
Standard 7.30 10.95 12 25 70 35
line with flare
Wide 9.00 13.50 12 25 70 35
3 lane approach Narrow 9.00 9.00 0.1 30 80 35
3 lanes at stop
Standard 10.95 10.95 0.1 30 80 35
line
Wide 13.50 13.50 0.1 30 80 35
Table 11: Roundabouts – Generic Geometric Parameters
Within SATURN saturation flows are applied at an entry level not for the individual turn and the
entry capacity will be the same for each turn from a given arm. GAPR values will are
calculated by dividing 3,600 by the circulating capacity. The GAPR values are defined in tenths
of seconds for individual junctions. Recommended ‘starting’ GAPR values are found in Table
12. It should be noted that these may require local adjustments during the calibration stage.
Table 12 provides the modelling parameters assumed for each roundabout type for each of the
approach widths defined in Table 11.
For unbalanced approach arms, the maximum circulating capacity should be undertaken for the
whole roundabout. For example, if we have 3 approaching arms, two of them have 2 lanes
approach 2 lanes at the stop line, and the third arm has 2 lanes approach 3 lanes at the stop
line, then the circulating capacity for the whole roundabout is 4120 pcus/h (assuming standard
lane width). The GAPR would be calculated as 0.9s.

Roundabout Type Lane Circulating GAP Entry Circulating

Width Time Value Capacity Capacity
mini roundabout Narrow 5 2.0 820 1820

Standard 5 1.8 990 2050
Wide 5 1.6 1220 2300
1 lane approach 1 lane at Narrow 10 2.0 920 1830
stop line with no flare Standard 10 1.6 1,100 2250
Wide 10 1.6 1380 2310
1 lane approach 2 lanes at Narrow 10 1.4 1370 2560
stop line with flare Standard 10 1.3 1620 2770
Wide 10 1.2 1920 3000
Wide 10 1.2 2100 3110
1 lane approach with 4 Narrow 10 1.2 2170 3100
lanes at stop line with flare Standard 10 1.5 2450 3200
Wide 10 1.0 3250 3590
stop line Standard 15 1.0 2200 3780
Wide 15 0.9 2710 4090
Wide 15 0.8 3330 4380
Wide 15 0.8 4010 4600
Wide 17 0.7 4090 4970
Wide 17 0.7 4760 5150
Table 12: Roundabouts – Range of Saturation Flows (PCU’s per hour) and GAP values
In terms of roundabout types there are two options within SATURN: to allow or ban U turns at
the junction. To provide a consistent approach it should be assumed that U-turns are banned for
mini roundabouts and allowed for all other roundabouts.
4.5. Gyratories and ‘Exploded’Roundabouts

Whilst gyratories on the highway network (for example, at motorway junctions) are, in effect,
large roundabouts, it is not recommended that roundabout coding standard (e.g. saturation
flows, GAPR values) be used at these locations. Also, there is not an option within SATURN to

code signalised roundabouts as a single node, and therefore these junctions need to be
represented as a series of signalised junctions.
Typically, expanded roundabouts are modelled as a series of either priority or signalised

junctions in order to represent both the complex layout and traffic interactions that take place at
these locations. Within SATURN, standard roundabout node coding is treated differently under
the assignment and simulation algorithms from that of priority or signalised junctions, tending to
require lower saturation flows in order to better match capacities and delays from the separate
ARCADY simulation software.
As a result, it is not recommended that roundabout saturation flows or GAP values are used for
‘exploded’ roundabouts or gyratories, as these will tend to underestimate capacities. Instead, it
is recommended that at an exploded gyratory the saturation flows given in Table 13 and 14
should be applied for the signalised junction and priority junctions respectively. A global
standard GAP value may be coded in the beginning, which may need to be refined during
model calibration and validation stage.
When coding a signalised roundabout or gyratory it is important to consider the coordinated

nature of the signal timings and phases at the junction. The use of signal timing offsets at these
junctions should be considered to represent the coordination of the individual signalised
junctions which make up the roundabout of gyratory.
The preferred approach to coding the links within gyratories and ‘exploded’ roundabouts should
be to code as fixed speeds as opposed to variable speed-flow curves. These fixed speeds
should represent the likely speed of travel approaching and circulating a junction, and not the
speed limit itself. A speed of 48kph will be used to represent fixed speed on gyratory and
‘exploded’ roundabout junction links in the RTMS. In certain circumstances (e.g. very large
roundabouts with long, straight links) fixed speed may deviate from this and in such case, any
changes should be documented.
Approach Arm Circulating Arm

left turn 2 3 4 1 lane 2 lanes 3 lanes 4 lanes
lane only lanes lanes lanes
Inc Ns Inc Inc Inc Ns Os Inc Exc Inc Exc Inc Exc
Ns Ns Ns Ns Ns Ns Ns Ns Ns
Narrow Lane
1,780 3690 5600 7510 1840 1970 3800 3940 5770 5910 7740 NA
(2.5m)
Standard
1,830 3790 5740 7700 1880 2020 3900 4040 5920 6060 7940 NA
(3m)
Wide Lane
1,970 4070 6170 8270 2030 2170 4200 4330 6360 6500 8530 NA
(4.5m)
Table 13: Exploded Signal Controlled Roundabout Saturation Flow Values (PCU’s per
hour)
Approach Arm Circulating Arm

left turn 2 3 4 1 lane 2 lanes 3 lanes 4 lanes
lane only lanes lanes lanes
Inc Ns Inc Inc Inc Ns Os Inc Exc Inc Exc Inc Exc
Ns Ns Ns Ns Ns Ns Ns Ns Ns
Standard
1250 2500 3750 5000 1880 2020 3900 4040 5920 6060 7940 NA
(3m)
Table 14: Exploded Roundabout Priority Controlled Saturation Flow Values (PCU’s per
hour)

4.6. Motorway Main Carriageway and Slip Roads
The proposed network coding methodologies for motorway main carriageways and slip roads
are discussed in Section 4. The saturation flows for these movements are defined based upon
the same principles as discussed above.
The saturation flows for motorway link main carriageways have been calculated using Equation
1 as defined above. The values have been based upon an assumed lane width of 3.65m
throughout. The median value has assumed a 0% gradient. The minimum value has assumed
a 5% uphill gradient and the maximum value has assumed a 5% downhill gradient. Table 15
below provides the saturation flow values to be applied in the model.
2 Lanes 3 Lanes 4 Lanes 5 Lanes 6 Lanes
Inc Ns Exc Inc Exc Ns Inc Ns Exc Ns Inc Ns Exc Ns Inc Ns Exc
Ns Ns Ns
Min Value 3680 3820 5590 5730 7500 7640 9410 9550 11320 NA
Median Value 4100 4240 6220 6360 8340 8480 10460 10600 12580 NA
Max Value 4520 4660 6850 6990 9180 9320 11510 11650 13840 NA
Table 15: Motorway Main Carriageway – Saturation Flow Values (PCU’s per hour)
In Table 15 above, NS applies to Smart Motorway All Lane Running (ie, no hard shoulder) and
Exc NS applies to standard motorway. In terms of a ‘starting point’ for coding motorway
saturation flows it is recommended that the median values should be applied in the first
instance. The range of values may be required during the calibration review.
Motorway slip road saturation flows are calculated using Equation 2 defined above. The turning
radii tend to be much larger than at standard signalised or priority junctions. The median value
is assumed to be a 50m radius, the minimum value assumes a 40m radius and the maximum
value assumes a 60m radius. Lane widths are assumed to be 3.65m. Irrespective of how many
lanes there are on the slip road, in the absence of a “Ghost Island” with 2 separate merge
points, the turn saturation flow should be calculated based upon a one lane approach. This is
because traffic is effectively forced into one lane at the merge point. The only place where a
motorway slip road should have greater than 1 lane saturation flow is where a “Ghost Island” is
provided which effectively provides 2 separate merge points. The suggested saturation flows on
motorway slip roads are shown in Table 16.
Motorways 1 Lane 2 Lanes
Ns Os Inc Ns Exc Ns
Min Value 1910 2050 3960 4100
Median Value 1930 2060 3990 4140
Max Value 1940 2070 4010 NA

A roads 1 Lane 2 Lanes
Min Value
Median Value 1730 3460
Max Value
Table 16: Motorway Slip Roads – Saturation Flow Values (PCU’s per hour)
4.7. Flare Lanes
Taking account of flares at a junction is important within a SATURN network so as not to over-
or understate the likely capacity of any given junction. Ideally one would code an additional
node prior to a flared approach to model the lane increase, but in larger models this would result
in a significant increase in the number of nodes in a network, and subsequently increased
assignment run times.
The proposed method is to utilise the FLAREF (nearside lane) and FLAREX (offside lane)
markers within SATURN where the flare length is less than 10 pcus. Currently this functionality
is only available for model flared approach arms at priority and signal junctions. The saturation
flow for the flared approaches is based on the saturation flow of the midpoint of the link so that,
for example, a single lane flared to 2 lanes would be coded as one lane with a single lane
capacity with a marker F1 (in the case of a nearside flare) with the number of pcus
accommodated in the flare added as an extra line of data FF1 for example. For an offside flare,
say for a right turn opposed movement, the coding would 1F and the extra data as FX1 for
example. For an approach link with flare lane coded, there is no need to update the stack
capacity manually as the flared pcus would be added to the value derived from the following
equation in SATURN, with the parameter of LANES taken from the mid-link lane layout.
STACK =LANES *IDIST / ALEX
It is strongly recommended that if any flare length is longer than 10 pcus (approximate 60m
assuming a standard pcu axle length of 5.75m) a full separate lane should be modelled. In this
case, by default there is a tendency of overestimating link stack capacity as SATURN would
assume the total number of lanes at the downstream stop line is applied to the whole link. As
such, it may be necessary to update the stack capacity by adding the extra pcus which can be
accommodated by the flare lane (now treated as a separate lane) to the standard stack capacity
calculated from the equation above, especially where blocking back at a junction is to be
modelled in detail. Note that the sample principle of updating the link stack capacity may also be
appropriate for any flared lane approach for roundabouts.
Currently, SATURN has its limitations in modelling some complex flare lane cases, for example,
two or more flared lanes alongside the standard approach lane at a stop line for either left turn
or right turn movements. It is difficult to provide a guidance how this shall be modelled since the
method to code such a case in the model would vary case by case, though a user may consider
a number of options listed as follows:
 Case 1-code as two full separate left/right turn lanes;

 Case 2-code as 1 flare lane with total flared pcus summed from all flared lanes and
increase one lane turning saturation flow to a certain extent; and
 Case 3-code as 1 full separate left/right turn lane with standard turning saturation flow
and 1 correspondent flare lane.

In SATURN the junction performance under flared lane conditions depends on a number of
factors such as turning movement demand and interactions with other flow streams, signal
timing, stack capacity on flare lanes, and approach lane utilisation. In view of these facts it is
suggested a detailed local investigation may be required so that the best coding practice could
be applied to enhance junction performance in the area. Note that for case 1 and 3 above, the
same principle of updating link stack capacity should still be applied.
4.8. Speed Flow Relationships
Speed-flow curves are a means to represent delay on links that result from the volume of traffic
travelling along a given link, and are independent of the delays that result from individual
junctions. Speed-flow curves should not be used to represent ‘junction’ delay, and therefore
should only be used on longer links.
A general rule of thumb is that a speed-flow curve should only be applied where the majority of
the delay along a link can be attributed to the link itself rather than the junction at the
downstream end of the link. Where the majority of the delay is attributable to the junction at the
end of the link, a fixed-speed should be coded on a link, with any delays being generated by the
node coding.
Speed-flow curves should be applied on rural links in excess of 1km, including motorways. It
should be noted that in some cases some longer links may be intersected by intermediate
nodes that are included to represent nominal changes in the highway network (for example Q
nodes, Spigot Zone connectors etc). In these cases, SFCs should be applied to both sides of
the node.
4.9. Methods for representing Cruise Speeds and Fixed Speed Links
Urban Areas
Within each regional model, the cities will be key traffic generators which will need to be
represented accurately in terms of scale of demand generated and loading on to the SRN.
Where the city network is not part of the SRN there is scope to simplify the network. In the
urban areas the level of network detail required will be relatively simple compared with what
could normally be expected from a model in an urban area.
Fixed speeds are to be used in the RTM for the urban network. The speeds will be based on
Trafficmaster data split by time period. The times will take account of both link travel time and
junction delay.
This approach is compatible with TAG Unit M3.1, 2.9.8, which states that: “Cruise speeds
should not be based on speed limits but should reflect mean speeds on a link.”
This approach will provide an accurate representation of the RTM base year speeds and travel
times, however the link speeds are fixed and so there will be no response to changes in
demand in the model forecasts. Further advice will be provided on generating forecast speeds.
External Area
Speeds in the external area will similarly be taken from the Trafficmaster data to represent fixed
speeds.

Cruise Speeds
Cruise speeds should not necessarily directly relate to the speed limit on a given road. The
speed limit should form an upper bound for the coded cruise speed, but other characteristics of
the links should be accounted for when determining this value.
The choice of the cruise speed is therefore open to a certain amount of interpretation, and may
need to be revisited during the course of model calibration. Changing the choice of cruise
speeds within urban areas could be a level used to influence routeing in the model to improve
model calibration / validation, modelled journey times and to reduce ‘rat-running’.
RTM cruise speeds will be used on all links that are not subject to fixed speeds and will be
derived from Trafficmaster off-peak periods, with a formula applied to remove off-peak junction
delay.
Detail on the methodology to process Trafficmaster data to obtain fixed speeds in urban areas
and cruise speeds is included in Section 8.

4.10. Default Speed-Flow Curves

Table 17 below details the list of speed-flows curves that will be used within the model for the
car and LGV based user classes. These curves were sourced from a technical note prepared
by TAME which is included in Appendix C.
Rural
Index Description S0 S2 Capacity N
1 Rural Motorway D5 113 81 11650 2.80
2 Rural Motorway D4 113 81 9320 2.80
3 Rural Motorway D3 113 81 6990 2.80
4 Rural Motorway D3 + Dynamic Hard Shoulder 60mph 100 75 9320 4.7
5 Rural Motorway D2 113 74 4659 2.80
6 Rural All-Purpose D4 (60mph) 98 76 8397 2.75
7 Rural All-Purpose D4 50mph 80 62 8397 2.20
11 Rural All-Purpose D2 (70 mph) 112 73 4199 2.75
14 Rural WS2 10.0m A Road 93 55 1686 2.15
15 Rural S2 7.3m A Road (TD9/81) 87 58 1328 1.99
16 Rural S2 7.3m A Road (Older) 82 53 1328 2.04
17 Rural S2 A Road 40mph 64 35 1328 2.39
18 Rural S2 6.5m Poor 67 45 1010 1.79
19 Rural S2 Other Road (slow) 54 35 1328 1.53
20 Rural S2 Other Road (narrow carriageway) 82 53 950 2.11
21 Rural S2 Other Road (slow, narrow carriageway) 54 35 950 1.53
44 Rural Motorway D3 + Roadworks 80 64 5580 2.6
45 Rural All-Purpose D5 (70mph) 112 80 10,497 2.75
46 Rural All-Purpose D5 (60mph) 98 76 10,497 2.75
47 Rural All-Purpose D4 (70 mph) 112 80 8,397 2.75
48 Rural Motorway D6 113 81 13,980 2.8
50 Rural All-Purpose S3/4 (60mph) 87 58 3400 2

Suburban
22 Suburban D4 71 35 7080 1.42
23 Suburban D3 71 35 5310 1.42
24 Suburban D2 (slight development) 75 35 3540 2.56
25 Suburban D2 (typical development) 71 35 3540 1.42
26 Suburban D2 (heavy development)1 58 35 3540 0.93
27 Suburban D2 (30mph) 48 30 3540 1.28
28 Suburban S4 (slight development) 54 25 3400 2.00
29 Suburban S4 (typical development) 54 25 2500 2.00
30 Suburban S2 (50mph) 71 35 1680 1.52
31 Suburban S2 (light development) 65 25 1680 2.63
32 Suburban S2 (typical development) 61 25 1680 1.58
33 Suburban S2 (heavy development) 58 25 1680 1.03
34 Suburban S2 (30mph) 48 25 1680 1.28
1
Use No.26 for 40mph dual section
Urban
35 Urban Non-central 50% development 48 30 896 2.22
36 Urban Non-central 80% development 48 25 896 1.49
37 Urban Non central 90% development 46 25 896 1.25
38 Urban Central INT = 2 37 15 944 1.51
39 Urban Central INT = 4.5 33 15 944 1.19
40 Urban Central INT = 9 28 15 896 0.72
Small town
41 Small Town 35% development 63 32 1344 2.91
Miscellaneous
99 Buffer Zone Connectors 70 50 10000 1.39
Table 17: Speed/Flow Relationships
Note: Speeds are given in kph
Capacity and breakpoint flows are given in pcu
4.11. HGV Free Flow Speeds

The speed limits for HGV's on single and dual carriageways increased on April 6th 2015. For
HGVs weighing more than 7.5 tonnes and travelling on a single carriageway, the speed limit
has increased from 40 to 50 mph, removing the 20-mph difference between HGV and car speed
limits. For HGVs weighing more than 7.5 tonnes and travelling on a dual carriageway, the speed
limit increase from 50 to 60 mph

Speed limits in Scotland remain unaffected.
In order to represent the restricted maximum speed for HGV’s on the highway network it is
necessary to reduce the maximum (free flow) speed available to the HGV userclass in the
model. This will be achieved using the CLICKS facility within Saturn.
4.12. Gap Acceptance

The standard default value of GAP set by SATURN is 5 seconds at priority and signal junctions.
This is considered too high (but is often left as such for mainly historic reasons) and results in
SATURN under-estimating capacities, and should be replaced by more appropriate local
values. This can either be done globally (using GAP for priority and signal junctions, GAPR for
roundabouts – SATURN default 4 secs and GAPM for merges – SATURN default 3 secs), for
each individual junction, or even for each separate turn.
The values for these can be taken from a linear relationship between gap acceptance and
saturation flow of the controlling arm, as with programs such as ARCADY. To get the same
relationship in SATURN the manual recommends that GAP is set to 1/Vm, where Vm is the
saturation flow of the controlling arm. Whilst this would be relatively simple to calculate, it would
add an extra level of complexity to the model, but may not necessarily improve the quality of the
model.
4.13. Capacity Reductions for Merges

To apply capacity reductions and delays for situations where traffic merge into a reduced
number of lanes, two different approaches are considered as described below.
For example, two lanes merging in to a single lane can be coded as:
 Code a node at the merge point in which the upstream link has two lanes and a speed-flow
curve for a dual carriageway. The node ‘stopline’ would have two lanes coded but the
saturation flow would be reduced to represent one lane. The downstream link would be
coded as a single carriageway.
 Code a node at the merge point in which the upstream link has one lane and a speed-flow
curve for a dual carriageway. The node ‘stopline’ would have one lane coded with
saturation flow of one lane but would be coded with stacking capacity for two lanes to
represent additional space available on dual carriageway. The downstream link would be
coded as a single carriageway.
Second approach is preferred for coding Strategic Road Network where possible. If alternative
approach is used for coding this situation and shows any issues at calibration/validation stage,
detail coding as described above should be used at calibration/validation stage.

5. Motorway Network Coding
5.1. Introduction
The sections below describe the different motorway merge and diverge options and how these
will be represented in the SATURN simulation network. The figures and tables include
descriptions of any turn priority markers applied, sources of link length data, the number of
lanes on each link and an assumed minimum, median and maximum saturation flow which are
extracted from Table 15 and Table 16 above. As noted in section 4.6, the median values of
saturation flows should be applied in the first instance for coding motorway merge and diverge.
The range of values may be required during the calibration review.
As can be seen it is proposed to use Q turn priority markers at motorway merges. These are
used, in combination with merge markers (except for lane gain type of merge) at the motorway
slip road merges to represent delays on slip roads and on the main carriageway. It is also
proposed to apply a negative stacking capacity at the Q-Node in order to “break the chain” of
SATURN links and ensure that queuing propagates back from the Q-Node rather than from the
downstream node.
The default distance for placing Q turn priority markers at motorway merges in the Regional
Traffic Models should be set at 300m as a standard value to ensure a network coding
consistency across all the models, as well as to avoid a network coder to measure every merge
section which may lead to bias due to individual’s judgement. The distance, however, may be
subject to change due to the calibration and validation stage, if blocking-back occurs
unrealistically on a merge section especially for parallel merge and lane gain merge as
illustrated in Figure 3 and Figure 5 below.
This guidance covers how the node structure and saturation flow would be coded for 6 common
motorway merge types in the UK, as follows:
 Taper merge
 Parallel merge
 Merge with ghost island
 Standard lane gain merge
 Lane gain with ghost island merge V1 (merge then lane gain)
 Lane gain with ghost island merge V2 (lane gain then merge)
If the motorway merge is formed as not one the types above, professional advice needs to be
sought to decide how the merge section should be coded in the regional models, taking
account of in particular the effective number of lanes at the merge itself.
5.2. Motorway Merge Coding

The following approach, using taper merge as for an example, should be applied to Strategic
Road Network merge coding:
 Apply a merge turn priority marker “M”” at Node 1003 on the slip-road link from Node
1001.
 Position a node (Node 1004) 300 metres downstream of the merge point for motorways.
 Apply a ‘Q’ turn priority marker at Node 1004, the total number of lanes from 1003 to
1004 is 4, with a standard D4M speed flow curve applied if appropriate.

 The turning capacity of 1003-1004-1005 should be coded as 3 lanes with a saturation

flow of 6220 PCUs/hr (median value including nearside lane according to Table 15), a
value to match the downstream motorway mainline lane definition.
There have been some discussions during M23 & M20 SMP work on whether both “M” and “Q”
marker should be applied in the taper merge example above since there were concerns that this
might lead to over-estimated delays. However this tends to be very theoretical and is not based
on actual comparisons with real data. By using the SATURN standard formulation and
parameters, the maximum delay in association with Q node, when link arriving flow equals to
link capacity, is 56.5s/PCU. This turns to under-estimate merge delay, and as such the use of
“M” marker might be quite justified. However, if during model calibration and validation stage
this causes excessive delays, then the “M” marker could be removed to see if this helps to
improve the model performance at the merge section.
Note that for all 5 types of motorway merges, the link (i.e. 1003-1004) on motorway mainline
approaching to the Q node defined should always be coded as 4 lanes. It is recognised that this
may result in some inconsistency between the mid-link and downstream turning capacity. In the
taper merge example above, the mid-link capacity of 1003-1004 is 9320 PCUs/hr (in
accordance with the speed-flow curves set out in Table 17), whereas the turning capacity at the
Q node (1003-1004-1005) is 6220 PCUs/hr. This, however, would have little impact on
SATURN assignment as the program would take the downstream turning capacity as the
constraint to derive the link capacity; hence in this case the link capacity would be reduced to
6220 PCUs/hr. The only differences are the less travel time related to the SFC if applied and
more stack capacity for D4M than D3M. But as the link distance of 1003-1004 is relatively short
their impacts would be negligible. We understand that this may result in some overestimated
stack capacity for taper merge. But given the fact that in a congested travel condition the merge
lane would also provide some extra space for the vehicles merging from the slip road therefore
the overall stack capacity would still be greater than a standard 3 lane motorway sections.
In the absence of an extended or ‘tiger-tail’ merge at Node 1003, link 1001-1003 should be
coded based on the actual layout. Sometimes a long stretch of a slip-road may have 2 lanes,
therefore the motorway slip-road itself would have 2 lane mid-link capacity but with a merge
saturation flow equivalent to a single lane slip-road of 1,930 PCUs/hr. This is due to the fact that
despite the slip-road having two lanes, traffic effectively is forced into a single lane at the merge
itself. A merge saturation flow equivalent to a 2-lane slip-road should only be coded where there
are two distinct merge locations where each lane joins the main carriageway.

Taper Merge – Assumes 3 lane main carriageway
Figure 3: Taper Merge Schematic Diagram (Source: TD22/06)
Figure 4: Taper Merge Node and Link SATURN Coding
Saturation flows
pcus per hour
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
Link
Onslip at merge 1001 1003 1004 M 1/2 1-1 1910 1930 1940
Main 1002 1003 1004 3 1-3 5590 6220 6850

carriageway at
merge
Main 1003 1004 1005 Q 300m 4 1-3 5590 6220 6850
Carriageway at
Q node
Table 18: Taper Merge Node and Link SATURN Coding

Parallel Merge – Assumes 3 lane main carriageway
Figure 5: Parallel Merge Schematic Diagram (Source: TD22/06)
Figure 6: Parallel Merge Node and Link SATURN Coding
Saturation flows
pcus per hourour
Link
Onslip at merge
1001 1003 1004 M 1/2 1-1 1910 1930 1940
Main
carriageway at 1002 1003 1004 3 1-3 5590 6220 6,850
merge
Main
carriageway at Q 1003 1004 1005 Q 300m 4 1-3 5590 6220 6850
node
Table 19: Parallel Merge Node and Link SATURN Coding

Merge with Ghost Island – Assumes 3 lane main carriageway
Figure 7: Merge with Ghost Island Schematic Diagram (Source: TD22/06)
Figure 8: Merge with Ghost Island Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Onslip at ghost
1001 1003 1005 2 1-1 1910 1930 1940
island
Onslip at ghost
1001 1003 1004 2 2-2 2050 2060 2070
island
Onslip at first
1003 1004 1005 M 1 1-1 1910 1930 1940
merge
Main
carriageway at 1002 1004 1005 3 1-3 5590 6220 6850
first merge
Onslip at second
1003 1005 1006 M 1 1-1 1910 1930 1940
merge
Main
carriageway at 1004 1005 1006 3 1-3 5590 6220 6850
second merge
Main
Carriageway at 1005 1006 1007 Q 300m 4 1-3 5590 6220 6850
Q node
Table 20: Merge with Ghost Island Node and Link SATURN Coding

Lane Gain – Assumes 3 lane main carriageway widening to 4 lane main carriageway
Figure 9: Lane Gain Schematic Diagram (Source: TD22/06)
Figure 10: Lane Gain Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Onslip at merge
1001 1003 1004 1/2 1-1 1910 1930 1940
Main carriageway
1002 1003 1004 3 1-3 5590 6220 6850
at merge
Main carriageway
1003 1004 1005 Q 300m 4 1-4 7500 8340 9180
at Q node
Table 21: Lane Gain Node and Link SATURN Coding

Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain) – Assumes 3 lane main
carriageway widening to 4 lane main carriageway
Figure 11: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain) Schematic
Diagram (Source: TD22/06)
Figure 12: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain) Node and Link
SATURN Coding
Saturation flows
Link
Onslip at ghost
1001 1003 1005 2 1-1 1910 1930 1940
island
Onslip at ghost
1001 1003 1004 2 2-2 2050 2060 2070
island
Onslip at first
1003 1004 1005 M 1 1-1 1910 1930 1940
merge
Main
carriageway at 1002 1004 1005 3 1-3 5590 6220 6850
first merge
Onslip at second
1003 1005 1006 1 1-1 1930 1930 1940
merge
Main
carriageway
1004 1005 1006 3 1-3 5590 6220 6850
(between merges
merge)
Main
Carriageway at Q 1005 1006 1007 Q 300m 4 1-4 7500 8340 9180
node
Table 22: Lane Gain with Ghost Island Merge V1 (Merge then Lane Gain) Node and Link
SATURN Coding

Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge) – Assumes 3 lane main
carriageway widening to 4 lane main carriageway
Figure 13: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge) Schematic
Diagram (Source: TD22/06)
Figure 14: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge) Node and Link
SATURN Coding
Saturation flows
Link
Onslip at ghost
1001 1003 1005 2 1-1 1910 1930 1940
island
Onslip at ghost
1001 1003 1004 2 2-2 2050 2060 2070
island
Onslip at first
1003 1004 1005 1 1-1 1910 1930 1940
merge
Main carriageway
1002 1004 1005 3 1-3 5590 6220 6850
at first merge
Onslip at second
1003 1005 1006 M 1 1-1 1930 1930 1940
merge
Main carriageway
1004 1005 1006 4 1-4 7500 8340 9180
(between merges)
Main Carriageway
1005 1006 1007 Q 300m 4 1-4 7500 8340 9180
at Q node
Table 23: Lane Gain with Ghost Island Merge V2 (Lane Gain then Merge) Node and Link
SATURN Coding

5.3. Motorway Diverge Coding
Taper Diverge – Assumes 3 lane main carriageway
Figure 15: Taper Diverge Schematic Diagram (Source: TD22/06)
Figure 16: Taper Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Turn Anode Bnod Cnode Marker Link Lanes Turnin Min Media Max
e Lengt Per g Value n Value
h Link Lanes Value
Offlslip at diverge 2001 2002 2003 3 1-1 1910 1930 1940
Main carriageway
2001 2002 2004 3 1-3 5590 6220 6850
at diverge
Table 24: Taper Diverge Node and Link SATURN Coding

Parallel Diverge – Assumes 3 lane main carriageway
Figure 17: Parallel Diverge Schematic Diagram (Source: TD22/06)
Figure 18: Parallel Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Main carriageway
at intermediate 2001 2002 2003 3 1-3 7500 8340 9180
node
Offslip at diverge 2002 2003 2004 4 1-1 1910 1930 1940
Main carriageway
2002 2003 2005 4 2-4 5730 6360 6990
at diverge
Table 25: Parallel Diverge Node and Link SATURN Coding

Ghost Island Diverge – Assumes 3 lane main carriageway
Figure 19: Ghost Island Diverge Schematic Diagram (Source: TD22/06)
Figure 20: Ghost Island Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Offslip at first
2001 2002 2004 3 1-1 1910 1930 1940
diverge
Main carriageway
2001 2002 2003 3 1-3 5590 6220 6850
at first diverge
Offslip - second
2002 2003 2004 3 1-1 1910 1930 1940
diverge
Main carriageway
2002 2003 2006 3 1-3 5590 6220 6850
at second diverge
Offslip after ghost
2002 2004 2005 1 1-1 1910 1930 1940
island
Offslip after ghost
2003 2004 2005 1 1-1 1910 1930 1940
island
Table 26: Ghost Island Diverge Node and Link SATURN Coding

Lane Drop at Taper Diverge – Assumes 4 lane main carriageway dropping to 3 lane main
carriageway
Figure 21: Lane Drop at Taper Diverge Schematic Diagram (Source: TD22/06)
Figure 22: Lane Drop at Taper Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Offlslip at diverge 2001 2002 2003 4 1-1 1910 1930 1940
Main carriageway
2001 2002 2004 4 2-4 5730 6360 6990
at diverge
Table 27: Lane Drop at Taper Diverge Node and Link SATURN Coding

Lane Drop at Parallel Diverge – Assumes 4 lane main carriageway dropping to 3 lane
main carriageway
Figure 23: Lane Drop at Parallel Diverge Schematic Diagram (Source: TD22/06)
Figure 24: Lane Drop at Parallel Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Main carriageway
at intermediate 2001 2002 2003 4 1-4 7500 8340 9180
node
Offslip at diverge 2002 2003 2004 5 1-2 3960 3990 4010
Main carriageway
2002 2003 2005 5 3-5 5730 6360 6990
at diverge
Table 28: Lane Drop at Parallel Diverge Node and Link SATURN Coding

Lane Drop Ghost Island Diverge – Assumes 4 lane main carriageway dropping to 3 lane
main carriageway
Figure 25: Lane Drop Ghost Island Diverge Schematic Diagram (Source: TD22/06)
Figure 26: Lane Drop Ghost Island Diverge Node and Link SATURN Coding
Saturation flows
pcus per hour
Link
Offslip at first
2001 2002 2004 4 1-1 1910 1930 1940
diverge
Main carriageway
2001 2002 2003 4 2-4 5730 6360 6990
at first diverge
Offslip - second
2002 2003 2004 3 1-1 1910 1930 1940
diverge
Main carriageway
2002 2003 2006 3 1-3 5590 6220 6850
at second diverge
Offslip after ghost
2002 2004 2005 1 1-1 1910 1930 1940
island
Offslip after ghost
2003 2004 2005 1 1-1 1910 1930 1940
island
Table 29: Lane Drop Ghost Island Diverge Node and Link SATURN Coding

6. Zone Connectors
Centroid connectors are the means by which demand from a zone loads onto the network. The
location and coding of these locations can have a significant influence on the performance of
the base year network against observed counts and journey times.
The following types of zone connectors can be modelled in SATURN.
 Spigots – which are generally used for small zones within an urban area. WebTAG
guidance advises that they should be used for zones with no greater than 200-300
vehicles per hour. The disadvantage of these is the requirement to code an additional
two simulation nodes thereby increasing run time.
 Spanning connectors – these are used to load trips from a sparse, large area across a
link. These should be used with care since they can cause issues during model
calibration, in particular at locations where traffic counts exist.
 Buffer connectors - these perform in a similar way to standard buffer links. They have
speed and distance applied which is taken into account in routing. These are more
suitable for strategic models which tend to have larger zones particularly in rural areas.
 The advice for the RTMs is to not use too many ‘spigot’ style connectors. The principle
should be a focussed and limited use of centroid connectors.

7. Bus Routes
Bus routes are generally defined in SATURN using fixed demand and routes.
Given the urban areas in the Regional Models will be coded in less detail and the level of bus
services using the SRN (the main area of interest) is small, the preferred approach is not to
model fixed route buses. This approach may need to be reviewed in areas where bus demand
may affect junction capacity and this should be reviewed on a case by case basis.

8. Trafficmaster Data
8.1. Introduction
Trafficmaster GPS navigation devices record the time taken for vehicles to travel along
individual links in the Integrated Transport Network. Around 100,000 vehicles in the whole of the
UK have Trafficmaster devices fitted. The data are available to consultants to calculate journey
times for particular routes, which can then be compared with model times for the equivalent
route.
This section summarises what raw data are available and how they are used to calculate
journey times, limitations of the data, and what further developments could be made.
Trafficmaster data is to be used for:
 Deriving fixed speeds in urban areas

 Deriving Cruise Speeds
 Average peak hour journey times for model validation
8.2. Data Available

Vehicle times are recorded in time periods of 15 minute intervals – that is, the time a vehicle
was tracked can be narrowed down to a 15 minute period on a particular day. Data are split by
vehicle type, with separate vehicle classes for HGVs weighing below or above 7500kg.
Each record in the raw data provided indicates the journey times of vehicles of a given type, on
a given link, in a given 15 minute time period. The cumulative time of all such vehicles is
provided, along with the number of vehicles in that observation. Times are provided to the
nearest 100th of a second. Data are provided in csv format for monthly intervals, with each
month of data typically around 750MB in size.
8.3. Journey Time Calculations

Typically Trafficmaster data are used to assess journey times for particular routes, to act as an
‘observed’ journey time. For a given time period, a mean journey time is calculated. A journey
time for an individual route is formed by summing average times for each individual link on that
route. This can be done for individual vehicle classes, any combination of vehicle classes or for
all vehicles. Typically journey times are calculated for weekdays in a neutral month.
Average speeds of vehicles along individual links or for the whole routes are calculated by
dividing the link length (provided from the GIS layer) by the average time taken for vehicles to
traverse that route or link.
8.4. RTM Data Processing

A technical note describing process for deriving the fixed speeds from Trafficmaster JT
database and summary of the outputs resulting from the process is attached in Appendix D.

Appendix A
Signalised Junction Template Coding Technical Note

A.1 Introduction
Highways England have commissioned 5 regional traffic models (RTMs) covering the Strategic
Road Network (SRN) across England. The scale and nature of these models mean that the
approach to represent the highway network has to be proportionate. As a result, the Network
Technical Consistency has agreed that a simplified approach especially in the areas away from
SRN and the region of focus will need to be used.
With the SATURN modelling software, the network can be coded as either ‘buffer’ or
‘simulation’. Areas within buffer would be coded with speed flow curves (SFC). Areas in
simulation have detailed junction coding to calculate delays, and can also account for delays
along longer links where SFC is coded.
Simulation coding is more detailed and provides a higher level of accuracy, but is more relevant
to areas of the network which include all, or most, significant roads. Increasing the extent of
simulation coding must be considered in the context of increased model preparation and run
times.
The approach adopted for the RTMs targets the main areas of focus for simulation coding in the
model, and applies templates for capacities and signal timings at those junctions which are
coded in simulation. As buffer network areas do not account for junction delays, it is not
necessary to include signal timings for areas within buffer network.
It should be noted that at the time of producing this note, there is some debate amongst the
RTM teams about the extent of simulation coding within the models. This note takes that debate
into account where appropriate.
Even though it is not feasible to collect phasing and timing information for all the signalised
junctions in the vast model areas which form RTMs, an exercise is being undertaken by RTMs
developers to request such information for selected junctions which depending upon when it
can be made available, can be used for either coding of such junctions or used as a
check/refinement during calibration / validation stage.
The remainder of this note discusses the issues associated with network coding in various
locations, and provides some template timings for those situations.
A.2 Junctions on the SRN
The following junctions may be observed on the SRN. These have cycle times and green splits
adjusted to give priority to strategic traffic over local traffic. This may not always be appropriate,
but can be adjusted manually during calibration if required.
A.2.1 Major/minor crossroads

Cycle time: 120s
Stage 1: Major road. Green time 63s, intergreen 12s

Stage 2: Minor road. Green time 28s, intergreen 17s
The high intergreen for the minor road is to account for the lost time due to pedestrian crossing
the junction.

Figure A1. SRN major/minor crossroads
A.2.2 Major/major crossroads

Cycle time: 120s
Stage 1: Arms A and C. Green time 48s, intergreen 12s

Stage 2: Arms B and D. Green time 48s, intergreen 12s

Figure A2. SRN major/major crossroads
A.2.3 Large junction crossroads

Cycle time: 120s

Stage 2: Arms A and C right turns. Green time 10s, intergreen 5s
Stage 4: Arms B and D right turns. Green time 10s, intergreen 5s.

Figure A3. SRN large junction crossroads
A.2.4 Gyratories / exploded roundabouts

Cycle time: 60s
Stage 1: Arm A. Green time 25s, intergreen 5s

Stage 2: Arm B. Green time 25s, intergreen 5s
At these junctions, it may be appropriate (and, indeed, advisable) to adjust the green time offset
of adjacent nodes to ensure major flows of traffic have a consistent free-flow journey through
the gyratory as a whole.

Figure A4. SRN gyratories / exploded roundabouts
A.2.5 Other junctions

Where other junctions’ types exist, or the number of arms vary, manual adjustments should be
made on a case-by-case basis to keep within the overall dimensions (cycle time and green split)
above.
A.3 Other roads
Within urban areas/city centres, away from the SRN, the current proposal is to use networks
with fixed average speeds derived from Trafficmaster data either in buffer or simulation. If the
former approach is adopted, there will be no requirement to code signal junctions in this part of
the network. The Trafficmaster average speed data will already include downstream junction
delays, and so adding them in to the model through detailed junction simulation coding could
potentially lead to doubly counted delays in the urban areas.
In view of this, in the urban areas most junctions can be coded as priority (type 1 in SATURN),
with the turning saturation flows set to a high value (e.g. 8999 pcu/h). The potential issue of
unlimited capacity along this part of the network which can make it unduly attractive can be
overcome by introduction an adjusted SFC where the FF and capacity speed are defined the
same as that of Trafficmaster with appropriate link capacity and the N power set to zero.
There would be no need to code any priorities or detailed approach lane allocation, but the local
traffic management such as banned turns or one-way roads should be considered in the
junction coding.

Rural roads away from the SRN are currently proposed to be coded in simulation, and will need
signal junctions to be coded where appropriate, with the template timings suggested below.
Whilst it is not possible to define templates for all potential junctions as some will be too
complex, in locations such as the transition areas from detailed SRN network to urban or rural
area where detailed simulation junction coding is required, the priority and roundabout junctions
should be coded following the guidelines set out in the RTM network coding manual.
However, as the actual signal timings may not be available in many locations, the proposed
general principles for signalised junctions are shown below. Note that the lane allocations will
still need to be coded in detail based on actual junction layout observed from aerial photos.
A.3.1 Major/minor crossroads

Cycle time: 90s
Stage 1: Major road. Green time 43s, intergreen 7s

Stage 2 : Minor road. Green time 23s, intergreen 17s
The high intergreen for the minor road is to account for the lost time due to pedestrian crossing
the junction.
Figure A5. Urban major/minor crossroads
A.3.2 Major/major crossroads

Cycle time: 90s

Figure A6. Urban major/major crossroads
A.3.3 Large junction crossroads

Cycle time: 120s

Stage 2: Arms A and C right turns. Green time 10s, intergreen 5s
Stage 4: Arms B and D right turns. Green time 10s, intergreen 5s.

Figure A7. Urban large junction crossroads
A.3.4 Gyratories / exploded roundabouts

Cycle time: 60s
Stage 1: Arm A. Green time 25s, intergreen 5s

Stage 2: Arm B. Green time 25s, intergreen 5s
At these junctions, it may be appropriate (and, indeed, advisable) to adjust the green time offset
for adjacent nodes to ensure major flows of traffic have a consistent free-flow journey through
the gyratory as a whole.

Figure A8. Urban gyratories / exploded roundabouts
A.3.5 Other junctions

Where other junctions’ types exist, or the number of arms vary, manual adjustments should be
made on a case-by-case basis to keep within the overall dimensions (cycle time and green split)
above.

Appendix B
Coding Gyratories

B.1 Introduction
This technical note sets out to explain the issues encountered when defining the network structure
around gyratory at Highways England’s Strategic Road Network (SRN). Advice is sort on the
common coding practice to ensure a degree of consistency across all the regional models.
The issue surrounds whether to code as a single node or to explode the junction into many nodes.
Is there a geographical difference to how this should be applied? There are advantages and
disadvantages to both in each case. Below are three examples.
B.2 An example of junction coding at M25 J28
M25 J28 is a 5-arm signalised gyratory (roundabout), with separated mainline M25 and A12
running through the junction. Four of the approaching arms are signalised, and the arm from Brook
Street is a give-way. For the M25 SB off slip approaching the junction, a dedicated left turn lane is
given for the traffic travelling eastbound to A12.
Obviously, since the majority of the arms at the gyratory is under signal control, the normal
roundabout deriving behaviour (e.g. gap acceptance) is no longer valid. As such the junction
should be exploded into a series of nodes. The question surrounding this junction is the number of
nodes to which it should be exploded into. Each arm is signalised so the approach arm joining the
roundabout should be a single node in each case. But it is uncertain whether the subsequent node
for the start of the diverging arm should be considered in this node or coded as a separate one?
Figure B1 below shows the M25 J28 junction structure generalised from ITN2Buffer tool, supplied
to all regional model teams on 28th July. It can be seen that the start of some diverging arms at
this junction is coded as separate node for A12 EB onslip, A12 WB onslip, and M25 NB onslip. It is
noticed that the link distance between the approaching node (where signal heads sit) and diverging
node is very short.
The main advantages and disadvantages for case 1 type of junction structure is shown in Table
B1. The major concern of this type of junction is the blocking back may occur at the diverging
node, especially in the forecasting years when the flows approaching the diverging node exceed its
turning capacity (as well as midlink capacity if SFC is being coded), which should not happen in
reality. In an extreme case, continuous blocking back may be the case for all the upstream
circulating nodes. As a result, the gyratory would be completely grid-locked. Although a quick
solution to this is to code this node with some artificial higher turning capacity, this is deemed as
inappropriate since it would simply remove the “true” blocking back impacts from the downstream
nodes on gyratory circulating links, and hence would underestimate the junction delays.
In view of this, after consulting SATURN development team we recommend for the example of
M25 J28 the junction should be coded as Case 2, shown in Figure B2, where the diverge node is
not explicitly coded as a separate node but consolidated into a single node into the upstream one.
Under such a structure, the unrealistic blocking back impacts would be largely removed. The
comparisons of advantages and disadvantages between Case 1 and Case 2 are shown in Table
B1.

Figure B1 Case 1: the start of diverging arm is coded as a separate node
Figure B2 Case 2: the start of diverging arm is not coded as a separate node

Table B1 Comparisons of junction node structure for case 1 and case 2

Figure B3 below shows an example of junction node structure at M20 J5, where it has been
exploded as 4 separate nodes to model the gyratory layout as given in the ITN buffer network
supplied. At this junction, whereby the capacity on the whole gyratory (roundabout) is consistent,
and there are no signals for any of the approaching arms, should this be collapsed as a single
node (As shown in Figure B4) or exploded?
We suggest that the exploded nodes should be applied for this junction, for a number of reasons:
 A better representation of the junction layout especially for the onslip and offslip roads;
 Reduce the coding efforts for forecasting years where the junction improvements may be
examined for signalising certain approaching arms;
 Accurately modelling the blocking back impact from the mainline onslip and offslip roads as
the blocking back would be extended further upstream beyond a roundabout in the current
SATURN;
 Reduce the extra effort to code dedicated left turn as the case in this example for A20 NB
approaching arm.
Note that for exploded nodes then the principle of how to code the diverging node described in
section 2 would still be applied.

Figure B3 Exploded nodes at M20 J5
Figure B4 Single node junction structure at M20 J5

Figure B5 below shows an example of dumbbell shaped junction at M20 J13, where it has been
exploded as a number of separate nodes to model the two normal roundabouts beside the M20
mainline as given in the ITN buffer network supplied. Figure B6 shows the structure of a single
node applied to each of the roundabout. We propose to code as a single node for the roundabout
in the north (as shown in case 2) and an exploded junction for the roundabout in the south (as
shown in case 1) as any future capacity issues would allow for signalisation of the junction.
Figure B5 Case 1: separate nodes coded for individual arms at M20 J13
Figure B6 Case 1: single nodes coded for two roundabouts at M20 J13

B.5 Summary
In summary it is proposed that for any SRN junctions exploded a combined single node should be
coded for the node at the end of approaching arm (e.g. the stop line) and subsequent diverge node
(e.g. leaving the gyratory), to avoid any unrealistic blocking back at the location where traffic
leaving the gyratory. In the case of dumbbell junctions where the roundabout is considered to be of
low risk of capacity constraint issues (i.e. only movements at the roundabout are to/from the
motorway slips) it could be coded as a single node. Any dedicated left filter lanes in the ITN should
remain segregated in the SATURN network and any additional nodes as a result included (For
example clockwise off slip to A12 in the M25 J28 example above) For junctions near to the SRN
but not classified as such a decision on the single node or exploded will be based upon the
inscribed diameter of the roundabout – anything greater than 60m will automatically be exploded,
equivalent to the M20 J5 example provided.

Appendix C
TAME Speed Flow Curves

Technical Note on a Proposed Update to the Speed/Flow

Curve Section of the SATURN Manual
C.1 Background
The speed/flow curves presented within the COBA11 user manual (the Design Manual for Roads
and Bridges, Volume 13) are piecewise linear functions of differing forms, by road type, and
dependent on a variety of variables to determine their gradient and intercepts. Whilst originally
used within the COBA programme for economic assessment, they have since been commonly
used as the basis for speed/flow curves used in highways assignment models.
The SATURN traffic modelling software, available from Atkins Ltd, is an example of a highway
assignment modelling package that will only accept speed flow curves in a specific format; in
SATURN’s case, the required format is a flow/delay curve rather than speed/flow curve, specified
as a power law curve of the form:
t  AV n  t 0 ,
where t is the travel time at flow V, t0 is the free flow travel time, n is the power of the flow/delay
curve and A is a variable fitted by SATURN to ensure that the curve passes through both t0 and tc,
the travel time at capacity.
Work was historically undertaken by various parties to translate the COBA curves into SATURN
power law notation and their work has been included within the SATURN manual. It has been
noted recently by the Highway Agency TAME group, however, that some of these curves have
been mis-specified due to a misunderstanding of the application of the 45kph cut-off speed within
COBA. A new translation attempt has therefore been undertaken by members of the TAME group.
C.2 Problem
The COBA11 user manual contains the mathematical descriptions of speed/flow curves for a
variety of road types. Alongside the generic mathematical descriptions are a series of
representative curves produced from the formula. The COBA11 manual goes on to state that “In
all cases the examples plotted should be seen as giving the form of a family of curves, differentiated
according to the user defined geometric characteristics of each road.” These example curves have,
however, ended up in widespread use within assignment models.
As a first step, these curves were recreated from the mathematical formula and the representative
values for the geometric variables given in the manual. Since the COBA curves are defined in
terms of vehicles, whereas SATURN uses passenger car units (pcus), the curves were then
translated to use pcus to describe the volume of flow.
To determine whether the problem truly existed, the COBA11 curves were then plotted alongside
the power law curves given within the SATURN manual. Two examples are given overleaf in
Figures 1 and 2. It should be noted that within these graphs, the SATURN curves have a ‘tail’
appended that describes the behaviour of traffic when demand exceeds capacity and queuing
occurs. This ‘tail’ is as described within Advice Note 1A1. COBA11 did not include any such tail as
the curves were used directly for economic assessment, rather than assignment. Instead, a cut-off
speed was included in the COBA11 curves. The overcapacity sections of COBA11 curve are
indicated by dotted lines within the figures and the cut-off speed is also included in the COBA11
curves within Figures 1 and 2.
1
Advice Note 1A, Department of the Environment, 1971

It was apparent from these plots that there were significant differences between the two sets of
curves, not all of which could be directly attributed to the initially assumed source of the problem;
that the 45kph cut-off had been used during the power law estimation of the COBA11 curves. It
was therefore determined that an attempt should be made to re-estimate power law
approximations for all the COBA11 curves.

Figure 1 - Comparison of COBA and SATURN Speed Flow Curves - Rural Motorways
120.0
110.0
100.0
90.0
80.0
70.0
COBA11 D2M
Speed (kph)
COBA11 D3M
COBA11 D4M
60.0
SATURN Manual D2M
SATURN Manual D3M
SATURN Manual D4M
50.0
40.0
30.0
20.0
10.0
0.0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
Carriageway Flow (pcus)
Figure 2 - Comparison of COBA SATURN Speed Flow Curves - Suburban Dual Carriageways
80.0
70.0
60.0
50.0
COBA11 DUAL CARRIAGEWAY (GOOD)

COBA11 DUAL CARRIAGEWAY (TYPICAL)
Speed (kph)
COBA11 DUAL CARRIAGEWAY (POOR)

40.0 SATURN Manual Dual (Slight Development)
SATURN Manual Dual (Typical Development)
SATURN Manual Dual (Heavy Development)
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500 3000 3500 4000 4500
C.3 Methodology
Two separate methods have been used in order to re-estimate the COBA curves. Where possible
the mathematic approach published within the SATURN manual has been adopted, reproduced
below for clarity, but where the COBA curves were tri-linear due to the minimum speed cut-off
coming in to force before the capacity threshold is reached, a least-squares approach was utilised.
The SATURN manual methodology uses three pieces of information from the COBA curve: S0, the
free flow speed; S1, the speed at the intermediate “break point” where the gradient of the curve
changes, F, and S2, the speed at capacity, C. From these, a “best-fit” value of n can be
determined by the following equation:
n  R1 * R2  1 B1  B2  1  1 ,
where:
F / C R1logR1 , 1  F / C R1 * R2 logR2 ,
B1  B2  R1  S 0 S1 , and R2  S1 S 2 .
R1  1 R2  1
The solution to the above equations was plotted alongside each COBA curve to determine
manually whether the value of n returned provided a close fit to the piecewise linear curve.
If the returned value of n did not appear to provide a close fit, judged by eye, a least squares fit
was undertaken. In this technique, a random value of n was chosen, the speed values predicted
by the power law curve, for each value of flow between 0 and C in steps of 25pcus, were
calculated and compared against the speed values predicted by the COBA 11 piecewise linear
curve. The sum of the squares of the differences was then calculated and the value of n adjusted
by a small increment until the sum of the squares of the differences was minimised. The technique
was repeated using a new random seed value of n multiple times in order to ensure that the best
value of n was chosen.
Table 1 below indicates which curves were estimated by each method.
Table 1 – Curve Estimation Method by Speed/Flow Curve
Curve Estimation Method

Rural Motorway – D4M SATURN manual
Dual Carriageway, All Purpose – D3AP SATURN manual
Dual Carriageway, All Purpose – D2AP SATURN manual
10m single carriageway (TD9/81) SATURN manual
7.3m single carriageway (TD9/81) SATURN manual
7.3m single carriageway SATURN manual
Dual Carriageway, Suburban (Good) SATURN manual
Dual Carriageway, Suburban (Typical) Least squares
Dual Carriageway, Suburban (Poor) Least squares
Single Carriageway, Suburban (Good) SATURN manual
Single Carriageway, Suburban (Typical) SATURN manual
Single Carriageway, Suburban (Poor) SATURN manual
Urban, Non-central (Good) Least squares
Urban, Non-central (Typical) Least squares
Urban, Non-central (Poor) Least squares

Urban, Central (Good) Least squares*

Urban, Central (Typical) Least squares*
Urban, Central (Poor) Least squares*
Small Town (Lightly Developed) SATURN manual
Small Town (Typically Developed) Least squares
Small Town (Heavily Developed) Least squares
*Whilst not tri-linear, it was found that the power law representation of these curves, estimated by the
SATURN Manual method, did not fit well to the actual curves so the Least squares methodology was used.
Results
The results of the re-estimation were a set of power law curves, and their associated description in
SATURN coding, that closely approximated the representative curves found within the COBA11
manual. The curves themselves are shown in this Appendix, whilst the associated SATURN
coding can be found overleaf, in Table 3. A comparison between the COBA11 curves, the existing
SATURN power law curves and the re-estimated power law curves is included in the figures below.
Suggested Amendment to the SATURN Manual

It is suggested that the SATURN Manual be amended to replace the table in Section 15.9.3 with
Table 2 below.
Table 2 – Replacement to COBA10 Speed/Flow Curve Table in the SATURN Manual

S0a S1 a S2 a Fb Cb N Description
Rural
111.8 104.6 81.4 1200 1902 2.8 D3/4M
104.8 97.6 74.4 1200 1902 2.8 D2M
100.8 94.3 73.4 1080 1714 2.8 D3AP
107.8 101.3 80.4 1080 1714 2.8 D2AP
93 70.7 56 1173 1467 2.1 S2 10m TD9/81
87.6 70 58.5 924 1155 2.0 S2 7.3m TD9/81
82.8 65.2 53.6 924 1155 2.0 S2 7.3m (Typical)
Suburban
75.8 56.2 35.9 1050 1500 2.56 Dual (slight development)
71.5 45 35 1050 1500 1.42 Dual (typical development)
68 35 35 719 1500 0.93 Dual (heavy development)
65.8 46.2 25.9 1050 1500 2.63 Single (light development)
61.5 34.9 25 1050 1500 1.58 Single (typical development)
58 25 25 1031 1500 1.03 Single (heavy development)
Urban
48 48 30.5 217 800 2.22 Non-central 50% development
48 25 25 783 800 1.50 Non-central 80% development
46.5 25 25 717 800 1.26 Non central 90% development
37 15 15 733 800 1.51 Central INT = 2
33.9 15 15 629 800 1.19 Central INT = 4.5
28.3 15 15 442 800 0.72 Central INT = 9
Small Town
63.1 54.7 32.2 700 1200 2.91 35% development
56.3 47.9 30 700 1200 2.37 60% development
46.3 37.9 30 700 1200 1.28 90% development

a
Speeds are given in kilometres per hour
b
Capacity and breakpoint flows are given in units of vehicles
It is also suggested that Table 3, overleaf, be included after Table 2, to indicate what SATURN
coding would look like in terms of pcus.
Table 3 –Additional Speed/Flow Curve Table for the SATURN Manual Showing SATURN
Coding
Speed/Flow Curve Coding Description

Rural
D 111 81 9320 S 2.80 D4M
D 111 81 6990 S 2.80 D3M
D 104 74 4659 S 2.85 D2M
D 107 80 6298 S 2.75 D3AP
D 100 73 4199 S 2.80 D2AP
D 93 55 1686 S 2.15 S2 10m TD9/81
D 87 58 1328 S 1.99 S2 7.3m TD9/81
D 82 53 1328 S 2.04 S2 7.3m (Typical)
Suburban
D 75 35 3540 S 2.56 Dual (slight development)
D 71 35 3540 S 1.42 Dual (typical development)
D 58 35 3540 S 0.93 Dual (heavy development)
D 65 25 1680 S 2.63 Single (light development)
D 61 25 1680 S 1.58 Single (typical development)
D 58 25 1680 S 1.03 Single (heavy development)
Urban
D 48 30 896 S 2.22 Non-central 50% development
D 48 25 896 S 1.49 Non-central 80% development
D 46 25 896 S 1.25 Non central 90% development
D 37 15 944 S 1.51 Central INT = 2
D 33 15 944 S 1.19 Central INT = 4.5
D 28 15 896 S 0.72 Central INT = 9
Small Town
D 63 32 1344 S 2.91 35% development
D 56 30 1344 S 2.37 60% development
D 46 30 1344 S 1.27 90% development

Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Rural Motorways
120.0
110.0
100.0
90.0
80.0
70.0 COBA11 D2M

COBA11 D3M
Speed (kph)
COBA11 D4M
60.0 TAME D2M
TAME D3M
TAME D4M
50.0
40.0
30.0
20.0
10.0
0.0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000
RTM Network Coding Draft V 08 Final - Copy.docx Page 75 of 97 Created by: Alison Cox
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Rural Dual Carriageways
120.0
110.0
100.0
90.0
80.0
70.0
Speed (kph)
COBA11 D2AP
COBA11 D3AP
60.0
TAME D2AP
TAME D3AP
50.0
40.0
30.0
20.0
10.0
0.0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Rural Single Carriageways
100.0
90.0
80.0
70.0
60.0
COBA11 S10 (TD9/81)
COBA11 S7.3 (TD9/81)
Speed (kph)
COBA11 S7.3 (Typical)

50.0 TAME11 S10 (TD9/81)
TAME11 S7.3 (TD9/81)
TAME11 S7.3 (Typical)
40.0
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Suburban Dual Carriageways
80.0
70.0
60.0
50.0
COBA11 DUAL CARRIAGEWAY (GOOD)

COBA11 DUAL CARRIAGEWAY (TYPICAL)
Speed (kph)
COBA11 DUAL CARRIAGEWAY (POOR)

40.0 TAME DUAL CARRIAGEWAY (GOOD)
TAME DUAL CARRIAGEWAY (TYPICAL)
TAME DUAL CARRIAGEWAY (POOR)
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500 3000 3500 4000 4500
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Suburban Single Carriageways
80.0
70.0
60.0
50.0
COBA11 SINGLE CARRIAGEWAY (GOOD)

COBA11 SINGLE CARRIAGEWAY (TYPICAL)
Speed (kph)
COBA11 SINGLE CARRIAGEWAY (POOR)

40.0 TAME SINGLE CARRIAGEWAY (GOOD)
TAME SINGLE CARRIAGEWAY (TYPICAL)
TAME SINGLE CARRIAGEWAY (POOR)
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Urban Non-central Roads
60.0
50.0
40.0
COBA11 URBAN NON-CENTRAL (GOOD)

Speed (kph)
COBA11 URBAN NON-CENTRAL

(TYPICAL)
30.0 COBA11 URBAN NON-CENTRAL (POOR)
TAME URBAN NON-CENTRAL (GOOD)
TAME URBAN NON-CENTRAL (TYPICAL)
20.0
10.0
0.0
0 500 1000 1500 2000
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Urban Central Roads
50.0
40.0
30.0
COBA11 URBAN CENTRAL (GOOD)
COBA11 URBAN CENTRAL (TYPICAL)
Speed (kph)
COBA11 URBAN CENTRAL (POOR)

TAME URBAN CENTRAL (GOOD)
TAME URBAN CENTRAL (TYPICAL)
TAME URBAN CENTRAL (POOR)
20.0
10.0
0.0
0 500 1000 1500
16/07/15
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Small Town Roads
70.0
60.0
50.0
COBA11 SMALL TOWN

(LIGHT DEVELOPMENT)
COBA11 SMALL TOWN
40.0 (TYPICAL
Speed (kph)
DEVELOPMENT)
COBA11 SMALL TOWN
(HEAVY DEVELOPMENT)
TAME SMALL TOWN
(LIGHT DEVELOPMENT)
30.0
TAME SMALL TOWN
(TYPICAL
DEVELOPMENT)
TAME SMALL TOWN
20.0
10.0
0.0
0 500 1000 1500 2000 2500
16/07/15
Appendix D
Trafficmaster Data Processing Technical Note
16/07/15
D.1 Introduction
As discussed at the Data Consistency and Network Development Technical Group, Mouchel
has developed a process to derive the fixed speeds for all the links within England and Wales
and offered to provide the data to all the five Regional Traffic model teams.
This note outlines the process and summary of the outputs resulting from the process that has
been developed by Mouchel.
D.2 ITN2SATURN Process

As agreed with HE, a process that has been developed by Atkins to generate the SATURN
buffer network to all the five regions, covering all the motorways, A-roads and B-roads within the
highway roads network for England, Wales and Scotland. The process produces three sets of
data:
1. SATURN GIS file (HERTM_MAB_Links_Polyline)
2. SATURN buffer network (SATURN_V2_150728.DAT); and
3. SATURN MapInfo file (SATURN_V2_150828_Links, SATURN_V2_150828_Nodes)
The process also provides the 3 lookup table in order to provide the relationship between the
MasterTOID (i.e. associated with SATURN links) and the ITN layer TOID:
1. DissolvedLinksTOIDRelation.txt,
2. CollapsedLinksTOIDRelation.txt, and
3. CollapsedNodesTOIDRelation.txt
D.3 Trafficmaster ITN Layer and JT Database

A revised set of Trafficmaster ITN layer and JT database were provided by DfT on 29th October
2015, which covers all the motorways, A-roads and B-roads for England and Wales for 4
months April, May, June and August 2015. However, as agreed with Highways England (HE),
only data for May and June 2015 were used to derive fixed speed data for the regional traffic
models. The data were provided with two separate elements:
1. Trafficmaster ITN2014 layer (itn140414EnglandDabmfinal) if GIS format; and
2. Trafficmaster JT database (GPSDataMay2015, GPSDataJune2015) in CSV format.
D.4 Derivation of Fixed Speed Data

Issue with SATURN GIS File (HERTM_MAB_Link_Polyline)
Initial analysis found that the SATURN GIS file provided by Atkins has number of links that are
duplicated and links that have the Anode and Bnode of the same values. This was due to the
fact that while aggregating number of ITN links to a single SATURN link, two or more links may
have the same Anode and Bnode thus resulting in duplicate, or links may have the same start
node and end nodes, thus resulting in Anode=Bnode, as show in Table below.
Region Not duplicate Duplicate Total A=B Valid SATURN buffer

England 10,0546 10,268 110,814 2,208 103,404 103,510
S&W 21,345 3,558 24,903 398 22,699 22,734
Total 121,891 13,826 135,717 2,606 126,103 126,244
16/07/15
Trafficmaster ITN Layer vs. Trafficmaster JT Database

Analysis of the Trafficmaster ITN layer has shown that the Node1 and Node2 provided in the
ITN links are the same for both directions, while the Trafficmaster JT database show correct
Node1 and Node2 for each direction, as example below:
from Trafficmaster JT database (CSV format)
link_id node1 node2 monthperiod tp vehcls N length av_jt sum_squ_ av_spd
4000000030120422A 4000000029828050 4000000029828040 Apr‐15 14 lgv 36 193.908 1686.69 1.22E+08 25.71653394
4000000030120422A 4000000029828050 4000000029828040 Apr‐15 15 lgv 32 193.908 1652.03 1.03E+08 26.25612254
4000000030120422A 4000000029828050 4000000029828040 Apr‐15 7 car 30 193.908 1680.53 1.24E+08 25.81081498
4000000030120422A 4000000029828050 4000000029828040 Apr‐15 7pm‐12amcar 31 193.908 1544.19 78768453 28.08970092
4000000030120422B 4000000029828040 4000000029828050 Apr‐15 12 lgv 29 193.908 1728.55 88316902 25.09380213
4000000030120422B 4000000029828040 4000000029828050 Apr‐15 9 lgv 40 193.908 1797.58 1.34E+08 24.13025044
from Trafficmaster ITN Network
ObjectID_ Toid ObjectID Descterm TopoArea Nature LnkLengthNode1 Node2 Classifica StreetName Trunk Prn Dir Length LinkID
77246 4000000030120420 82827 B Road ####### Single Carr 193.9 4000000029828050 4000000029828040 B2030 CHURCH HILL 0 0A 193.908 4000000030120422A
70654 4000000030120420 82827 B Road ####### Single Carr 193.9 4000000029828050 4000000029828040 B2030 CHURCH HILL 0 0B 193.908 4000000030120422B
However, the Link_ID column in the Trafficmaster ITN network shows TOID with sub-fix “A” and
“B” which represent different direction of travel. The Link_ID from Trafficmaster ITN network
matches the Link_ID from the Trafficmaster JT database.
Issues with SATURN GIS file ITN layer

SATURN GIS file only contains single links that represent both directions of the network as
opposed to SATURN buffer network, as shown below.
As can be seen, only one link was created for the two-way road between node 82609 and
82985 as opposed to two-way links created in SATURN buffer network. Please note that the
SATURN buffer network links were offset to the south of the SATURN GIS link in order to show
the difference.
16/07/15
Following analysis from the DissolvedLinksTOIDrelation.txt (provided by Atkins) and the

TrafficMaster ITN network (provided with the TrafficMaster JT database), it is noted that the
MasterTOID was created by aggregating number of ITN TOID along the direction of the road
that form the SATURN Link, as example below:
from DissolvedLinksToIDrelation From ITN Link

MasterTOID OrderSeqNo TOID Orientation NetworkElementType Link_ID
osgb4000000009353667 0 osgb4000000009353706 1 Link 4000000009353706A
osgb4000000009353667 2 osgb4000000009353707 ‐1 Link 4000000009353707B
osgb4000000009353667 4 osgb4000000009353729 ‐1 Link 4000000009353729B
osgb4000000009353667 6 osgb4000000009353708 ‐1 Link 4000000009353708B
osgb4000000009353667 8 osgb4000000009353684 1 Link 4000000009353684A
osgb4000000009353667 10 osgb4000000009353721 1 Link 4000000009353721A
osgb4000000009353667 12 osgb4000000009353709 1 Link 4000000009353709A
osgb4000000009353667 14 osgb4000000009353688 1 Link 4000000009353688A
osgb4000000009353667 16 osgb4000000009353710 1 Link 4000000009353710A
osgb4000000009353667 18 osgb4000000009353667 1 Link 4000000009353667A
osgb4000000009353667 20 osgb4000000009353691 1 Link 4000000009353691A
osgb4000000009353667 22 osgb4000000009509441 1 Link 4000000009509441A
osgb4000000009353667 24 osgb4000000009353711 1 Link 4000000009353711A
osgb4000000009353667 26 osgb4000000009353672 1 Link 4000000009353672A
osgb4000000009353667 28 osgb4000000009353724 1 Link 4000000009353724A
osgb4000000009353667 30 osgb4000000009353732 1 Link 4000000009353732A
osgb4000000009353667 32 osgb5000005119251563 1 Link 5000005119251563A
osgb4000000009353667 34 osgb4000000009655699 1 Link 4000000009655699A
osgb4000000009353667 36 osgb4000000009395290 1 Link 4000000009395290A
osgb4000000009353667 38 osgb4000000009395288 1 Link 4000000009395288A
osgb4000000009353667 40 osgb4000000009395292 1 Link 4000000009395292A
osgb4000000009353667 42 osgb4000000009395289 1 Link 4000000009395289A
It can be seen, the “Orientation” column represents the direction of the GIS link, with 1 and -1
indicating the sub-fix “A” and “B” respectively in the ITN network.
From this, it is possible to generate Link_ID and subsequently JT data for the SATURN link
reversed direction.
16/07/15
However, there are cases where 1 does not represent “A”, and -1 not representing “B”, as
example below:
Those are one-way links in the network. It was observed that the column “Oneway” in the
SATURN GIS file provides an indication of direction with blank for two-way links, and 1 and -1
for one-way links.
Interrogation of the SATURN GIS file and the DissolvedLinksTOIDRelation as provided by
Atkins, it was found that:
If “Oneway” column shows “-”, then 1 implies “B”, -1 implies “A”
from DissolvedLinksToIDRelation From ITN Network
osgb4000000032978947 0 osgb4000000033032541 1 Link 4000000033032541B
osgb4000000032978947 2 osgb4000000032978947 1 Link 4000000032978947B
Or example below
from DissolvedLinksToIDRelation from ITN Link
osgb4000000032965849 0 osgb4000000032965861 ‐1 Link 4000000032965861A
osgb4000000032965849 2 osgb4000000032966984 1 Link 4000000032966984B
osgb4000000032965849 4 osgb4000000032972534 1 Link 4000000032972534B
osgb4000000032965849 6 osgb4000000032968874 1 Link 4000000032968874B
osgb4000000032965849 8 osgb4000000032965855 1 Link 4000000032965855B
osgb4000000032965849 10 osgb4000000032978699 1 Link 4000000032978699B
osgb4000000032965849 12 osgb4000000032978701 1 Link 4000000032978701B
osgb4000000032965849 14 osgb5000005109153890 1 Link 5000005109153890B
osgb4000000032965849 16 osgb5000005109153891 1 Link 5000005109153891B
osgb4000000032965849 18 osgb4000000032966973 1 Link 4000000032966973B
osgb4000000032965849 20 osgb4000000032965849 1 Link 4000000032965849B
osgb4000000032965849 22 osgb4000000033051896 1 Link 4000000033051896B
osgb4000000032965849 24 osgb4000000032972326 1 Link 4000000032972326B
osgb4000000032965849 26 osgb4000000032985656 1 Link 4000000032985656B
osgb4000000032965849 28 osgb4000000032966965 1 Link 4000000032966965B
If “Oneway” column shows “+“, then 1 implies “A”, -1 implies “B”
16/07/15
from DissolvedLinksToIDRelation from ITN Link

osgb4000000032965862 0 osgb4000000032979037 ‐1 Link 4000000032979037B
osgb4000000032965862 2 osgb4000000032965862 1 Link 4000000032965862A
osgb4000000032965862 4 osgb4000000032993467 1 Link 4000000032993467A
osgb4000000032965862 6 osgb4000000032968889 1 Link 4000000032968889A
There are cases where the aggregate links from SATURN GIS file do not include all the ITN
links. This normally occurs at: exploded junctions, entries/exits to roundabouts, island on the
roads, etc., as example below:
from DissolvedLinksToIDRelation from Trafficmaster ITN Network

4000000010796130B
osgb4000000010797099 0 osgb4000000010797120 ‐1 Link 4000000010797120B
osgb4000000010797099 2 osgb4000000010797099 1 Link 4000000010797099A
osgb4000000010797099 4 osgb4000000010797111 1 Link 4000000010797111A
osgb4000000010797099 6 osgb4000000010797100 1 Link 4000000010797100A
osgb4000000010797099 8 osgb4000000011027448 1 Link 4000000011027448A
4000000010797102B
not included in the DissolvedLinksToIDRelation
Similar occurence was found on other locations, as below.
16/07/15
Or example below
16/07/15
Conclusions
Based on the analysis above, it is therefore concluded that:
For direction of Trafficmaster ITN layer:
 For 2-way links: Column “One-way” = “ “, then 1 implies A, -1 implies B
 For 1-way links: if column “One-way” =”+”, then 1 implies A, -1 implies B
 For 1-way links: if column “One-way” = “-“, then 1 implies B, -1 implies A
For missing ITN links at either each end of a SATURN links:

 Ignore the presence of the ITN links that are excluded from the aggregation process,
and
 only use the ITN links that are included as “Link” in the “NetworkElelement” column from
the “DissolvedLinksTOIDRelation” file provided by Atkins.
D.5 Derivation of SATURN Fixed speed from Trafficmaster JT database

The process developed by Mouchel was implemented to derive the fixed speed at link level for
the SATURN buffer network as provided by Atkins. For any further amendment/revision of the
network structure of each RTM model, each RTM team will need to create a list of
correspondence between revised SATURN link ID <-> ITN TOID (discussed later) prior to input
into the process.
The process to derive the SATURN fixed speed from Trafficmaster JT database was divided
into 2 steps:
Step 1: Create lookup table: SATURN Link ID to ITN TOID by direction

 Convert one-way link from SATURN GIS file to create two-way links data where
applicable (including Anode, Bnode, MasterTOID).
 Create a lookup table between MasterTOID (generated from SATURN GIS file) and list
of Trafficmaster ITN layer TOIDs associated with SATURN link with indication of
direction of travel
o From “DissovledLinksTOIDrelation”, filter “link” only from “NetworkElement”, and
sort in ascending order of the column “OrderSeqNo”
o Export to CSV format
o Import to excel tool to create a list of MasterTOID -> TOID equivalent
o Correct direction of TOID based on analysis above (i.e. for 2-way links or one-
way links with “Oneway” column is marked as “+”, 1 indicates A and -1 indicates
B; for one-way links with “Oneway” column is marked as “-“, -1 indicates A and 1
indicates B)
 At the end of this process, a lookup table was created with the following format:
16/07/15
Anode Bnode MasterToID Sequence ToID

40266 40272 osgb4000000015453017 1001 4000000015453019A
40266 40272 osgb4000000015453017 1002 4000000015453018A
40266 40272 osgb4000000015453017 1003 4000000015453029A
40266 40272 osgb4000000015453017 1004 4000000015453017A
40266 40272 osgb4000000015453017 1005 4000000015453046A
40266 40272 osgb4000000015453017 1006 4000000015453059B
40272 40266 osgb4000000015453017 2001 4000000015453059A
40272 40266 osgb4000000015453017 2002 4000000015453046B
40272 40266 osgb4000000015453017 2003 4000000015453017B
40272 40266 osgb4000000015453017 2004 4000000015453029B
40272 40266 osgb4000000015453017 2005 4000000015453018B
40272 40266 osgb4000000015453017 2006 4000000015453019B
 Where:
o Anode: SATURN Anode
o BNode: SATURN Bnode
o MasterTOID: MasterTOID associated with SATURN link from the SATURN GIS
file
o Sequence: Sequence Order of the ITN TOID from the start of SATURN Link to
the End of SATURN link; and
o TOID: list of all the ITN TOID that aggregate to the SATURN Link in the order
from the start to the end of the SATURN link following direction of travel.
 The lookup table as shown above will be input in to the SQL process that has been
developed below. Each RTM team can easily update the link between ITN TOID and
SATURN MasterTOID by adding in new “Sequence” and ITN “TOID” to the list.
Step 2: Process (SQL Server) to produce travel Speed for SATURN links
 Import lookup table as produced at the end of Step 1 above
 Import Trafficmaster JT database for May and June 2015 into SQL Server for England
and Wales. The JT data cover all the motorways, A-roads and B-roads as agreed with
HE and consists of the following fields:
o TOID: ITN Link TOID
o Node1: ITN Link node1
o Node2: ITN link Node2
o MonthPeriod: May-15, June-15
o TimePeriod: individual hour from 7 to 19, plus two off-peak periods 0am-7am and 7pm-
0am
o VehClass: car, lgv, and hgv
o SampleSize
o Lengthm: ITN link length in metre
o Ave_JT: mean JT in 100th of second,
o Sum_square_JT
o Ave_Speed: speed based on mean JT in mph
o Med_JT: median JT in 100th of second
16/07/15
 Aggregate JT data to modelled periods (AM 07-10, Inter-Peak 10-16, PM 16-19 and off-
peak 19-07) and “all vehicle” and by two months of data (May and June), at the ITN
TOID link level, following the equations:
Sum_AveJTSampleSize Ave_JT , , ∗ SampleSize , , 1.1
, ,
Sum_MedJTSampleSize Med_JT , , ∗ SampleSize , , 1.2

, ,
Sum_SampleSize SampleSize , , 1.3

, ,
 And then calculate Average JT and Median Journey Time for each ITN link (factor of
0.01 is used to convert from 100th of second to second):
Sum_AveJTSampleSize
Ave_JTime 0.01 ∗ 1.4
Sum_SampleSize
Sum_MedJTSampleSize
Med_JTime 0.01 ∗ 1.5
Sum_SampleSize
 Please note that since sample size was provided for ITN TOI level, when aggregate to
SATURN link level, the sample size for the SATURN link is not sum of all the ITN
sample sizes but will be a form of number of sample that travels from the first ITN link to
the last ITN link, as illustrated in the example below:
Length1, N1 Length2, N2 Length3, N3 Length4, N4
ITN Link:
∑ ∗ /∑
SATURN link:
 For simplicity, the length weighted average sample size was applied to calculate sample
size at SATURN link level. As a result, an extra step was added as below:
Sum_LengthSampleSize Lengthm , , ∗ SampleSize , , 1.6
, ,
 Aggregate data from ITN link levels to SATURN link levels using the lookup table
produced in step 1, as below:
Total_AveJTime Ave_JTime 2.1
Total_MedJTime Med_JTime 2.2
Total_SampleSize Sum_SampleSize 2.3
Total Sum_LengthSampleSize Sum_LengthSampleSize 2.4
Total_Length Lengthm 2.5
 Average and Median speed on SATURN link was then calculated (factor of 3.6 is used
to convert from m/s to kph), as below:
Total_Length
Ave_Speed 3.6 ∗ 2.6
Total_AveJTime
Total_Length
Med_Speed 3.6 ∗ 2.7
Total_MedJTime
 ITN link weighted average sample size was also calculated:
16/07/15
Total Sum
SampleSize_Ave 2.8
Total Lengthm
 The output from the process consists of two sets of data:
o Average and median journey time at ITN link level, with the following fields:
 Anode: SATURN Anode
 Bnode: SATURN Bnode
 MasterTOID: SATURN link TOID
 Order: Sequence order of ITN Link TOID
 TOID: ITN link TOID that constitute to the SATURN link
 TimeIndex: 1-4 for AM, IP, PM and OP respectively
 VehIndex: 1 for all vehicles combined
 SSize: Sample Size (total of 2 months)
 Lengthm: ITN link length in metre
 AveJTSSize: Sum_AveJTSampleSize (equation 1.1)
 MedJTSSize: Sum_MedJTSampleSize (equation 1.2)
 LenJTSSize: Sum_LengthSampleSize (equation 1.6)
 Ave_JTime: average journey time at ITN link level (equation 1.4); and
 Med_JTime; median journey time at ITN link level (equation 1.5).
o Average and median journey time and speed at SATURN link level, with the
following fields:
 Anode: SATURN anode
 Bnode: SATURN bnode
 MasterTOID: SATURN link TOID
 TimeIndex: 1-4 for AM, IP, PM and OP respectively
 VehIndex: 1 for all vehicles
 Length_m: total SATURN link length in metre (equation 2.5)
 SSize_Tot: total sample sizes of all ITN links that constitute to SATURN link
(equation 2.3)
 SSize_Ave: weighted average sample size (equation2.8)
 AveJTime: average JT on SATURN link (equation 2.1)
 AveSpeed: average speed on SATURN link (equation 2.6)
 MedJTime: median JT on SATURN link (equation 2.2)
 MedSpeed: median speed on SATURN link (equation 2.7)
16/07/15
Output Statistics
Analysis from output fixed speed results show that about 2-4% of the SATURN links do not
have any speed data, this is as a result of:
 The incompatibility between the ITN2014 (used for Trafficmaster JT data) and the
ITN2015 (used to produce SATURN buffer network); or
 ITN links without any observed data
Summary of Links with/without Data
TimeIndex Midlands North NPH Scotland South East South West Wales total
No data 2,992 1,069 3,410 15,651 5,729 2,047 1,257 32,155
AM 20,395 7,351 26,746 4 33,580 15,435 7,829 111,340
IP 20,519 7,407 26,907 4 33,721 15,492 7,874 111,924
PM 20,382 7,347 26,735 4 33,576 15,427 7,839 111,310
OP 20,309 7,293 26,666 4 33,523 15,345 7,790 110,930
SAT. Link 21,113 7,591 27,458 15,335 34,825 15,876 8,076 130,274
Percentage of Valid data
No data 14% 14% 12% 102% 16% 13% 16% 25%
AM 97% 97% 97% 0% 96% 97% 97% 85%
IP 97% 98% 98% 0% 97% 98% 97% 86%
PM 97% 97% 97% 0% 96% 97% 97% 85%
OP 96% 96% 97% 0% 96% 97% 96% 85%
Comparison of average speed and median speed shows that about 95-97% of links within
England that show higher values in median speed compared to average speed, as shown in
table below.
Comparison of Average Speed vs. Median Speed
Record %age
Area Period
Ave<Med Ave=Med Ave>Med Total Ave<Med Ave=Med Ave>Med
England AM 100,305 1,660 1,542 103,507 97% 2% 1%
England IP 101,354 1,714 978 104,046 97% 2% 1%
England PM 100,121 1,805 1,541 103,467 97% 2% 1%
England OP 97,993 1,944 3,199 103,136 95% 2% 3%
Total 399,773 7,123 7,260 414,156 97% 2% 2%
Scotland&Wales AM 7,408 212 213 7,833 95% 3% 3%
Scotland&Wales IP 7,608 151 119 7,878 97% 2% 2%
Scotland&Wales PM 7,386 244 213 7,843 94% 3% 3%
Scotland&Wales OP 7,002 380 412 7,794 90% 5% 5%
Scotland&Wales 29,404 987 957 31,348 94% 3% 3%
Both AM 107,713 1,872 1,755 111,340 97% 2% 2%
Both IP 108,962 1,865 1,097 111,924 97% 2% 1%
Both PM 107,507 2,049 1,754 111,310 97% 2% 2%
Both OP 104,995 2,324 3,611 110,930 95% 2% 3%
Total 429,177 8,110 8,217 445,504 96% 2% 2%
16/07/15
Distribution of speed (both average and median) by speed band was also summarised in the
two tables below.
Distribution of Average Speed by Speed band
Record
Area Period
<10mph 10-20mph 20-30mph 30-40mph 40-50mph 50-60mph 60-70mph >70mph Total
England AM 16,824 28,843 27,682 15,578 8,541 2,862 2,956 221 103,507
England IP 16,870 27,431 28,607 16,348 8,611 2,707 3,320 152 104,046
England PM 20,066 28,323 25,417 14,720 8,604 3,065 2,825 447 103,467
England OP 10,039 19,770 32,369 20,465 11,469 4,504 3,829 691 103,136
Total 63,799 104,367 114,075 67,111 37,225 13,138 12,930 1,511 414,156
Scotland&Wales AM 592 1,643 2,299 1,733 1,002 291 267 6 7,833
Scotland&Wales IP 640 1,719 2,307 1,783 916 236 276 1 7,878
Scotland&Wales PM 690 1,671 2,205 1,678 1,012 286 272 29 7,843
Scotland&Wales OP 339 1,146 2,351 1,876 1,214 529 285 54 7,794
Scotland&Wales 2,261 6,179 9,162 7,070 4,144 1,342 1,100 90 31,348
Both AM 17,416 30,486 29,981 17,311 9,543 3,153 3,223 227 111,340
Both IP 17,510 29,150 30,914 18,131 9,527 2,943 3,596 153 111,924
Both PM 20,756 29,994 27,622 16,398 9,616 3,351 3,097 476 111,310
Both OP 10,378 20,916 34,720 22,341 12,683 5,033 4,114 745 110,930
Total 66,060 110,546 123,237 74,181 41,369 14,480 14,030 1,601 445,504
Distribution of Median Speed by Speed band

Record
Area Period
<10mph 10-20mph 20-30mph 30-40mph 40-50mph 50-60mph 60-70mph >70mph Total
England AM 8,884 24,021 34,494 18,518 10,354 3,343 3,530 363 103,507
England IP 9,250 23,568 34,332 19,057 10,647 3,080 3,826 286 104,046
England PM 10,302 25,213 32,187 17,595 10,406 3,589 3,405 770 103,467
England OP 5,380 15,044 34,754 24,729 12,900 5,323 3,821 1,185 103,136
Total 33,816 87,846 135,767 79,899 44,307 15,335 14,582 2,604 414,156
Scotland&Wales AM 308 1,271 2,550 1,856 1,152 378 308 10 7,833
Scotland&Wales IP 341 1,354 2,536 1,878 1,155 296 310 8 7,878
Scotland&Wales PM 364 1,358 2,387 1,855 1,160 379 281 59 7,843
Scotland&Wales OP 195 855 2,381 2,035 1,326 597 328 77 7,794
Scotland&Wales 1,208 4,838 9,854 7,624 4,793 1,650 1,227 154 31,348
Both AM 9,192 25,292 37,044 20,374 11,506 3,721 3,838 373 111,340
Both IP 9,591 24,922 36,868 20,935 11,802 3,376 4,136 294 111,924
Both PM 10,666 26,571 34,574 19,450 11,566 3,968 3,686 829 111,310
Both OP 5,575 15,899 37,135 26,764 14,226 5,920 4,149 1,262 110,930
Total 35,024 92,684 145,621 87,523 49,100 16,985 15,809 2,758 445,504
16/07/15
Distribution of Speed data by Sample Size

Record
Area Period
<10 10-50 50-100 100-200 200-500 >500 Total
England AM 2,201 4,856 6,121 12,792 34,536 43,001 103,507
England IP 1,629 2,444 2,995 6,464 19,999 70,515 104,046
England PM 2,278 5,510 6,861 15,670 38,995 34,153 103,467
England OP 3,326 9,154 10,922 19,625 33,074 27,035 103,136
Total 9,434 21,964 26,899 54,551 126,604 174,704 414,156
Wales AM 447 1,201 1,085 1,602 1,974 1,520 7,829
Wales IP 177 666 746 1,175 2,353 2,757 7,874
Wales PM 469 1,335 1,261 1,733 2,002 1,039 7,839
Wales OP 861 1,999 1,612 1,558 1,219 541 7,790
Total 1,954 5,201 4,704 6,068 7,548 5,857 31,332
Both AM 2,648 6,057 7,206 14,394 36,510 44,521 111,336
Both IP 1,806 3,110 3,741 7,639 22,352 73,272 111,920
Both PM 2,747 6,845 8,122 17,403 40,997 35,192 111,306
Both OP 4,187 11,153 12,534 21,183 34,293 27,576 110,926
Total 11,388 27,165 31,603 60,619 134,152 180,561 445,488
16/07/15
Two figures below show an example of the fixed speed plots for the AM periods for England and
Wales that is based on average JT. Please note that there are number of motorway links where
speed exceeds 70mph.
16/07/15

RTM Network Coding Draft V 08 Final - (Changes Highlighted)

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

RTM Network Coding Draft V 08 Final - (Changes Highlighted)

Diunggah oleh

Hak Cipta:

Format Tersedia

Regional Traffic Models

Network Coding Manual

Date: 11 December 2015 Version: 0.8

Document Title Regional Traffic Models

Version Date Description Author

Name Signature Title Date of Version

The original format of this document is copyright to the Highways England.

RTM Network Coding Draft V 08 Final - Copy.docx Page 2 of 97

RTM Network Coding Draft V 08 Final - Copy.docx Page 3 of 97

Table 1: Principles of Network Coding 8

RTM Network Coding Draft V 08 Final - Copy.docx Page 4 of 97

RTM Network Coding Draft V 08 Final - Copy.docx Page 5 of 97

Figure 1: Signalised Junction Movement Descriptions 16

RTM Network Coding Draft V 08 Final - Copy.docx Page 6 of 97

 Section 2 provides detail on the coding principles to be adopted by the Regional

RTM Network Coding Draft V 08 Final - Copy.docx Page 7 of 97

2.1. Network Density and Coding Principles

Area 1 Area 2 Area 3 External

RTM Network Coding Draft V 08 Final - Copy.docx Page 8 of 97

2.2. Node and Zone Numbering Convention

Node Numbering Convention

Zone Numbering Convention

RTM Network Coding Draft V 08 Final - Copy.docx Page 9 of 97

RTM Network Coding Draft V 08 Final - Copy.docx Page 10 of 97

3. Network Assignment Parameters

RTM Network Coding Draft V 08 Final - Copy.docx Page 11 of 97

3.3. Integer Parameters

RTM Network Coding Draft V 08 Final - Copy.docx Page 12 of 97

It is recommended that the value of KONSTP is set to 1, 5 or 6, with 5 being the

3.4. Real Parameters

RTM Network Coding Draft V 08 Final - Copy.docx Page 13 of 97

RTM Network Coding Draft V 08 Final - Copy.docx Page 14 of 97

4.2. Signalised Junctions

RTM Network Coding Draft V 08 Final - Copy.docx Page 15 of 97

Figure 1: Signalised Junction Movement Descriptions

RTM Network Coding Draft V 08 Final - Copy.docx Page 16 of 97

Lane Width 1 lane 2 lanes 3 lanes 4 lanes

Turn Radius Left Turning Movement Right Turning Movement

RTM Network Coding Draft V 08 Final - Copy.docx Page 17 of 97

Turn Radius 1 Lane 2 Lanes 3 Lanes 4 Lanes

4.3. Priority Junctions

Figure 2: Priority Junction Movement Descriptions

RTM Network Coding Draft V 08 Final - Copy.docx Page 18 of 97

RTM Network Coding Draft V 08 Final - Copy.docx Page 19 of 97

E = visibility to the right in metres

Turn Radius 1 Lane 2 Lanes 3 Lanes 4 Lanes

RTM Network Coding Draft V 08 Final - Copy.docx Page 20 of 97

Minor to Major Give-Way (G) Major to

RTM Network Coding Draft V 08 Final - Copy.docx Page 21 of 97

Minor to Major Give-Way (G) Major to

RTM Network Coding Draft V 08 Final - Copy.docx Page 22 of 97

Roundabout Lane Approach Entry Flare Entry Inscribed Entry

Mini roundabout Narrow 3.00 3.00 0.1 7 20 35

RTM Network Coding Draft V 08 Final - Copy.docx Page 23 of 97

Roundabout Type Lane Circulating GAP Entry Circulating

mini roundabout Narrow 5 2.0 820 1820

4.5. Gyratories and ‘Exploded’Roundabouts

RTM Network Coding Draft V 08 Final - Copy.docx Page 24 of 97

Typically, expanded roundabouts are modelled as a series of either priority or signalised

When coding a signalised roundabout or gyratory it is important to consider the coordinated

Approach Arm Circulating Arm

Approach Arm Circulating Arm

RTM Network Coding Draft V 08 Final - Copy.docx Page 25 of 97