Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Registered office Bridge House, 1 Walnut Tree Close, Guildford GU1 4LZ
Highways England Company Limited registered in England and Wales number 09346363
Regional Traffic Models
Document Control
Revision History
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
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.1. Introduction 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.1. Introduction 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.1. Introduction 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
List of Figures
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:
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.
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.
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.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.)
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.
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.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.
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.
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.
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:
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.
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.
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:
Sr = turn saturation flow in PCU’s per hour
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:
Sr = turn saturation flow in PCU’s per hour
Y = geometric parameter calculated based on the following equation:
Equation 6
Y = (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 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:
Sr = turn saturation flow in PCU’s per hour
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:
D = lane width 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:
Sr = turn saturation flow in PCU’s per hour
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.
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.
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.
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.
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.
code signalised roundabouts as a single node, and therefore these junctions need to be
represented as a series of signalised junctions.
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.
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.
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.
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.
Ns Os Inc Ns Exc Ns
Min Value
Median Value 1730 3460
Max Value
Table 16: Motorway Slip Roads – Saturation Flow Values (PCU’s per hour)
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.
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:
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.
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.
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
8 Rural All-Purpose D3 (70mph) 112 80 6298 2.75
9 Rural All-Purpose D3 60mph 98 76 6298 2.75
10 Rural All-Purpose D3 50mph 80 62 6298 2.20
11 Rural All-Purpose D2 (70 mph) 112 73 4199 2.75
12 Rural All-Purpose D2 50mph 80 62 4199 2.20
13 Rural All-Purpose D2 40mph 64 35 4199 1.60
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
49 Rural All-Purpose D2 (60mph) 96 76 4199 2.75
50 Rural All-Purpose S3/4 (60mph) 87 58 3400 2
Suburban
Index Description S0 S2 Capacity N
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
Index Description S0 S2 Capacity N
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
Index Description S0 S2 Capacity N
41 Small Town 35% development 63 32 1344 2.91
42 Small Town 60% development 56 30 1344 2.37
43 Small Town 90% development 46 30 1344 1.27
Miscellaneous
Index Description S0 S2 Capacity N
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
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.
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.
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.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.
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.
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.
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
Saturation flows
pcus per hourour
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
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
Figure 8: Merge with Ghost Island 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 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
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 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
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
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
Saturation flows
pcus per hour
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
Figure 20: Ghost Island Diverge 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
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
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
Turn Anode Bnode Cnode Marker Link Lanes Turning Min Median Max
Length Per Lanes Value Value Value
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
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.
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.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.
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.
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.
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.
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.
The high intergreen for the minor road is to account for the lost time due to pedestrian crossing
the junction.
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.
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.
The high intergreen for the minor road is to account for the lost time due to pedestrian crossing
the junction.
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.
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.
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 B2 Case 2: the start of diverging arm is not coded as a separate node
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 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
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)
RTM Network Coding Draft V 08 Final - Copy.docx Page 70 of 97
Created by: Alison Cox 16/07/15
Regional Traffic Models
Figure 2 - Comparison of COBA SATURN Speed Flow Curves - Suburban Dual Carriageways
80.0
70.0
60.0
50.0
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500 3000 3500 4000 4500
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 71 of 97
Created by: Alison Cox 16/07/15
Regional Traffic Models
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.
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
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Rural Motorways
120.0
110.0
100.0
90.0
80.0
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
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 75 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 76 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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)
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 77 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Suburban Dual Carriageways
80.0
70.0
60.0
50.0
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500 3000 3500 4000 4500
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 78 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Suburban Single Carriageways
80.0
70.0
60.0
50.0
30.0
20.0
10.0
0.0
0 500 1000 1500 2000 2500
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 79 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Urban Non-central Roads
60.0
50.0
40.0
20.0
10.0
0.0
0 500 1000 1500 2000
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 80 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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)
10.0
0.0
0 500 1000 1500
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 81 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Comparison of COBA and Re-estimated SATURN Speed Flow Curves - Small Town Roads
70.0
60.0
50.0
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
Carriageway Flow (pcus)
RTM Network Coding Draft V 08 Final - Copy.docx Page 82 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Appendix D
Trafficmaster Data Processing Technical Note
RTM Network Coding Draft V 08 Final - Copy.docx Page 83 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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.
RTM Network Coding Draft V 08 Final - Copy.docx Page 84 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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.
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.
RTM Network Coding Draft V 08 Final - Copy.docx Page 85 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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.
RTM Network Coding Draft V 08 Final - Copy.docx Page 86 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
MasterTOID OrderSeqNo TOID Orientation NetworkElementType Link_ID
osgb4000000032978947 0 osgb4000000033032541 1 Link 4000000033032541B
osgb4000000032978947 2 osgb4000000032978947 1 Link 4000000032978947B
Or example below
from DissolvedLinksToIDRelation from ITN Link
MasterTOID OrderSeqNo TOID Orientation NetworkElementType Link_ID
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
RTM Network Coding Draft V 08 Final - Copy.docx Page 87 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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:
RTM Network Coding Draft V 08 Final - Copy.docx Page 88 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
Or example below
RTM Network Coding Draft V 08 Final - Copy.docx Page 89 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
RTM Network Coding Draft V 08 Final - Copy.docx Page 90 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
RTM Network Coding Draft V 08 Final - Copy.docx Page 91 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
, ,
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
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:
RTM Network Coding Draft V 08 Final - Copy.docx Page 92 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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)
RTM Network Coding Draft V 08 Final - Copy.docx Page 93 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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%
RTM Network Coding Draft V 08 Final - Copy.docx Page 94 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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
RTM Network Coding Draft V 08 Final - Copy.docx Page 95 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
RTM Network Coding Draft V 08 Final - Copy.docx Page 96 of 97 Created by: Alison Cox
16/07/15
Regional Traffic Models
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.
RTM Network Coding Draft V 08 Final - Copy.docx Page 97 of 97 Created by: Alison Cox
16/07/15