SUMO Road Networks Screenshot of a SUMO net file opened in sumo-gui. It shows the map of the German city Eichstätt.

SUMO road network
Filename extension .net.xml
Type of content Map
Open format? Yes
SUMO specific? Yes
XML Schema net_file.xsd

A SUMO network file describes the traffic-related part of a map, the roads and intersections the simulated vehicles run along or across. At a coarse scale, a SUMO network is a directed graph. Nodes, usually named "junctions" in SUMO-context, represent intersections, and "edges" roads or streets. Note that edges are unidirectional. Specifically, the SUMO network contains the following information:

  • every street (edge) as a collection of lanes, including the position, shape and speed limit of every lane,
  • traffic light logics referenced by junctions,
  • junctions, including their right of way regulation,
  • connections between lanes at junctions (nodes).

Also, depending on the used input formats and set processing options, one can also find

  • districts,
  • roundabout descriptions.

Although being readable (XML) by human beings, a SUMO network file is not meant to be edited by hand. Rather you should use SUMO XML description files together with netconvert. You can also convert an existing map from various formats using netconvert or generate geometrically simple, abstract road maps with netgenerate. To modify an existing .net.xml-file you may load it with netconvert along with patch files You may also use netedit for building own road networks or for reworking the ones obtained from netconvert or netgenerate.


When creating SUMO networks from custom input data, the recommended approach is to create/generate plain-xml-files and use netconvert to turn these into a .net.xml file. Trying to generate the .net.xml file directly is fraught with dangers.

Network Format#

SUMO road networks are encoded as XML files. The contents are grouped by the instances in the following order:

  • cartographic projection valid for this network
  • edges; at first, internal edges are given, then plain edges; each edge contains the list of lanes that belong to it
  • traffic light logics
  • junctions, including their right-of-way definitions; plain junctions first, then internal junctions
  • connections, plain first, then internal
  • optionally roundabouts

Coordinates and alignment#

The networks are using cartesian, metric coordinates where the leftmost node is at x=0 and the node being most at the bottom is at y=0. This means that when being imported, netconvert and netgenerate are projecting the network, first, if the original network was not using cartesian and/or metric coordinates. Then, they move the road network to the origin at (0,0).

This process is documented within the generated network within the element location. You may find here the following attributes:

Name Type Description
netOffset offset (<2D-POSITION>) The offset applied for moving the network to (0,0)
convBoundary boundary (<2D-BOUNDING_BOX>) The boundary spanning over the nodes of the converted network (the network as now given)
origBoundary boundary (<2D-BOUNDING_BOX>) The network's initial boundary before projecting and translating it
projParameter projection parameter Information how the network was projected (see below)

projParameter may have one of the following values:

Encoding Description
'!' No projection was applied.
'-' "Simple" projection was applied
'.' ?
proj-definition (<PROJ_DEFINITION>) The projection was done using proj, initialising it using these parameter.

For obtaining the original coordinates from the x/y-coordinates SUMO reports, one has to subtract the network offset first. Then, one has to apply an inverse transformation of the initial projection, regarding projParameter. For proj-projected networks, one can use proj's function named pj_inv which performs the inverse transformation. proj has to be initialised with the projection parameters from projParameter, first. For proj-projected networks this would look like:

Position2D cartesian = sumoXY(x, y);
projPJ myProjection = pj_init_plus(projParameter.c_str());
projUV p;
p.u = cartesian.x();
p.v = cartesian.y();
p = pj_inv(p, myProjection);
p.u *= RAD_TO_DEG;
p.v *= RAD_TO_DEG;
cartesian.set(p.u, p.v);

For networks with no projection (projParameter='!'), only the offset must be applied. For networks with "simple" projection (projParameter='-'), a back-projection method is currently not known.

SUMO road networks are meant to be aligned to the north. Of course, it is up to the user how he defines a road network, but when being imported from sources as Open Street Map or shape files, the up-direction is meant to correspond to north.

Edges and Lanes#

"plain" and "internal" edges are encoded almost the same way, but they differ by the mandatory and used attributes.

Normal Edges#

A "normal" edge is a connection between two nodes ("junctions").

<edge id="<ID>" from="<FROM_NODE_ID>" to="<TO_NODE_ID>" priority="<PRIORITY>">
    ... one or more lanes ...

Here, the ID (<ID> in the example above) is an ID as read during the network import. Both the IDs of the begin and the end node are given within the attributes from and to, respectively. The priority is an abstract ordinal number that determines right-of-way rules. The function attribute was omitted in the example above, as it defaults to "normal", which is the example edge's function value.

The attributes of an edge are:

Name Type Description
id id (string) The id of the edge
from id (string) The id of the node it starts at
to id (string) The id of the node it ends at
priority integer Indicates how important the road is (optional)
function enum ( "normal", "internal", "connector", "crossing", "walkingarea" ) An abstract edge purpose (optional with default "normal")

For the simulation, only the "function" attribute is of interest. It describes how the edge is used, and whether it is an edge that can be found within the real world or only a helper construct used for assignment. The following purposes are defined:

  • normal: The edge is a plain part of a road network, like a highway or a normal street which connects two roads
  • connector: The edge is a macroscopic connector - not a part of the real world road network. Still, within the simulation, no distinction is made between "connector" roads and "normal" nodes. Only sumo-gui allows to hide connector edges.
  • internal: The edge is a part of an intersection (is located within the intersection), see above.
  • crossing:
  • walkingarea:


Each edge includes the definitions of lanes it consists of. The following example shows a single edge with two lanes. Note, that coordinates may be 2D as well as 3D.

    <edge id="<ID>" from="<FROM_NODE_ID>" to="<TO_NODE_ID>" priority="<PRIORITY>">
        <lane id="<ID>_0" index="0" speed="<SPEED>" length="<LENGTH>" shape="0.00,495.05 248.50,495.05"/>
        <lane id="<ID>_1" index="1" speed="<SPEED>" length="<LENGTH>" shape="0.00,498.35,2.00 248.50,498.35,3.00"/>

As one can see, the id is composed by the ID of the edge the lane belongs to and a running number, both divided by an underline ('_'). The running number starts at zero for the right-most lane. The same number is also given in the "index" attribute. The lanes are sorted by this number, too. @note: this is highly duplicate

The attributes of a lane are:

Name Type Description
id id (string) The id of the lane
index running number (unsigned int) A running number, starting with zero at the right-most lane
speed float The maximum speed allowed on this lane [m/s]
length float The length of this lane [m]
shape position vector The geometry of the lane, given by a polyline that describes the lane's center line; must not be empty or have less than two positions

It should be noted, that currently all lanes of an edge have the same length, even if it differs from the geometrical length of the shape. netconvert even explicitly allows to override the geometrical lengths. Additionally, even though the network is shifted to start at (0,0), it is not guaranteed that all of the network's parts have positive coordinates.


The minimum edge length is 0.1m.

Internal Edges#

An internal edge lies within an intersection and connects and incoming normal edge with an outgoing normal edge. Internal edges are not included if the network was built using the --no-internal-links option. An example of an internal edge may look like this:

<edge id="<ID>" function="internal">
    ... one lane ...

The id of an internal edge is composed as :<NODE_ID>_<EDGE_INDEX> where <NODE_ID> is the ID of the node the edge is located within and <EDGE_INDEX> is a running number running clockwise around the node (starting in the north). Please note that the ID has a ':' as prefix. If the incoming and outgoing edges connected by the internal edge have multiple lanes, the internal edge has multiple lanes as well (according to the number of connections between these two edges). In case of multi-lane internal edges, the INDEX jumps by the number of lanes so that EDGE_INDEX + LANE_INDEX = CONNECTION_INDEX.

The attributes are given in the following table.

Name Type Description
id id (string) The id of the internal edge
function "internal" Always "internal" for an internal edge

When the network was built with internal edges, each connection will typically correspond to exactly one internal lane. If there are multiple connections that have the same pair of from and to edges, then the internal lanes for these edges will be part of the same internal edge. On connections marked as straight (dir="s"), lane changing on internal lanes is permitted.

Special cases are so called internal junctions. These mark places where vehicles wait within an intersection before passing through foe traffic. The most common occurrence for this are:

  • left-turning vehicles that yield to oncoming traffic
  • right-turning vehicles that yield to pedestrian crossings

The connection corresponding to such a movement are split into two internal lanes: one lane before the waiting position and one lane after the waiting position. The lanes after an internal junction always have their own internal edge.

Stop Offsets#

Each edge or lane may carry a stopOffset child element to specify an additional stopping offset for vehicles of certain classes. This can be used to define a bike box. The exact syntax is explained at stopOffset.

Traffic Light Programs#

A traffic light program defines the phases of a traffic light.

    <tlLogic id="<ID>" type="<ALGORITHM_ID>" programID="<PROGRAM_ID>" offset="<TIME_OFFSET>">
        <phase duration="<DURATION#1>" state="<STATE#1>"/>
        <phase duration="<DURATION#1>" state="<STATE#1>"/>
        ... further states ...
        <phase duration="<DURATION#n>" state="<STATE#n>"/>

For an explanation of the attributes and semantics, please consult Simulation/Traffic Lights. Please note that usually, the generated program has the ID "0".

Junctions and Right-of-Way#

Plain Junctions#

Junctions represent the area where different streams cross, including the right-of-way rules vehicles have to follow when crossing the intersection. An example may be:

<junction id="<ID>" type="<JUNCTION_TYPE>" x="<X-POSITION>" y="<Y-POSITION>"
          incLanes="<INCOMING_LANES>" intLanes="<INTERNAL_LANES>"
    ... requests ...

The junction itself is described by the following attributes:

Name Type Description
id id (string) The id of the junction; By default, a traffic light controlling this junction will have the same id but this may changed by the user or when joining traffic lights.
x x-position (real) The x-coordinate of the intersection
y y-position (real) The y-coordinate of the intersection
z z-position (real) The (optional) z-coordinate of the intersection
incLanes id list The ids of the lanes that end at the intersection; sorted by direction, clockwise, with direction up = 0
intLanes id list The IDs of the lanes within the intersection
shape position list A polygon describing the road boundaries of the intersection
customShape bool Whether the shape was customized by the user (and should thus not be rebuilt by netconvert or netedit), default False

Please note, that the x/y-positions of the junction describe the given, not the computed center of the junction. It is allowed for two nodes to have the same position.


The maximum number of connections (links) per junction is limited to 256 since version 0.25.0. In earlier versions of sumo the limit was 64.


What follows are "request"s, looking like:

  <request index="<INDEX>" response="<RELATIVE_MAJOR_LINKS>" foes="<FOE_LINKS>" cont="<MAY_ENTER>"/>

They describe, for each link (given as "index") which streams have a higher priority ("response") and force the vehicle on link "index" to stop, and which streams are in conflict ("foes"). "foes" is a super-set of "response", adding streams that have a lower priority than the stream referenced as "index".

One can read the requests as following: the index describes a certain connection, between an incoming and an outgoing lane, over the intersection. The indices are computed connection-wise and the order is as following: first, sort edges by their direction, starting with 0° (up); second, use lane order (right-most-first); third, order by the direction the connection follows, starting by the right-most.

The same order is applied in the "response" and the "foes" field, starting from right. This means:

  <request index="2" response="001" foes="011" cont="0"/>

The a vehicle using the connection with the index "2" has to wait for vehicles that use the connection "0". Connections "0" and "1" are its foes. The attributes of a request element are:

Name Type Description
index index (unsigned int) The index of the described connection in the right-of-way matrix
response bitset (string) A bitstring that describes for each connection whether it prohibits un-decelerated passing of the intersection for vehicles at this connection. The rightmost bit corresponds to index 0.
foes bitset (string) A bitstring that describes for each connection whether it conflicts with this connection. The rightmost bit corresponds to index 0.
cont bool Whether a vehicle may pass the first stop line to wait within the intersection until there are no vehicles with higher priority. This is typically the case for left-moving streams from the prioritized direction.


The bitstrings in attributes response and foes must be read from right to left (response to link 0 is the rightmost entry) in contrast to tlLogic-state strings which are read from left to right (state of link 0 is the leftmost entry).

Internal Junctions#

"internal" junctions are used to define a waiting position within the intersection for some traffic relations. This is typically used for left-turning vehicles from the prioritized direction or for right-turning vehicles that have to wait for straight-going pedestrians.

Since version 0.25.0 the user can customize the positioning (and presence) of internal junctions

These junctions do not need a right-of-way matrix but only following information

  • the lanes that are incoming into the junction the internal junction is located in and prohibit to pass the internal junction if a vehicle is approaching
  • the internal lanes that must not be occupied for crossing the internal junction

An internal junction is encoded like this:

<junction id="<ID>" type="internal" x="<X-POSITION>" y="<Y-POSITION>"

The ID is the same as the lane to use when crossing the internal junction itself. The type is always "internal". Please note that an internal junction is usually encoded in one line. The attributes of an internal junction are:

Name Type Description
id id (string) The id of the internal junction; It always starts with : followed by the id of the parent junction, then an _and finally a unique index.
x x-position (real) The x-coordinate of the intersection
y y-position (real) The y-coordinate of the intersection
z z-position (real) The (optional) z-coordinate of the intersection
incLanes id list The ids of the lanes that end at the intersection the internal junction is located within and prohibit to cross the internal junction
intLanes id list The ids of the lanes within the intersection the internal junction is located within and prohibit to cross the internal junction


Plain Connections#

Plain connections or "links" describe which outgoing lanes can be reached from an incoming lane. Additionally, the first lane to use for passing the intersection is given. Additional information describe the direction and the "state" of the connection. If the connection is controlled by a traffic light, the name of the traffic light and the index of the signal that controls this connection within the traffic light's phase definition is given. A connection is encoded as:

<connection from="<FROM_EDGE_ID>" to="<TO_EDGE_ID>" fromLane="<FROM_LANE_INDEX>" toLane="<TO_LANE_INDEX>"
            via="<VIA_LANE_ID>" tl="<TRAFFIC_LIGHT_ID>" linkIndex="12" dir="r" state="o"/>

The attributes are:

Name Type Description
from edge id (string) The ID of the incoming edge at which the connection begins
to edge id (string) The ID of the outgoing edge at which the connection ends
fromLane index (unsigned int) The lane of the incoming edge at which the connection begins
toLane index (unsigned int) The lane of the outgoing edge at which the connection ends
via lane id (string) The id of the lane to use to pass this connection across the junction
tl traffic light id (string) The id of the traffic light that controls this connection; the attribute is missing if the connection is not controlled by a traffic light
linkIndex index (unsigned int) The index of the signal responsible for the connection within the traffic light; the attribute is missing if the connection is not controlled by a traffic light
dir enum ("s" = straight, "t" = turn, "l" = left, "r" = right, "L" = partially left, R = partially right, "invalid" = no direction) The direction of the connection
state enum ("-" = dead end, "=" = equal, "m" = minor link, "M" = major link, traffic light only: "O" = controller off, "o" = yellow flashing, "y" = yellow minor link, "Y" = yellow major link, "r" = red, "g" = green minor, "G" green major) The state of the connection

When creating these connections without netconvert (not recommended) it should be taken into account that a connection with an internal lane follows a special pattern. For example when lane 1_f_0 needs to be connected to 1_t_0 through 1_v_0, the following connection entries exist: [from=1_f_0, to=1_t_0 via=1_v_0] and [from=1_v_0 to=1_t_0]. If the latter is omitted, SUMO will not load the network. It will also not load if next to the necessary connections a connection [from=1_f_0 to=1_v_0] exists.

Indices of a connection#

Each connection has associated indices which can be shown in sumo-gui by customizing gui settings and activating Junctions->Show ... index. These indices are usually identical but may be configured independently of each other.

  • Junction Index: This index is described in section #Requests. It cannot be modified. The index corresponds to the order of the <junctions>s incLanes-attribute and also to the order of the <connection> elements. These indices run clockwise (in a right-hand network) around the junction starting at the top.
  • TLS Index: This index is assigned to connections which are controlled by a traffic light. For joined traffic lights (controlling multiple junctions) this index differs from the junction index because the latter is no longer unique. The TLS Index may be configured with a .con.xml file. Custom indices may be used to create signal groups (multple connections that always have the same state and share the same index) and thus simplify the state definiton for the traffic light phases.


Roundabouts in a network influence the right of way (encoded in the Requests <request> elements of a junction during network building). Their presence in the network file has two reasons:

  • It facillitates re-importing a .net.xml-file with netconvert
  • lane-changing models may take roundabouts into account

Each roundabout is defined (somewhat redundantly) by its nodes and edges:

<roundabout nodes="nodeID1 nodeID2 ..." edges="edgeID1 edgeID2 ..."/>

Software for Viewing, Editing and Processing#

To create a SUMO network file, netconvert helps to generate it from maps in other formats and netgenerate constructs a new map with simple geometries. sumo performs its simulation directly in the map of this file. Most other SUMO tools read such files to generate or import information that must be the mapped onto a road network.

Networks can be created and edited graphically using netedit.

The SUMO net file is not meant for manual editing. Convert it to the SUMO native XML descriptions with netconvert instead. You can then process these files by hand and rebuild the network with netconvert.

Further Documentation#


Please see the ChangeLog when dealing with networks generated by old versions of netconvert / netgenerate.