Tweets collection

Junctions are the dominant source of delay in congested urban networks. It is therefore critical that junctions are coded accurately, and that modelling software correctly simulates the operation and capacity of junctions.

HTA modelling software packages will simulate junction capacity using different methods. However, it is common that junction attributes will include data that defines junction geometry and the average method of traffic control.

SATURN relies on a propagation of Cyclic Flow Profiles (CFP) for calculation of the actual turn delays within a junction (see Figure 14). The CFP method allows accurate calculation of delay by inherently considering the impact of platoon progression on junction turn interaction. To achieve the correct capacity SATURN regards all turning movements at a junction as ‘assignment links’ with specific Volume-Delay Functions (VDFs). Unlike conventional assignment link functions, the volume-delay curve within SATURN is not user specified or pre-defined but is calculated by the software using input information on signal settings, turning priorities and saturation flows.

VISUM uses a different approach, by using an Intersection Capacity Analysis (ICA) module which is based on the Highway Capacity Manual⁶⁵ (HCM) method for calculating junction turn capacities and delays within isolated junction models. The HCM methodology treats junctions in isolation and thus disregards the effects of signal coordination. VISUM corrects this within ICA by modifying the junction turn delay based on the link attribute ‘ICAArrivalType’, a parameter which describes the nature of traffic platoons. Complex and/or large junctions (e.g. dual carriageway junctions) in navigational networks are often not represented by a single node, but instead by a group of nodes. One individual node then corresponds to only one part of an actual junction and application of the HCM formulae to each of these sub-nodes would yield erroneous results within VISUM. The solution adopted in VISUM is to group all nodes comprising a given intersection into a single ‘main node’. This can be illustrated by Figure 18, which shows a four leg intersection with separate carriageways in the east-west direction. For the purpose of signalling, capacity and delay calculations this has been combined into a single node within VISUM.

Figure 18: A VISUM main node – as on-street (left) and within the model (right).

When using the ICA method embedded within VISUM it may not seem necessary to specify free-flow turn time (t0 in VISUM) and capacities for turns. However the bi-level calculation method within VISUM initiates a classical VDF-based equilibrium assignment which requires both free-flow turn time (t0) and turn capacity. It is for this initial assignment that the attributes need to be specified. Experiments have shown using VISUM that converged solutions are quite stable against changes of the initial t0 and turn capacity, so the choice of these values is not critical. Recommended values are:

Initial t0 = 10s; and

Initial turn capacity = 1500 PCU/hour x effective number of turn lanes.

The effective number of turn lanes is given by:

1.0, if the lane is exclusive; or

0.5 or 0.333 if shared with one or two other movements.

65 Highway Capacity Manual, Transportation Research Board, Washington, DC, 2000.

1

The procedure used when converting ICA parameters into turn volume delay functions successively overwrites turn capacities with new estimates from ICA. In order to restore initial values and reproduce results, it is necessary to input initial turn capacities as a VISUM User-Defined Attribute (UDA) instead of the in-built turn attribute. ICA calculations for over-saturated junctions may yield very small capacities. While this should not occur in the converged solution, it may happen during the first iterations and can then lead to numerical problems. A reliable countermeasure is to specify a minimum turn capacity, as a UDA, to use as a lower bound for re-estimated capacities.

A minimum capacity of 100 PCU/hour has been found to work in practice. The value can be justified since a number of vehicles can be stored in the junction and clear during the subsequent interstage even when the opposing flow is saturated.

6.4.3.1 Junction Geometry

In HTA models detailed junction modelling should begin by coding accurate junction geometry. The coding of geometric elements should represent information obtained from various sources outlined in B2.3 and B2.4 (e.g. site layout drawings and site observations).

An illustration of junction coding will be provided using VISUM. Detailed junction modelling should begin by defining the orientation of the approach links at a node or main node. The orientation of an approach link is the direction (i.e. north, east, south, or west) from which it approaches the intersection. It serves as a convenient designation of the approach for reporting, but also determines geometric calculations in the node by defining conflicting movements. Link orientations are assigned automatically from link angle, which may not be desirable when modelling main nodes within VISUM.

Node approach link orientations must be correctly defined at the beginning of any network development. Link orientations act as a reference for other data in the junction model, meaning subsequent alteration will cause a loss of dependent link data such as lanes, signal group associations, etc.

To correctly model the geometry of a junction it is necessary to specify the number of lanes per approach, allowed turns per lane and the length of effective flared lanes.

VISUM will only represent distinct lanes with a constant width. Therefore flared lanes must be coded as separate pocket lanes. The effective length of a pocket lane is the position at which the flared approach allows two vehicles to queue side by side.

ICA does not currently consider the finite length of pocket lanes, although future extensions may incorporate this feature to better reflect queuing capacity. Pocket lanes will need to be coded if this feature becomes incorporated within ICA.

Figure 19 illustrates the correct coding of a dual carriageway junction where the east-west direction consists of dual-carriageway links. VISUM is unable to recognise that links belong to a single leg of the same intersection. Furthermore, accidental differences in link angle lead to the north-west leg coming from south of the west leg, similar to the eastern side of the intersection. The correct solution illustrates that it is necessary to manually override the link orientations to designate both of the links on the left as the W leg, and both links on the right as the E leg. Note that the direction of major flow (the thick arrows in Figure 19) is now drawn correctly alongside each of the one-way carriageways.

INCORRECT

CORRECT

Figure 19: Examples of incorrect and correct network coding using a dual carriageway junction in VISUM.

6.4.3.2 Capacity Considerations

Calculation of effective capacities is an essential component within any congested assignment model. Signal settings and saturation flow are the two main parameters necessary to represent network capacity. The accuracy of these parameters is paramount if a model is to correctly depict available traffic supply.

SATURN and VISUM have specific capacity coding requirements driven by the methodology used to calculate network delay. Both require an average timing plan to be created, therefore it is advised to refer to section B2.4.9, especially if a junction operates with traffic-actuated (i.e. VA) or dynamic (i.e. SCOOT) signal control. Average phase durations and cycle times should be calculated before being coded into the junction control. The presence of demand-dependent stages should be established, with their frequency, along with a determination of which stages receive additional time when an enabled stage is not activated (see section B2.4.9.3).

N

SATURN uses cyclic flow profiles (CFP) based on turning movements, which consist of four different patterns: IN, ARRIVE, ACCEPT and OUT. The ACCEPT profile is derived independently based on capacity, signal timing and conflicting traffic. The accurate generation of this profile is critical to a model and thus occupies a large proportion of the required coding. The calculation of the saturation flows in SATURN is vulnerable to inconsistency during network coding. This is because modellers must use a level of interpretation when developing a network and thus practitioners may use generic saturation flow values for specific turn types. This may be acceptable for specific networks but the preferred option should be for measured saturation flow values.

VISUM also allows users to override the ideal turn saturation flow. It may be necessary to use this feature when the ICA (HCM) method conflicts with more detailed modelling or site observation. In all other cases use of the saturation flow override is discouraged in VISUM as it effectively disables the sensitivity of the model to changes in junction geometry or signal timing.

There are two important network attributes that have an important influence on ICA results within VISUM:

Link attribute ‘ICAArrivalType’ describes the nature of traffic platoons. This should be calculated from the platoon progression on each link, and is used in lieu of signal offset values that are not applied within ICA turn delay calculations; and

Node attribute ‘Sneakers’ describes the minimum number of vehicles which will succeed in making an opposed right-turn within each cycle. A single value applies to all movements at the node. For opposed turns with high conflicting flows, the sneakers will be virtually all capacity available for that turn. Care should be taken in setting a realistic value based on the physical storage available within the intersection.

Within VISUM it is also recommended to define a lower threshold in a UDA ‘MINCAP’

which maintains a minimum capacity during ICA re-estimation. The lower threshold must be adjusted to be greater than, or equal to, the base volume. The following approach for this adjustment is suggested:

MINCAP = min(MINCAPorig, 1.1 * base volume) Eq. (1) where MINCAPorig refers to the original value (e.g. 100).