Introduction#
SUMO allows modelling access restrictions via a predefined set of so-called vehicle classes. Each vehicle has a vehicle class and each simulation lane allows a set of vehicle classes. Vehicles may only drive on lanes that allows it's vehicle class.
This is useful for describing multi-modal traffic scenarios by distinguishing between passenger cars, bicycles, tram and pedestrians.
Vehicle definition#
The vehicle class of a vehicle is defined by first defining a vehicle type with the appropriate vehicle class and thenassigning that type to the vehicle. An example is given below:
<routes>
<vType id="myType" vClass="bus"/>
<vehicle id="veh0" type="myType" depart="0">
<route edges="a b c"/>
</vehicle>
</routes>
If no such definition is given, the vehicle class defaults to passenger (normal passenger cars). By setting the attribute, a set of default type parameters is automatically assigned to better correspond to a typical vehicle of that class.
Network definition#
In a .net.xml file, each lane defines a set of permitted vehicle classes. This definition is either
- taken from custom input
files.
It possible to define permissions for edges or individual lanes. To
simplify definition, either the permitted classes or the prohibited
classes can be specified using the attributes
allow, disallow. - set using the option --default.disallow <STRING>,...
- imported from an input source such as OpenStreetMap according to a customizable heuristic.
- or set via netedit. Convenience features exist for adding bicycle lanes, bus lanes and sidewalks.
For visualizing access permissions, either sumo-gui or netedit may be used.
Special cases#
The vehicle class ignoring may drive on any edge.
The vehicle class pedestrian should not be assigned to a vehicle. Instead, pedestrians should be modeled as walking persons. During network building, no direct connections between pedestrian-only lanes are built. Instead options for building pedestrian intersections should be used.