Within the nodes-files, normally having the extension ".nod.xml" (see Appendix "Naming Conventions"), every node is described in a single line which looks like this: <node id="<STRING>" x="<FLOAT>" y="<FLOAT>" [type="<TYPE>"]/> - the straight brackets ('[' and ']') indicate that the parameter is optional. Each of these attributes has a certain meaning and value range:

When writing your nodes-file, please do not forget to embed your node definitions into an opening and a closing "tag". A complete file should like the example below, which is the node file "cross3l.nod.xml" for the examples "<SUMO_DIST>/data/examples/netbuild/types/cross_usingtypes/" and "<SUMO_DIST>/data/examples/netbuild/types/cross_notypes/" example.

<nodes> <!-- The opening tag -->

   <node id="0" x="0.0" y="0.0" type="traffic_light"/> <!-- def. of node "0" -->

   <node id="1" x="-500.0" y="0.0" type="priority"/> <!-- def. of node "1" -->
   <node id="2" x="+500.0" y="0.0" type="priority"/> <!-- def. of node "2" -->
   <node id="3" x="0.0" y="-500.0" type="priority"/> <!-- def. of node "3" -->
   <node id="4" x="0.0" y="+500.0" type="priority"/> <!-- def. of node "4" -->

   <node id="m1" x="-250.0" y="0.0" type="priority"/> <!-- def. of node "m1" -->
   <node id="m2" x="+250.0" y="0.0" type="priority"/> <!-- def. of node "m2" -->
   <node id="m3" x="0.0" y="-250.0" type="priority"/> <!-- def. of node "m3" -->
   <node id="m4" x="0.0" y="+250.0" type="priority"/> <!-- def. of node "m4" -->

</nodes> <!-- The closing tag -->

As you may notice, only the first node named "0", which is the node in the middle of the network, is a traffic light controlled junction. All other nodes are uncontrolled. You may also notice, that each of both ends of a street needs an according node. This is not really necessary as you may see soon, but it eases the understanding of the concept: every edge (street/road) is a connection between two nodes (junctions).

You should also know something about the coordinate system: the higher a node on the screen shall be (the nearer to the top of your monitor), the higher his y-value must be. The more to left it shall be, the higher his x-value.

Figure 4.3. Coordinate system used in SUMO

Since version 0.9.4 you can also give the x- and y-coordinates using geocoordinates. In this case, the coordinates will be interpreted as long/lat in degrees. Read more on this in "Converting from Geocoordinates".

Edges are described quite the same way as nodes, but posses other parameter. Within the edges file, each description of a single edge looks like this: <edge id="<STRING>" (fromnode="<NODE_ID>" tonode="<NODE_ID>" | xfrom="<FLOAT>" yfrom="<FLOAT>" xto="<FLOAT>" yto="<FLOAT>") [type="<STRING>" | nolanes="<INT>" speed="<FLOAT>" priority="<UINT>" length="<FLOAT>")] [shape="<2D_POINT> [ <2D_POINT>]*"] [spread_type="center"]/>.

What does it mean? Every one who knows how XML-files look like should have noticed brackets ('(' and ')') and pipes ('|') within the definition and these characters are not allowed within XML... What we wanted to show which parameter is optional. So for the definition of the origin and the destination node, you can either give their names using fromnode="<NODE_ID>" tonode="<NODE_ID>" or you give their positions using xfrom="<FLOAT>" yfrom="<FLOAT> xto="<FLOAT>" yto="<FLOAT>". In the second case, nodes will be build automatically at the given positions. Each edge is unidirectional and starts at the "from"-node and ends at the "to"-node. If a name of one of the nodes can not be dereferenced (because they have not been defined within the nodes file) an error is generated (see also the documentation on "--dismiss-loading-errors" in subchapter "Building the Network").

For each edge, some further attributes should be supplied, being the number of lanes the edge has, the maximum speed allowed on the edge, the length the edge has (in meters). Furthermore, the priority may be defined optionally. All these values - beside the length in fact - may either be given for each edge using according attributes or you can omit them by giving the edge a "type". In this case, you should also write a type-file (see subchapter "Types Descriptions"). A type with this name should of course be within the generated type-file, otherwise an error is reported. Even if you supply a type, you can still override the type's values by supplying any of the parameter nolanes, speed and priority. You may also leave the edge parameter completely unset. In this case, default-values will be used and the edge will have a single lane, a default (unset) priority and the maximum allowed speed on this edge will be 13.9m/s being around 50km/h. The length of this edge will be computed as the distance between the starting and the end point.

As an edge may have a more complicated geometry, you may supply the edge's shape within the shape tag. If the length of the edge is not given otherwise, the distances of the shape elements will be summed. The information spread_type="center" forces NETCONVERT to spread lanes to both sides of the connection between the begin node and the end node or from the list of lines making up the shape. If not given, lanes are spread to right, as default.

Let's list an edge's attributes again:

The priority plays a role during the computation of the way-giving rules of a node. Normally, the allowed speed on the edge and the edge's number of lanes are used to compute which edge has a greater priority on a junction. Using the priority attribute, you may increase the priority of the edge making more lanes yielding in it or making vehicles coming from this edge into the junction not wait.

Also the definitions of edges must be embedded into an opening and a closing tag and for the example "<SUMO_DIST>/data/examples/netbuild/types/cross_notypes/" the whole edges-file looks like this ("cross3l.edg.xml"):

<edges>

   <edge id="1fi" fromnode="1" tonode="m1" priority="2" nolanes="2" speed="11.11"/>
   <edge id="1si" fromnode="m1" tonode="0" priority="3" nolanes="3" speed="13.89"/>
   <edge id="1o" fromnode="0" tonode="1" priority="1" nolanes="1" speed="11.11"/>

   <edge id="2fi" fromnode="2" tonode="m2" priority="2" nolanes="2" speed="11.11"/>
   <edge id="2si" fromnode="m2" tonode="0" priority="3" nolanes="3" speed="13.89"/>
   <edge id="2o" fromnode="0" tonode="2" priority="1" nolanes="1" speed="11.11"/>

   <edge id="3fi" fromnode="3" tonode="m3" priority="2" nolanes="2" speed="11.11"/>
   <edge id="3si" fromnode="m3" tonode="0" priority="3" nolanes="3" speed="13.89"/>
   <edge id="3o" fromnode="0" tonode="3" priority="1" nolanes="1" speed="11.11"/>

   <edge id="4fi" fromnode="4" tonode="m4" priority="2" nolanes="2" speed="11.11"/>
   <edge id="4si" fromnode="m4" tonode="0" priority="3" nolanes="3" speed="13.89"/>
   <edge id="4o" fromnode="0" tonode="4" priority="1" nolanes="1" speed="11.11"/>

</edges>

Within this example, we have used explicit definitions of edges. An example for using types is described in the chapter "Types Descriptions".

	Caution
	There are some constraints about the streets' ids. They must not contain any of the following characters: '_' (underline - used for lane ids), '[' and ']' (used for enumerations), ' ' (space - used as list divider), '*' (star, used as wildcard), ':' (used as marker for internal lanes).

Recent changes:

4.2.2.1. Defining allowed Vehicle Types

Since version 0.9.5 you may allow/forbid explicite vehicle classes to use a lane. The information which vehicle classes are allowed on a lane may be specified within an edges descriptions file by embedding the list of lanes together with vehicle classes allowed/forbidden on them into these lanes' edge. Assume you want to allow only busses to use the leftmost lane of edge "2si" from the example above. Simply change this edge's definition into:

... previous definitions ...
   <edge id="2si" fromnode="m2" tonode="0" priority="3" nolanes="3" speed="13.89">
      <lane id="2" allow="bus"/>
   <edge>
... further definitions ...

If you would like to disallow passenger cars and taxis, the following snipplet would do it:

... previous definitions ...
   <edge id="2si" fromnode="m2" tonode="0" priority="3" nolanes="3" speed="13.89">
      <lane id="2" disallow="passenger;taxis"/>
   <edge>
... further definitions ...

The definition of a lane contains by now the following attributes:

• id: The enumeration id of the lane (0 is the rightmost lane, <NUMBER_LANES>-1 is the leftmost one)

• allow: The list of explicitely allowed vehicle classes

• disallow: The list of explicitely disallowed vehicle classes

Both the allowed and the disallowed attributes assume to get a list of vehicle class names devided by a ';'. See "Vehicle Classes" for further information about allowed vehicle classes and their usage.

	Caution
	This is a new feature. Its usage and the way it works will surely change in the future.

Examples: none yet

Recent changes:

• The possibility to define which vehicle classes are allowed on a lane was added in version 0.9.5

As mentioned, road types are meant to be used to ease the definition of edges. As described above, the description of an edge should include information about the number of lanes, the maximum speed allowed on this edge and the edge's priority. To avoid the explicit definition of each parameter for every edge, one can use road types, which encapsulate these parameter under a given name. The format of this definition is: <type id="<STRING>" nolanes="<INT>" speed="<FLOAT>" priority="<UINT>"/>.

The attributes of a type are of course exactly the same as for edges themselves:

The information about the nodes the edge starts and ends at is not given within the types' descriptions. They can only be set within the edge's attributes. Here's an example on referencing types in edge definitions:

<edges>

   <edge id="1fi" fromnode="1" tonode="m1" type="b"/>
   <edge id="1si" fromnode="m1" tonode="0" type="a"/>
   <edge id="1o" fromnode="0" tonode="1" type="c"/>

   <edge id="2fi" fromnode="2" tonode="m2" type="b"/>
   <edge id="2si" fromnode="m2" tonode="0" type="a"/>
   <edge id="2o" fromnode="0" tonode="2" type="c"/>

   <edge id="3fi" fromnode="3" tonode="m3" type="b"/>
   <edge id="3si" fromnode="m3" tonode="0" type="a"/>
   <edge id="3o" fromnode="0" tonode="3" type="c"/>

   <edge id="4fi" fromnode="4" tonode="m4" type="b"/>
   <edge id="4si" fromnode="m4" tonode="0" type="a"/>
   <edge id="4o" fromnode="0" tonode="4" type="c"/>

</edges>

The according types file looks like this:

<types>

   <type id="a" priority="3" nolanes="3" speed="13.889"/>
   <type id="b" priority="2" nolanes="2" speed="11.111"/>
   <type id="c" priority="1" nolanes="1" speed="11.111"/>

</types>

As you can see, we have joined the edges into three classes "a", "b", and "c" and have generated a description for each of these classes. Doing this, the generated net is similar to the one generated using the settings described above (example "<SUMO_DIST>/data/examples/netbuild/types/cross_notypes/" ).

Examples:

Recent changes:

After you have generated the files you need being at least the edges and the nodes-files and optionally also a type and/or a connections file you should run NETCONVERT to build the network. The call should look like:

netconvert --xml-node-files=MyNodes.nod.xml --xml-edge-files=MyEdges.edg.xml \
   --output-file=MySUMONet.net.xml

if you only use edges and nodes. Types and connections may be given as:

netconvert --xml-node-files=MyNodes.nod.xml --xml-edge-files=MyEdges.edg.xml \
   --xml-connection-files=MyConnections.con.xml --xml-type-files=MyTypes.typ.xml \
   --output-file=MySUMONet.net.xml

Maybe your edge definitions are incomplete or buggy. If you still want to import your network, you can try passing "--dismiss-loading-errors" to NETCONVERT. In this case, edges which are not defined properly, are omitted, but NETCONVERT tries to build the network anyway. You may also flip the network around the horizontal axis. Use option "--flip-y" for this.

You may also use abbreviations for the option names. These abbreviations and options used when building SUMO-networks from own XML-descriptions are:

See also:

Examples:

Almost all networks within the <SUMO_DIST>/data/ - folder. Additionally some examples that cover the mentioned topics are:

Recent changes:

NETCONVERT is able to directly read binary NavTech's ArcView databases. To convert such databases, you need at least three files: a file with the extension ".dbf", one with the extension ".shp" and one with the extension ".shx". Additionally, having a projection file with the extension ".proj" is of benefit. Since version 0.9.2 we do not suply the possibility to use different names for the files, so all files should have the same name besides the extension. To build your network from an ArcView-database use the option "--arcview=<FILENAME_WITHOUT_EXTENSION>":

netconvert --arcview=MyArcViewDB --output-file=MySUMONet.net.xml

This call will force NETCONVERT to read the files "MyArcViewDB.dbf", "MyArcViewDB.shx", and "MyArcViewDB.shp" (and possibly "MyArcViewDB.proj" and to generate a network named "MySUMONet.net.xml". We have been asked which fields are read from ArcView-files. As said before, the reader was build to read ArcView-files containing road networks from NavTech. Due to this the following fields are used as default:

The problem is, that not all networks stored as ArcView-databases also use this naming scheme. During some further work with ArcView-networks, some further options got necessary which allow to name the fields the used database contains. The column the street name shall be read from may be specified using --arcview.street-id <STREET_NAME_COLUMN_NAME>. You can also name the columns the names of the edges' origin and destination nodes shall be read from using --arcview.from-id <START_NODE_ID_COLUMN_NAME> and --arcview.to-id <END_NODE_ID_COLUMN_NAME>. If the no information about the starting/ending nodes is given and your database does not contain the columns "REF_IN_ID" and "NREF_IN_ID", nodes will be placed into the network at the positions the streets end.

Since version 0.9.2 we also allow to override the rather "fuzzy" information about an edge's attributes from NavTech using own fields:

This idea came from John Michael Calandrino.

Some databases do not contain explicite information about the edges' attributes (number of lanes, priority, allowed speed) at all. Since version 0.9.4 you can use types as described in "Types Descriptions" to describe your edges' attributes. You have to name the column to retrieve the information about a street's type from using --arcview.type-id <TYPE_ID_COLUMN_NAME>. Of course, you have then to supply a type-file using --xml-type-files <TYPES_FILE> (or --types or -t ). If something fails with the types or the explicite values, you can catch it using --arcview.use-defaults-on-failure. Besides this, you can specify your own connections using --xml-connection-files <CONNECTIONS_FILE> (or --xml-connections or -x, see "Connection Descriptions").

ArcView-networks are (mostly?) encoded using geocoordinates which have to be converted to the cartesian coordinates system used by SUMO. Our current implementation is not yet fully developed, it works for the most cases, but you should not be surprised if it fails with a certain network. Contact us in this case, please. To describe how to convert the coordinates, you should know in which UTM-zone your network is located. Pass this to NETCONVERT using --arcview.utm <ORIGINAL_UTM_ZONE>. If the conversion can not be initialised, you may additionally use --arcview.guess-projection to let NETCONVERT guess the conversion by him own.

Specific options:

See also:

Examples: none yet

Recent changes:

Although Vissim is a microscopic simulation as SUMO is, it follows a completely different concept of modelling traffic. Due to this, the import is quite clumsy and may not work with all networks. Also, we have to insert additional edges into our networks to simulate the Vissim-parking places, originally being nodes, which we do not have. An usage example could be this one:

netconvert --vissim=<VISSIM_FILE> --output-file=MySUMOFile.net.xml

Vissim-networks do possibly not contain explicit definitions of an edge's speed. We have to propagate once set velocities, but even then some edges' speeds may not be defined. The option "--vissim.default-speed" may change the default speed used in the case an edge's speed is not defined. The default value for this parameter is 13.89m/s, being around 50km/h. The second parameter "--vissim.speed-norm" describes the factor to multiply a described flows maximum velocity to gain the velocity to use. The default value is 1.

Furthermore, as we have to use geometrical heuristics, a further factor steers the process of converting Vissim-networks: simply spoken, "--vissim.offset" holds the information how near two nodes must be (in meters) to be joined.

During import, different actions must be done which may yield in some loss of data and may be watched in part by setting the verbose option. The additional warnings the import of Vissim-networks generates will be described in a further document.

Specific options:

Known problems:

Examples: none yet (we do not own a network we could give away for legal reasons)

Recent changes:

Visum is a macroscopic simulation developed by ptv. NETCONVERT is capable to read VISUM-networks written as .net files. An usage import call could be this one:

netconvert --visum=<VISUM_FILE> --output-file=MySUMOFile.net.xml

As the network description may not contain any information about the number of lanes, we have to generate it from the street's flow. The computation is done by dividing the flow through a fix value, 2000 by default. This yields in a realistic network but fails on 'feeder roads' where vehicles are emitted.

You can also specify your own connections using --xml-connection-files <CONNECTIONS_FILE> (or --xml-connections or -x, see "Connection Descriptions").

Not all parts of the Visum-Format are read; below you'll find a table which contains the information which Visum-tables are imported.

Specific options:

See also:

Examples: none yet (we do not own a network we could give away for legal reasons)

Recent changes:

You can convert both the splitted and the unsplitted version of files generated by Elmar from NavTech-files. There seems to be no difference between the results in the networks' topologies, but the names of junctions and roads change. The option --elmar loads the splitted definitions, --elmar2 the unsplitted. Both options await the prefix as generated by Elmar's converter, an optional path is allowed. Example:

netconvert --elmar=berlin_ --output-file=MySUMOFile.net.xml

Imports the descriptions of nodes from "berlin_nodes.txt" and the edges from "berlin_links.txt".

You can also specify your own connections using --xml-connection-files <CONNECTIONS_FILE> (or --xml-connections or -x, see "Connection Descriptions").

Specific options:

See also:

Examples: none yet (we do not own a network we could give away for legal reasons)

This import function is in a rather experimental state. We need someone who owns a network she/he knows and who could give us an advice whether the import work as expected. You still may try it out using the option --tiger=<FILE_PREFIX>.

You can also specify your own connections using --xml-connection-files <CONNECTIONS_FILE> (or --xml-connections or -x, see "Connection Descriptions").

See also:

Examples: none yet

We have mentioned, that edge parameter may be omitted and defaults will be used in this case. You have the possibility to define these defaults using the following options:

These options may be used while importing the following formats:

Examples: none yet

Normally, turnarounds are added as a possible edge continuations and play an important role during network building (see [Krajzewicz_et_al2005_2]). Still, one may want not to add them. In this cases, it is possible to disallow their appending using option "--no-turnarounds".

Specific option:

This options may be used while importing the following formats:

Recent changes:

In most input networks one may find nodes where one street comes in and one with the same attributes goes out or where two parallel edges come in and two (with the same attributes) come out. Such nodes have mostly no meaning (maybe besides the additional possibility to make a U-turn) and may be removed. The removal of such nodes increases the simulation speed due to a smaller number of edges to process during each time step. To remove such nodes and join the incoming and outgoing edges use "--remove-geometry". The removal of nodes preserves the geometry of edges by ading a further geometry point at the removed node's position.

Specific option:

This options may be used in conjunction with all import formats.

Recent changes:

Some people do not like to use speed definitions in m/s. If you want to define the speeds allowed on your edges in km/h instead, you should pass the following option to NETCONVERT:

This option may be used while importing the following formats:

Examples:

Recent changes:

Some of the supported network formats supply information about the logic of the traffic lights, other do not. Due to this, we have to compute the traffic lights by our own. Doing this, we do not only have to compute the plans, but of course also, on which junction traffic lights are positioned. There are several options steering this procedure. At first, you have to tell NETCONVERT/NETGEN that you wish him to guess positions of traffic lights. This is done using the "--guess-tls"-option. Then, you have the possibility to describe the junctions at which you think a tls shall be placed using description of incoming and outgoing edges: "--tls-guess.no-incoming-min", "--tls-guess.no-incoming-max", "--tls-guess.no-outgoing-min" and "--tls-guess.no-outgoing-max" constraint the building of a tls by the number of the lanes incoming/outgoing edges have. All these four options require an int as parameter. Furthermore, you may constraint the junctions by giving the minimum/maximum of allowed speed on edges that participate: "--tls-guess.min-incoming-speed", "--tls-guess.max-incoming-speed", "--tls-guess.min-outgoing-speed", and "--tls-guess.max-outgoing-speed".

	Caution
	No, we do not have a validated set of these option's settings, yet.

You may also set junctions as tls-controlled using "--explicite-tls" or as uncontrolled using "--explicite-no-tls". Both options assume to get a list of node names divided by ',' as parameter. The behaviour when a node is in both lists is undefined.

If you want to know where traffic lights have been inserted and your network is too large to evaluate this by hand, you can force NETCONVERT to write a list of POIs where each POI is placed on a tls-controlled junction. This allows you to tae a look at all the positions tls have been inserted at. The option for doing this is --tls-poi-output <FILENAME> where <FILENAME> is the filename to write the POIs into.

Normally, only one traffic lights logic (phases definition) is computed per a traffic lights controlled junction, but the algorithm we use is able to compute several logics. To force the computation of all possible logics, use "--all-logics". Remind, that all logics will be written to the network file and that we have no tools for further procesing of these logics.

During the computation of tls-logics among other information we have to guess the duration of the phases. The options "--traffic-light-green" and "--traffic-light-yellow" allow you to give the durations of green and yellow lights. Both options assume the duration in s as an int as parameter. The duration of having red is dependant to the number of other phases and their green and yellow phase durations. The green phase length has a default of 20s, yellow lights are - if no value is set for this option - computed using the "--min-decel" - value described below.

One has to remind one thing: dead times are necessary to avoid collisions of vehicles which do not manage to break as they are too near to the traffic light when it switches to red. This time may be computed, and is, but depends on the maximum deceleration possibility of the vehicles used. As this parameter is not known to the network builder at all - the vehicle types are supported to the simulation only - the option "--min-decel" (or -D for short) is used to set the minimum deceleration of vehicles. The default is 3.0 in m/s^2.

There is no possibility to compute or estimate green light districts, yet. You have only the options to shift the computed phases by half of their duration or by a quarter of their duration. The options for this are: "--tl-logics.half-offset" and "--tl-logics.quarter-offset". Both options assume to get a list of node names divided by ',' as parameter. The behaviour when a node is in both lists or if the node is not meant to be controlled by a tls is undefined.

Specific options:

These options may be used while importing the following formats:

Recent changes:

Most of the imported network descriptions do not have information about highway on- and off-ramps. You can force NETCONVERT to guess where on- and off-ramps shall be build. To enable this, use the option "--guess-ramps". The algorithm assumes that an on-ramp shall be build on highway junctions with one incoming and one outgoing highway edge and one incoming minor edge and that an off-ramp shall be build on highway junctions with one incoming and one outgoing highway edge and one outgoing minor edge. You can constrain what a highway is by giving its minimum speed of this edge using "--ramp-guess.min-highway-speed" and what a minor edge is by giving its maximum speed using "--ramp-guess.max-ramp-speed". Both options assume a float parameter being the speed. Furthermore, "--ramp-guess.ramp-length" tells NETCONVERT how long the added ramp shall be in meters.

	Note
	Normally, we keep --ramp-guess.ramp-length unset and let the geometry computation do the rest.

Specific options:

These options may be used in conjunction with all import formats.

Examples: none yet

Most professional networks are not stored using cartesian, but geo-coordinates. Since version 0.9.4 NETCONVERT is able to deal with such positions. NETCONVERT uses herefor the projection library "PROJ.4". This is important for you as a user, because you may have to describe the original projection of your file and when doing this, you have to describe it using the options offered by PROJ.4. In order to enable the reprojection use the option --use-projection. You can then add parameter for the projection using --proj <STRING>. The default for the projection is "+proj=utm +ellps=bessel +units=m". That means, that NETCONVERT assumes the network to be encoded using "universal traverse mercator" and the Bessel ellipsoid what resembles what is known as WGS84 (as far as we have understood it). Please remark, that when giving own description, you should embed it into "" for passing all the arguments to PROJ.4.

Specific options:

These options may be used in conjunction with the following import formats:

	Caution
	This is a new feature. Its usage and the way it works will surely change in the future.

Examples: none yet

Recent changes:

If you already know SUMO or if you have taken a look at some of the examples you may have noticed that vehicles used to "jump" over a junction instead of driving over them. This behaviour was quite appropriate for simulating large scenarios as in these cases the simulation error could be neglected (at least we have neglected it). Since version 0.10.0 SUMO will by default simulate traffic over the junctions in a way you know it from reality. Because inserting inner lanes into a network dramatically increases the network's size, you may want to return to the old behavior using the option --no-internal-links.

	Note
	Please note that you also have to disable the usage of internal lanes within the simulation.

Specific Options:

Examples:

Meanwhile all of the examples included in the distribution have internal lanes.

Recent changes:

NETCONVERT offers you some possibillities to constrain the read edges what is quite needful if one has a large street network but only wants to simulate a part of it or only the major roads. The first possibility to constrain the input is to name all the edges you want to keep. You can either do this on the command line/within your configuration directly using --keep-edges <EDGE_ID>[,<EDGE_ID>]+ where each <EDGE_ID> represents the id of an edge you want to keep or you can save this list into a file where each id is stored in a seperate line and then let NETCONVERT read this file using --keep-edges.input-file <FILENAME>. In the case you are joining edges using --remove-geometry (see "Removing Geometry Nodes"), you may also be interested in the option --keep-edges.postload which forces NETCONVERT to join the edges first and remove the unwished afterwards.

It is also possible to constrain the imported edges by giving a minimum velocity that is allowed on an edge in order to include this edge into the generated network. Use --edges-min-speed <MIN_SPEED> for this where <MIN_SPEED> is the minimum velocity an edge must allow in order to be included in the output in m/s.

Specific options:

Examples: none yet

Recent changes:

NETCONVERT and NETGEN allow to generate additional output files beside writing the network file. We will present the possibilities in the following subchapters.

edge1<TAB>edge1:10<TAB>edge2:20<TAB>edge3:30

edge<TAB>edge:100

You are able to describe how many junctions in x- and in y-direction you want to be build and how far from each other they should be. The parameter for the number of junctions are --grid-x-number and --grid-y-number, the ones for the distance between the junctions --grid-x-length and --grid-y-length. If you want to build networks which have the same values for both axes, use --grid-number and --grid-length. The lengths are given in meters. It is possible to give another option --attach-length, which adds streets of the given length at the boundary of the grid such that all crossings have four streets (It is not yet possible to have different attach lengths for x- and y-direction).

An example usage for building could be:

Figure 4.8. netgen --grid-net --grid-number=10 --grid-length=400 --output-file=MySUMOFile.net.xml

Another one:

Figure 4.9. netgen --grid-net --grid-x-number=20 --grid-y-number=5 --grid-y-length=40 --grid-x-length=200 --output-file=MySUMOFile.net.xml

Spider-net networks are defined by the number of axes dividing them (parameter --spider-arm-number or --arms, default is 13), the number of the circles they are made of (--spider-circle-number or --circles, default is 20) and the distance between the circles (--spider-space-rad or --radius in meters, default is 100).

	Caution
	As the number of edges within the middle of the spider net may be quite large, it is often not possible to build a traffic light junction here. Due to this, this junction is always a right-of-way-junction.

Optionally you can omit the central junction of the network by specifying --spider-omit-center or --nocenter. This also gives an easy way of generating a circle network. Using for instance netgen --spider-net --spider-omit-center --output-file=MySUMOFile.net.xmlwill create a circle consisting of 13 elements with a radius of 100m.

Two examples of usage:

Figure 4.10. netgen --spider-net --spider-arm-number=10 --spider-circle-number=10 --spider-space-rad=100 --output-file=MySUMOFile.net.xml

and:

Figure 4.11. netgen --spider-net --spider-arm-number=4 --spider-circle-number=3 --spider-space-rad=100 --output-file=MySUMOFile.net.xml

The random network generator does just what his name says, it builds random networks... Several settings may be changed:

An example:

Figure 4.12. netgen --random-net -o MySUMOFile.net.xml --rand-iterations=200 --abs-rand