This page describes simulations of bicycles in SUMO. To build an intermodal simulation scenario with bicycles, additional steps have to be take in comparison to a plain vehicular simulation.
The simulation of bicycles is a developing subject and still carries some difficulties. These are discussed below.
Approaches to bicycle modelling#
Currently, no exclusive movement model for bicycles is implemented. Existing models need to be re-purposed
Bicycles as slow vehicles#
In this case, vehicles are specified as vehicles with the appropriate type:
<vType id="bike" vClass="bicycle"/> <vehicle type="bike" .../>
Note, that that the
guiShape="bicycle" along with sensible default
automatically used when specifying
vClass="bicycle". By adapating vType-parameters for
different cyclist types can be modelled.
Problems and workarounds#
- Turning left by crossing twice does not work. Extra edges need to be added to accommodate these trajectories.
- No bi-directional movements on bicycle lanes
- No shared space for bicycles and pedestrians
- No overtaking by vehicles on a single-lane road. This can be fixed by using the Sublane Model.
- The intersection model has no special adaptations for bicycles. This results in unrealistic (large) safety gaps when bicycles are approaching a large priority intersection from a prioritized road
- The road speed limit is not meaningful for bicycles. To model a speed distribution for bicycles with a single vehicle type, a speed limit corresponding to the median speed of the bicycles should be set for the cycling lanes.
One way for overcoming most of these problems is to control bicycle movements at intersections with an external control script. This approach is described in Integration of an external bicycle model in SUMO, Heather Twaddle 2016.
Bicyles as fast pedestrians#
In this case, persons walking at high speed are used.
Problems and workarounds#
- No support for proper visualization - Movement model is not validated
Building a network for bicycle simulation#
The import of bicycle lanes from OpenStreetMap is supported since version 0.24.0. To use this, an appropriate typemap must be loaded.
Generating a network with bike lanes#
A bike lane is a lane which only permits the vClass bicycle. There are various different options for generating a network with bike lanes which are explained below. All of these options recognize the presence of an existing bike lane and will not add another lane in that case.
Explicit specification of additional lanes#
Bike lanes may be defined explicitly in plain XML input when describing edges edges (plain.edg.xml). This is done by defining an additional lane which only permits the vClass “bicycle” and setting the appropriate width. In this case it may be useful to disallow bicycles on other lanes. Also, any pre-exisiting connection definitions must be modified to account for the new bike lane.
Explicit specification of bike lanes#
Alternatively to the above method, the
bikeLanWidth may be used. It will cause a bike lane of the specified width to be added to that edge, connections to be remapped and bicycle permissions to be removed from all other lanes.
The heuristic methods described below, also perform automatic connection shifting and removal of bicycle permissions from non-bike lanes
When importing edges with defined types, it is also possible to declare that certain types should receive a sidewalk. This can be used to automatically generate bike lanes for residential streets while omitting them for motorways when importing OSM data.
<types> <type id="highway.motorway" numLanes="3" speed="44.44" priority="13" oneway="true" disallow="pedestrian bicycle"/> <type id="highway.unclassified" numLanes="1" speed="13.89" priority="5" bikeLaneWidth="1" disallow="bicycle"/> <type id="highway.residential" numLanes="1" speed="13.89" priority="4" bikeLaneWidth="1" disallow="bicycle"/> <type id="highway.living_street" numLanes="1" speed="2.78" priority="3"/> ... </types>
A special type file that imports bike lanes based on additional OSM attributes can be found in <SUMO_HOME>/data/typemap/osmNetconvertBicycle.typ.xml. This is to be preferred for importing bike lanes from OSM as it uses more accurate data.
A third option which can be used if no edge types are available is a heuristic based on edge speed. It adds a bike lane for all edges within a given speed range. This is controlled by using the following options:
|--bikelanes.guess <BOOL>||Guess bike lanes based on edge speed|
|--bikelanes.guess.max-speed <FLOAT>||Add bike lanes for edges with a speed equal or below the given limit default:13.89|
|--bikelanes.guess.min-speed <FLOAT>||Add bike lanes for edges with a speed above the given limit default:5.8|
||Specify a list of edges that shall not receive a bike lane|
Option --bikelanes.guess.from-permissons <BOOL> is suitable for networks which specify their edge permissions (such as DlrNavteq). It adds a bike lane for all edges which allow bicycles on any of their lanes. The option --bikelanes.guess.exclude <ID>[,<ID>]* applies here as well.
To add bike lanes to a set of edges in NETEDIT select these and right click on them. From the context-menu select lane operations->add restricted lane->Bikelane.
Notes on Right-of-Way rules#
When using bicycle lanes in a network, right-turning vehicles must yield for straight-going bicycles. The intersection model supports these right-of-way rules and builds internal junctions where appropriate.
Likewise, left-turning bicycles one a bicycle lane (on the right side of the road) must yield to straight-going vehicles.
The trajectories of left-turning bicycles use a wide curve rather than going straight twice. Currently, this can only be remedied by setting custom shapes for these internal lanes.