VISSIM - Flare Modelling
Introduction
Welcome to the latest Modelling Group blog post.
This time, we are going to focus on modelling Flares and provide some thoughts and tips, based on how we model these in VISSIM. We hope you find this useful.
Background
The traditional way of modelling flares in VISSIM has been to use one connector which joins a single lane link to a two-lane link. An example of this is shown in Figure 1.
This approach is recommended in Transport for London’s (TfL’s) ‘Model Auditing Process (MAP) – Engineer Guide, Section V211’.
It should also be noted that both PTV and TfL do not recommend the use of two connectors to join both lanes, with PTV’s Online FAQ – Network Editor (#VIS19204) (https://www.ptvgroup.com/en/solutions/products/ptv-vissim/knowledge-base/faq/) stating that “the functionality of VISSIM means vehicles will change lanes to the one which is connected to the single lane link and therefore only one route is possible”. This method usually results in vehicles making unnecessary lane changes when approaching the two connectors, which is unrealistic.
Figure 2 is from TfL’s ‘Traffic Modelling Guidelines, Para 5.3.1.5’, which shows this graphically.
VISSIM 6, Lists and the Training Directory
When PTV released VISSIM Version 6, this featured the introduction of ‘Lists’, which opened up additional functionality for a number of the network elements. One of these new features was the ability to have different lane widths within the same link.
PTV also introduced a number of example models in a ‘Training Directory’, which acted as a guide for showing how various features in VISSIM could be used. One such example was for ‘Merging and Weaving’, which used a link containing a lane with a 0.1m width to model an inside merge.
It is the use of the 0.1m lane width that has influenced our updated approach to modelling flares, with an example shown in Figures 3 & 4.
This method, whilst it looks a little different to the recommended approach by PTV and TfL, follows the same premise as we are still only using a single connector to join the two-lane link.
Figure 1 – Example of Traditional Flare Method
Figure 2 – Correct and Incorrect Merge Set-Ups
Figure 3 – Updated Flare Method – Link/Connector Set-Up
Figure 4 – Updated Flare Method – Network Layout
‘Flare’ Driver Behaviour
With this updated layout and the use of the default ‘Urban (motorised) driver behaviour, there will likely be some instances of vehicles that will move into the 0.1m wide lane before there is enough space to do so in reality, which creates artificial capacity on the flare.
Therefore, to reduce the instances of this happening, we have developed a ‘flare’ behaviour that is added to the connector.
The key parameters that we have adjusted to make the flare behaviour more realistic include:
Lateral - see Figure 5.2
- ‘Observe adjacent lanes’ – ticked
- ‘Consider next turn’ – ticked
By ‘observing adjacent lanes’, the vehicles take account of the position and lateral orientation of other vehicles on adjacent lanes. This prevents vehicles moving across too early when there is not enough space. The ‘consider next turn’ prevents a vehicle passing another vehicle on the same lane if this could cause a collision at the next turning connector, which adds another level of realism to the behaviour.
Lateral - see Figure 5.2
- ‘Default behaviour when overtaking vehicles on same or adjacent lane’ – for ‘overtake right’ – decreased distance from 1.00m to 0.20m at 30mph.
Lane Change - see Figure 5.3
- ‘Cooperative lane change’ – ticked
- Maximum deceleration for cooperative braking – increased from -3.00m/s2 to -4.00m/s2
These parameters work together and provide more opportunities and ‘gaps’ for vehicle to move across and change lanes.
Figure 5.1 – ‘Flare’ Driving Behaviour – Parameter Changes
Figure 5.2 – ‘Flare’ Driving Behaviour – Parameter Changes
Figure 5.3 – ‘Flare’ Driving Behaviour – Parameter Changes
Summary
We hope this post has helped to provide a bit of insight on we approach flared approaches in our models.
However, we are keen to stress that we have developed these settings and understanding of the functionality through trial and error on multiple projects and time invested in internal development. They do not represent a ‘one-size fits all’ approach and it may be that some adjustments to the parameters are needed for your own model calibration/validation purposes.
Despite this, we wanted to share our learning and hopefully there are some elements you can apply to your own models.
Thanks for reading!