Chapter 5. Route Generation

5.1. Introduction

After having your network converted into the SUMO-format, you could take a look at it using the gui-version of the simulation (see "Simulation-GUI"), but no cars would be driving around. You still need some kind of description about the vehicles. If you are importing data from other simulation packages, they normally bring own route definitions you can use. In case of using ArcView or own data or in other cases where you do not have the vehicle movements at all, you have to generate them by your own. From now on we will use the following nomenclature: A trip is a vehicle movement from one place to another defined by the starting edge (street), the destination edge, and the departure time. A route is an expanded trip, that means, that a route definition contains not only the first and the last edge, but all edges the vehicle will pass. There are several ways to generate routes for SUMO:

  • using trip definitions
    As described above, each trip consists at least of the starting and the ending edge and the departure time (see Chapter "Using Trip Definitions").
  • using flow definitions
    This is mostly the same approach as using trip definitions, but you may join several vehicles having the same trips using this method (see Chapter "Using Flow Definitions").
  • using flow definitions and turning ratios
    You may also leave out the destination edges for flows and use turning ratios at junctions instead (see Chapter "Using the Junction Turning Ratio - Router").
  • using OD-matrices
    OD-matrices have to be converted to trips first (see Chapter "Using OD2TRIPS"), then from trips to routes (see Chapter "Using Trip Definitions").
  • by hand
    You can of course generate route files by hand (see Chapter "Building Routes 'by Hand'").
  • using random routes
    This is fast way to fill the simulation with life, but definitely a very inaccurate one (see Chapter "Generating random Routes").
  • by importing available routes (see Chapter "Importing Routes from other Simulations")

By now, the SUMO-package contains four applications for processing routes. DUAROUTER is responsible for importing routes from other simulation packages and for computing routes using the shortest-path algorithm by Dijkstra. JTRROUTER may be used if you want to model traffic statistically, using flows and turning percentages at junctions. OD2TRIPS helps you to convert OD-matrices (origin/destination-matrices) into trips. A new application, the DFROUTER was added to the suite for version 0.9.5. Within the next chapters, at first the mandatory arguments are described, then we will show how each of the possible methods of generating routes from scratch can be used. In the following, importing routes and additional options are given followed by a small overview.

Figure 5.1. Building routes (!!! Netzwerk fehlt)

Building routes (!!! Netzwerk fehlt)

5.2. Common, mandatory Values

Independent to what you are doing, you always have to supply the network using the --net-file (or --net or -n for short) option when working with either DFROUTER, DUAROUTER, JTRROUTER, or OD2TRIPS. Additionally, you should let the application know which time interval shall be used. Route/trip/flow definitions will be imported within the interval given by the options --begin (-b) and --end (-e). Definitions with departure time earlier than the one specified by --begin or later than those specified by --end will be discarded. If you do not give a value for the begin / end time step the defaults 0 and 86400 (one day) will be used, respectively.

Common options:

( --net-file | --net | -n ) <SUMO_NET_FILE>

The network to route on. Mandatory, type:filename, default: none

( --begin | -b ) <TIME>

Defines the begin time routes shall be generated (in seconds). Default (pregiven), type:int, default: 0

( --end | -e ) <TIME>

Defines the end time routes shall be generated (in seconds). Default (pregiven), type:int, default: 86400

5.3. Building Routes from Scratch

You have either the possibility to generate completely random routes or to exactly describe what you want and pass this information to DUAROUTER or JTRROUTER, which then expand your descriptions to routes. As result, a routes file is normally generated which you may use within your simulation.

[Caution]Caution
You have to know that each route should consist of at least three edges! On the first, the vehicle will be emitted. As soon as it reaches the begin of the last, it will be removed from the network. So to see the vehicle running, you should at least have one edge in between!

5.3.1. Generating own, explicit Routes

There are three possibilities to describe own routes. The most trivial one is to do this by hand. The first way to make more vehicle trips more automatically is the usage of trip definitions, the second one the usage of flow descriptions. Trip definitions describe the movement of a single vehicle giving the departure time, and both the origin and the destination edges via their id. Flow descriptions use these values too, but instead of describing only one vehicle, the description is used for a defined number of vehicles to be emitted within a described interval. Due to this, instead of the departure time, the period's begin and end times must be supplied and the number of vehicles to emit within this interval.

We will describe both data types less briefly, now.

5.3.1.1. Building Routes 'by Hand'

The most simple way to get own routes is to edit a routes file by hand, but only if the number of different routes is not too high. Most of the routes within the examples were written by hand, in fact. Before starting, you must know that a vehicle in SUMO consists of three parts: a vehicle type which describes the vehicle's physical properties, a route the vehicle shall take, and the vehicle itself. Both routes and vehicle types can be shared by several vehicles. In this case, routes need a further information. Assume you want to build a routes file "routes.rou.xml". Herein, you can define a vehicle type as following:

<routes>
   <vtype id="type1" accel="0.8" decel="4.5" sigma="0.5" length="5" maxspeed="70"/>
</routes>

The values used above are the ones most of the examples use. They resemble a standard vehicle as used within the Stefan Krauß' thesis besides that the minimum gap between vehicles is not added to the length!!!. These values have the following meanings:

  • id: A string holding the id of the vehicle type
  • accel: The acceleration ability of vehicles of this type (in m/s^2) !!!
  • decel: The deceleration ability of vehicles of this type (in m/s^2)
  • sigma: The driver imperfection (between 0 and 1)
  • length: The vehicle length (in m)
  • maxspeed: The vehicle's maximum velocity (in m/s)
  • color: An optional color of the vehicle type, encoded as three values between 0 and 1 for red, green, and blue, divided by a ','. Please remark that no spaces between the numbers are allowed.

Having this defined, you can build vehicles of type "type1". Let's do this for a vehicle with an completely own route:

<routes>
   <vtype id="type1" accel="0.8" decel="4.5" sigma="0.5" length="5" maxspeed="70"/>

   <vehicle id="0" type="type1" depart="0" color="1,0,0">
      <route>beg middle end rend</route>
   </vehicle>

</routes>

Ok, now we have a red (color=1,0,0) vehicle of type "type1" named "0" which will start at time 0. The vehicle will drive along the streets "beg", "middle", "end", and as soon as it has approached the edge "rend" it will be removed from the simulation. Ok, let's review a vehicle's attributes:

  • id: A string holding the id of the vehicle
  • type: The vehicle type to use for this vehicle
  • depart: The time at which the vehicle shall be emitted into the net
  • color: An optional color of the vehicle, encoded as three values between 0 and 1 for red, green, and blue, divided by a ','. Please remark that no spaces between the numbers are allowed.

This vehicle has an own, internal route which is not shared with other vehicles. You may also define two vehicles using the same route. In this case you have to "externalize" the route by giving it an id and make SUMO know that it is shared by more than one vehicle using the multi_ref attribute. The vehicles using it refer it using the "route"-attribute. The complete change looks like this:

<routes>
   <vtype id="type1" accel="0.8" decel="4.5" sigma="0.5" length="5" maxspeed="70"/>

   <route id="route0" multi_ref="x" color="1,1,0">beg middle end rend</route>

   <vehicle id="0" type="type1" route="route0" depart="0" color="1,0,0"/>
   <vehicle id="1" type="type1" route="route0" depart="0" color="0,1,0"/>

</routes>

You may have noticed, that the route itself also got a color definition, so the attributes of a route are:

  • id: A string holding the id of the route
  • multi_ref: If set to 'x' or 't' then the route is assumed to be shared by several vehicles and not removed until the simulation has ended
  • color: An optional color of the vehicle, encoded as three values between 0 and 1 for red, green, and blue, divided by a ','. Please remark that no spaces between the numbers are allowed.

This knowledge should enable you to specify own route definitions by hand or using self-written scripts. All routing modules are generating route files that match this routes and vehicles specification.There are a few important things to consider when building your own routes:

  • Routes have to be connected. At the moment the simulation does not raise an error if the next edge of the current route is not a successor of the current edge. The car will simply stop at the end of the current edge and will possibly be "teleported" to the next edge after a waiting time. This is very likely to change in future versions.
  • Routes have to contain at least two edges. The simulation stops the car at the start of the last edge, thus a route consisting of a single edge is empty.
  • The starting edge has to be at least as long as the car starting on it. At the moment cars can only start at a position which makes them fit on the road completely.
  • The route file has to be sorted by starting times. In fact this is only relevant, when you define a lot of routes or have large gaps between departure times. The simulation parameter --route-steps, which defaults to 200, defines the size of the time interval with which the simulation loads its routes. That means by default at startup only route with departure time <200 are loaded, if all the vehicles have departed, the routes up to departure time 400 are loaded etc. pp. This works only if the route file is sorted. This behaviour may be disabled by specifying --route-steps 0.

The first three conditions can be checked using <SUMO_DIST>/tools/routecheck.py.

5.3.1.2. Using Trip Definitions

Trip definitions that can be laid into the network may be supplied to the router using an XML-file. The syntax of a single trip definition is: <tripdef id="<ID>" depart="<TIME>" from="<ORIGIN_EDGE_ID>" to="<DESTINATION_EDGE_ID>" [type="<VEHICLE_TYPE>"] [period="<INT>" repno="<INT>"] [color="<COLOR>"]/>. You have to supply the edge the trip starts at (origin), the edge the trip ends at (destination) and the departure time at least. If the type is not given, a default ("SUMO_DEFAULT_TYPE") will be used and stored within the routes-file. If the attribute period is given, not only one vehicle will use the route, but every n seconds (where n is the number defined in period), a vehicle using this route will be emitted. The number of vehicles to emit using this route may be additionally constrained using repno. Otherwise, it is unlimited. !!! test !!!

Let's review a trip's parameter:

  • id: A string holding the id of the route (and vehicle)
  • depart: The time the route starts at
  • from: The name of the edge the route starts at; the edge must be a part of the used network
  • to: The name of an the edge the route ends at; the edge must be a part of the used network
  • type: The name of the type the vehicle has (optional)
  • period: The time after which another vehicle with the same route shall be emitted (optional)
  • repno: The number of vehicles to emit which share the same route (optional)
  • color: Defines the color of the vehicle and the route (optional)

This file is supplied to DUAROUTER using the option "--trip-defs" or "-t":

duarouter --trip-defs=<TRIP_DEFS> --net=<SUMO_NET> \
   --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

Specific options:

( --trip-defs | --trips | -t ) <TRIP_DEFINITION_FILE>

Tells DUAROUTER from what file trip definitions shall be read. Optional, type:filename, default: none

Examples:

Almost all networks within the <SUMO_DIST>/data/ - folder. Additionally some examples that deal with trips may be found in <SUMO_DIST>/data/examples/router.

  • <SUMO_DIST>/data/examples/router/trips2routes/ shows the basic usage of trips; This example is quiet trivial - 100 same vehicles are emitted
  • <SUMO_DIST>/data/examples/router/trips2routes_repetition/ does exactly the same, but not by defining each of the 100 vehicles, but letting one vehicle be duplicated using period and repno

5.3.1.3. Using Flow Definitions

Flow amounts share most of the parameter with trip definitions. The syntax is: <flow id="<ID>" from="<ORIGIN_EDGE_ID>" to="<DESTINATION_EDGE_ID>" begin="<INTERVAL_BEGIN>" end="<INTERVAL_END>" no="<VEHICLES_TO_EMIT>" [type="<VEHICLE_TYPE>"] [color="<COLOR>"]/>. Notice the following differences: the vehicle does not take a certain departure time as not only one vehicle is described by this parameter, but a set of, given within the attribute "no" (short for number). The departure times are spread uniformly within the time interval described by <INTERVAL_BEGIN> and <INTERVAL_END>. All these three attributes must be integer values. The values "period" and "repno" are not used herein. Flow definitions can also be embedded into an interval tag. In this case one can (but does not have to) leave the tags "begin" and "end" out. So the following two snipples mean the same:

<flow id="0" from="edge0" to="edge1" begin="0" end="3600" no="100"/>

and

<interval begin="0" end="3600">
   <flow id="0" from="edge0" to="edge1" no="100"/>
</interval>

Let's review flow parameter:

  • id: A string holding the id of the flow; vehicles and routes will be named "<id>_<RUNNING>" where <RUNNING> is a number starting at 0 and increased for each vehicle.
  • from: The name of the edge the routes start at; the edge must be a part of the used network
  • to: The name of an the edge the routes end at; the edge must be a part of the used network
  • type: The name of the type the vehicle has
  • begin: The begin time for the described interval
  • end: The end time for the interval; must be greater than <begin>; vehicles will be emitted between <begin> and <end>-1 !!! test!!!!
  • no: The number of vehicles that shall be emitted during this interval
  • color: Defines the color of the vehicles and their routes (optional)

As we have to read in the flow definitions completely into the memory - something we do not have to do necessarily with trips, an extra parameter (-f or --flow-defs) is used to make them known by the router:

duarouter --flow-defs=<FLOW_DEFS> --net=<SUMO_NET> \
   --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

Remind that you can not insert flow descriptions into a trip definitions file. The opposite (some trip definitions within a flow descriptions file) is possible. You also can give both files at the input file, for example:

duarouter --flow-defs=<FLOW_DEFS> --trip-defs=<TRIP_DEFS> --net=<SUMO_NET> \
   --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

Specific options:

( --flow-definition | --flow-defs | --flows | -f ) <FLOW_DEFINITION_FILE>

Tells DUAROUTER/JTRROUTER from what file flow definitions shall be read. Optional, type:filename, default: none

Examples:

  • <SUMO_DIST>/data/examples/router/flows2routes/ shows the basic usage of flows; This example generates 100 vehicles just like <SUMO_DIST>/data/examples/router/flows2routes/ but it uses flow definitions instead of trips for this.
  • <SUMO_DIST>/data/examples/router/flows2routes_100s_interval/ is almost the same, but vehicles are departing over a time of 100s.
  • <SUMO_DIST>/data/examples/router/flows2routes_200s_interval/ is almost the same, but vehicles are departing over a time of 200s.
  • <SUMO_DIST>/data/examples/router/flows2routes_100s_interval_ext/ shows the second possibility of defining intervals in flow-defs.

Recent changes:

  • There was a bug on using flow in prior versions; the end time step was also used making the behaviour not as good predictable. This has been now changed so that the vehicles are emitted in steps starting at <begin> and ending at <end>-1.
    Reason: The prior behaviour was not correct

5.3.2. Generating random Routes

Random routes are the easiest, but also the most inaccurate way to feed your network with vehicle movements. Using the following call ro DUAROUTER:

duarouter --net=<SUMO_NET> -R <FLOAT> --output-file=MySUMORoutes.rou.xml \
   -b <UINT> -e <UINT>

or the same for the JTRROUTER:

jtrrouter --net=<SUMO_NET> -R <FLOAT> --output-file=MySUMORoutes.rou.xml \
   -b <UINT> -e <UINT>

you will generate random routes for the time interval given by -b(egin) and -e(nd). In each time step as many vehicles will be emitted into the network as given by the value of -R (--random-per-second). You can also supply values smaller than one. In this case, a single vehicle will be emitted each 1/<-R> step. Example: -R 0.25 generates a route description, which, when loaded, forces the simulation to emit a single vehicle each fourth time step. It is also possible to use this parameter in combination with other route definitions, for example supplying some fix routes and additionally generate random routes.

Random routes are not the best way to generate routes. Take a look at the network displayed below. This network has two rural and many minor roads. Random routes are by now spread all over the network and each road is chosen to be the starting or the ending without respecting his function. Due to this, the network is filled over with cars, coming from and approaching directions, the normal traffic is not taking - the normal traffic would concentrate on rural roads.

Figure 5.2. A network where the usage of random routes causes an improper behaviour due to the mixture of rural and minor roads

A network where the usage of random routes causes an improper behaviour due to the mixture of rural and minor roads

There is also another problem with random routes: Often, the route starts in the opposite direction of the destination - on the wrong side of the road. This yields in a large amount of vehicles that want to turn back using the first possibility. This is of course also not common in the real world, especially not in areas as the one shown above. To avoid this, we remove the first and the last edge from the route per default when generating random routes. !!! revalidate this!!!

Options:

( --random-per-second | -R ) <RANDOM_VEHICLES_PER_SECOND>

Forces DUAROUTER/JTRROUTER to generate random trips. Per second the given number of vehicles will be generated. Optional, type:float, default: none

5.3.3. Using the Junction Turning Ratio - Router

The JTRROUTER is a routing applications which uses flows and turning percentages at junctions as input. The following parameter must be supplied: the network to route the vehicles through, the description of the turning ratios for the junctions (defaults may be used for this, too), and the descriptions of the flows.

A call may look like this:

jtrrouter --flow-defs=<FLOW_DEFS> --turns=<TURN_DEFINITIONS> --net=<SUMO_NET> \
   --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

The definitions of the flow look like the ones for the DUAROUTER with just a single difference: as it is not known where the vehicle will leave the network as the route it uses is randomly computed, the destination parameter has no meaning for jtr-routing and so may be left off. A vehicle leaves the network as soon as it comes to a sink edge. As not all networks have sink edges set, one can support a list of edges to be declared as sinks using --sinks <EDGE_ID>[;<EDGE_ID>]*.

To describe the turn definitions, one has to build a further file. Within this file, for each interval and each edge the list of percentages to use a certain follower is to be given. An example:

<turn-defs>
   <interval begin="0" end="3600">
      <fromedge id="myEdge0">
         <toedge id="myEdge1" probability="0.2"/>
         <toedge id="myEdge2" probability="0.7"/>
         <toedge id="myEdge3" probability="0.1"/>
      </fromedge>

      ... any other edges ...

   </interval>

   ... some further intervals ...

</turn-defs>

The snippet defines that vehicles coming at the end of edge "myEdge0" within the time interval between 0s and 3600s will choose the edge "myEdge1" with a probability of 20%, "myEdge2" with a probability of 70% and "myEdge3" with a probability of 10%. The specification of such information is of course quite extensive and so the JTRROUTER is also able to read the turning ratios from a cvs file. The same information as above may be coded the following way:

begin;end;from;to;split
0;3600;myEdge0;myEdge1;0.2
0;3600;myEdge0;myEdge2;0.7
0;3600;myEdge0;myEdge3;0.1
[Caution]Caution
Do not forget to give the order of the attributes in the first line of the file.

Another possibility to save time on preparing the description is to use default values. The parameter --turn-defaults (-T) <TURN_DEFAULTS> can be used to describe the default ratios that will be used for all junctions for all time steps. <TURN_DEFAULTS> is a list of doubles, separated by a ';'. To achieve the same behaviour as in the example above, use --turn-defaults=20;70;10. The values will be applied to an edge's following edges beginning at the right edge (20%) and ending at the leftmost edge (10%). As the number of possible followers changes for different edges, the values are resampled for edges which number of following edges differs from the number of given turning probability defaults. Given --turn-defaults=20;70;10 a vehicle using an edge that has two followers would use the follower to the right with 55% probability, the one to the left with 45%.

As theoretically a route may get infinitely long when a vehicle is forced to take always the same direction, it is possible to limit the route's size using max-edges-factor. This factor, multiplied with the number of the used network's edges is the maximum number of edges a route may have. With the default of 2.0, a route may contain twice as many edges as the network has. Any route longer than this size will be marked as invalid. We assume that for each network this number has to be chosen again.

The following options are accepted by JTRROUTER:

( --net-file | --net | -n ) <SUMO_NET>

Uses the named network to route vehicles on. Mandatory, type:filename, default: none

( --output-file | --output | -o ) <FILENAME>

Set <FILENAME> as the filename to write computed routes into. Additionally a file named "<FILENAME>.alt" will be generated which contains the route alternatives. Mandatory, type: filename, default: none

(--begin | -b ) <INT>

The first time step for which routes shall be build. Optional (pregiven), type: int, default: 0

(--end | -e ) <INT>

The last time step (+1) for which routes shall be build. Optional (pregiven), type: int, default: 86400

( --alternatives | -a ) <ALTERNATIVES_FILE>

Forces JTRROUTER to use the previously generated <ALTERNATIVES_FILE> as input. Optional, type:filename, default: none

Recent changes:

  • The attribute "probability" within turn definitions was named "perc" in versions lower than 0.9.4 The reason for this change is that "probability" is more common throughout the package and the values had to be in the range between 0 and 1, what is no percentage information at all.

Examples:

Several examples may be found in <SUMO_DIST>/data/examples/jtrrouter/.

5.3.4. Using OD2TRIPS

OD2TRIPS computes trips tables from O/D (origin/destination) matrices. OD2TRIPS assumes the matrix/matrices to be coded as amounts of vehicles that drive from one district to another within a certain time period. Because the generated trips must start and end at edges, OD2TRIPS requires a mapping of districts to edges. During conversion of VISUM networks - the base of the OD2TRIPS development - districts stored in the VISUM input file are parsed and stored within the outputted SUMO network file. If you do not use VISUM as input, you must build a districts file by your own. The format is given in "Describing the Districts", one of the next subchapters. You have to pass the file containing the district definitions to OD2TRIPS using the --net-file (--net or -n for short) option.

Because OD2TRIPS was used only to import data stored in VISUM/VISION formats, it assumes O/D to be stored in one of the VISUM formats. Not all VISUM formats are supported, by now only two, namely the "VMR" and the "OR" format. If you do not own matrices stored in these formats, you still have three possibilities: a) convert them into one of the supported formats, b) write your own reader for OD2TRIPS, or c) convert them into flow definitions and then give them to DUAROUTER (see Chapter "Using Flow Definitions"). Both supported formats are described in "Describing the Matrix Cells", one of the next subchapters. You may either give a list of matrices to OD2TRIPS using the --od-files (--od or -d for short) option followed by the list of files separated using a ';', or - when importing routes from a Vissim simulation - using --vissim <VISSIM_SIMULATION_FILE> to read the matrices referred in this simulation file.

OD2TRIPS reads all matrices and generates trip definitions as described in "Using Trip Definitions". The generated trip definitions are numbered starting at zero. You can also add a prefix to the generated trip definition names using --prefix <STRING>. As usual, they are written to the output file named using the --output-file option (--output or -o for short). OD2TRIPS colors the trip definitions. To remove this feature, use --no-color. You can specify a vehicle type to be added to the trip definitions using --vtype followed by the type name. Please remark that vehicles will have no type unless not given in the O/D-matrices or defined using this option. This option overrides type names given in the O/D-matrices. The type itself will not be generated. Vehicles will be generated for the time period between --begin (-b) and --end (-e), having 0 and 86400 as default values, respectively. The meaning is the simulation step in seconds, as usual.

Because each O/D-matrix cell describes the amount of vehicles to emit within a certain time period, OD2TRIPS has to compute the vehicle's explicite departure times. Normally, this is done by using a random time within the time interval the O/D-matrix cell is defined for. It still is possible to emit a cell's vehicles with an uniform time between their emissions. Use the option --spread.uniform to enable this.

You can scale the amounts stored in the O/D-matrices using the --scale option which assumes a float as parameter. All read flows will be multiplied with this values, the default is 1. When importing O/D-matrices that cover a whole day, you maybe want to apply a curve which resembles the spread of the trip begins found in reality. Please read the subchapter "Splitting large matrices" on this.

Figure 5.3. Building trips from the OD-matrix

Building trips from the OD-matrix

Specific options:

( --net-file | --net | -n ) <DISTRICT_MAP>

Tells OD2TRIPS to use the districts stored in <DISTRICT_MAP>. Mandatory, type:filename, default: none

( --od-files | --od | -d ) <OD_FILE>[;<OD_FILE>]*

Tells OD2TRIPS to use the given O/D matrices. Optional, type:(list of) filename(s), default: none

--vissim <VISSIM_SIMULATION_FILE>

Forces OD2TRIPS to read the list of matrices to process from the given Vissim file. Optional, type: filename, default: none

( --output-file | --output | -o ) <FILENAME>

Forces OD2TRIPS to write the generated vehicle trip definitions into <FILENAME>. Mandatory, type: filename, default: none

(--begin | -b ) <INT>

The first time step for which trip definitions shall be build. Optional (pregiven), type: int, default: 0

(--end | -e ) <INT>

The last time step (+1) for which trip definitions shall be build. Optional (pregiven), type: int, default: 86400

( --scale | -s ) <FLOAT>

A value with which read flow amount are multiplied. Optional (pregiven), type: float, default: 1

--no-color

Disables trip coloring. Optional (pre-given), type: bool, default: false

--vtype <VEHICLE_TYPE_NAME>

Adds a vehicle type to the trip definitions. Optional, type: string, default: none

--prefix <VEHICLE_NAME_PREFIX>

Adds a prefix to the vehicle names. Optional, type: string, default: none

--spread.uniform

Forces OD2TRIPS to spread the vehicle departure time uniformly for each cell. Optional (pregiven), type: bool, default: false

--timeline.day-in-hours

Says OD2TRIPS that the timeline is a list of amount per hour. Optional (pregiven), type: bool, default: false

--timeline <TIMELINE_DEFINITION>

If --timeline.day-in-hours is set, the string should contain 24 floating point values, divided by ';', each describing the probability with which a vehicle is emitted into the network during the according hour. Otherwise, the string should contain a list of time/probability pairs, divided by ';', each describing the begin time and the probability for the interval defined by this and the next entry. Time and probability are divided by ','. Optional, type: string, default: none

Examples: None yet.

Recent changes:

  • The whole application was rewritten for the 0.9.5. version. Most things still should work as well with older versions, but the options --vtype, --prefix, --timeline, and --timeline.day-in-hours were not available.
  • The usage of --od-files and --vissim differs from prior versions.
  • --od-files was named --od-file in versions prior to 0.9.5.

5.3.4.1. Describing the Districts

OD2TRIPS assumes the matrix/matrices to be coded as amount of vehicles that drive from one district to another within a certain time period. Because the generated trips must start and end at edges, OD2TRIPS requires a mapping of districts to edges. During conversion of VISUM networks which conversion was the base of the OD2TRIPS development, districts stored in the VISUM input file are parsed and stored within the network file. If you have to generate districts by your own, you must build a districts file by your own. Such a file looks as following:

<districts>
   <district id="<DISTRICT_ID>">
      <dsource id="<EDGE_ID>" weight="<PROBABILITY_TO_USE>"/>
      ... further source edges ...

      <dsink id="<EDGE_ID>" weight="<PROBABILITY_TO_USE>"/>
      ... further destination edges ...
   </district>

   ... further districts ...

</districts>

This means that a district is described by its id, being a simple name, and lists of source and destination edges. A district should have at least one source and one destination edge each described by its id and use probability called weight herein. These edges are used to emit and remove vehicles into/from the network respectively. The probability sums of each the source and the destination lists are normalized after loading.

5.3.4.2. Describing the Matrix Cells

To understand how an O/D-matrix is stored, we should remind the meanings of the values stored herein. Each matrix describes a certain time period. The indices within the matrix are names of the origin/destination districts (normally they are equivalent, both lists are the same). The values stored within the matrix are amounts of vehicles driving from the according origin district to the according destination district within the described time period.

The formats used by ptv are described in the VISUM-documentation more detailed. All start with a line where the type of the O/D-matrix is given, appended to a '$'. The first following character tells in which format the table is stored. Then, further characters follow which describe which values are supplied additionally within the matrix. For further information we ask you to consult the documentation supported by ptv. Herein, only the supported variants are described.

The V-format stores the O/D matrix by giving the number of districts first and then naming them. After this, for each of the named districts, a list of vehicle amounts that leave this district is given, sorted by the destination district names as given in the district name list. An example may look like this:

$VMR
* vehicle type
4
* From-Time  To-Time
7.00 8.00
* Factor
1.00
*
* some
* additional
* comments
* District number
3
* names:
         1          2          3
*
* District 1 Sum = 6
         1          2          3
* District 1 Sum = 15
         4          5          6
* District 1 Sum = 24
         7          8          9 

The 'M' in the type name indicates that a vehicle type is used, the "R" that the values shall be rounded randomly. The second information is not processed by OD2TRIPS what means that you can parse both V-, VR-, VMR, and VM-matrices. Please remark that both the names list and the lists containing the amounts are written in a way that no more than 10 fields are stored in the same line. Each of the entries they contain seems to be left-alogned to a boundary of 11 characters (possibly 10 for the name and one space character). Both constraints are not mandatory for the importer used in OD2TRIPS.

The O-format instead simply lists each origin and each destination together with the amount in one line (please remark that we currently ignore the string after the ';' that occures after the type identifier "$OR" in the first line):

$OR;D2
* From-Time  To-Time
7.00 8.00
* Factor
1.00
* some
* additional
* comments
         1          1       1.00
         1          2       2.00
         1          3       3.00
         2          1       4.00
         2          2       5.00
         2          3       6.00
         3          1       7.00
         3          2       8.00
         3          3       9.00

5.3.4.3. Splitting large matrices

Since version 0.9.5 OD2TRIPS allows splitting matrices defining a long tie period into parts that dure less long. There are two ways of defining the amounts the matrix shall be split into. The first possibility is to use the option --timeline directly. In this case, it should be followed by a list of times and probabilities, separated by ';'. Each time and probability field is made up of two values, an integer time being the simulation time in seconds and a floating point number describing the probability. These two values are separated using a ','. At least two values must be supplied making the definition of a timeline in this case being decribeable by the following BNF-formula:

<TIME>,<AMOUNT>[;<TIME>,<AMOUNT>]+

In this case, the matrix will be split into (fields-1) parts and each part will have the amount described by the integral within the field.

The second case is rather common in transportation science. It allows to split the matrix into 24 subparts - this means the number of dields is fixed to 24 - allowing to spread an O/D-matrix over a day describing it by hours. To use this, give additionally the option --timeline.day-in-hours to OD2TRIPS. It the assumes the values from the --timeline - option being a list of 24 floats, divided by ';', each describing the probability of emitting a vehicle within the according hour.

In both cases, the probabilities are automatically normed.

5.4. Importing Routes from other Simulations

5.4.1. Importing Artemis-routes

Although originally ARTEMIS-routes are stored within an OD-matrix, the import within SUMO is done using the DUAROUTER program.

This is basically done this way:

duarouter --artemis=<ARTEMIS_FOLDER> --net=<SUMO_NET> \
  --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

Remind that you have to specify the begin and the end of the simulation. This is quite inconsequent, as our mechanisms would allow import of repeatable routes, too. This is just not yet implemented.

Known problems:

  • Only the a0-Flow is being imported
  • Only one time-period is imported

5.4.2. Importing FastLane-routes

One of the main concepts of FastLane is the Dynamic User Assignment by Christian Gawron. As this mechanism is based on single vehicle routes, those are given for a FastLane simulation. The router module has only to convert routes from the FastLane- into the SUMO-representation. Do this using the following command:

duarouter --cell=<CELL_FILE_NAME(NO_EXTENSION)> --net=<SUMO_NET> \
   --output-file=MySUMORoutes.rou.xml -b <UINT> -e <UINT>

If you are familiar with FastLane, you may have noticed that you have only to supply one file name while FastLane uses two files to describe the routes: one "*.driver" and one "*.rinfo" file. As both files have the same name and only the extension differs, you have to give the name without the extension. So if your files have the names "foo.driver" and "foo.rinfo", write --cell=foo.

FastLane stores routes within a very large file what makes the process quite slow. If you want to speed it up for the future, you can tell SUMO-ROUTER to save some temporary files using --save-cell-rindex. A further file named "<CELL_FILE_NAME>.rindex" will be generated. It speeds up the processing by a factor of ten or so.

As FastLane is portable, you may encounter files generated on a Windows-machine. Those files give some strange warnings, something that should not happen if you supply the right net. To avoid them, use the --intel-cell switch to tell DUAROUTER it has to turn the byte order.

You can also decide whether the best, not the last route a driver took shall be used: set the switch --no-last-cell for this.

5.4.3. Importing VISSIM und VISUM-routes

See "Using OD2TRIPS" for information about how to import O/D-matrices in ptv format.

5.5. Dynamic User Assignment and Alternative Routes

!!! Weights fehlen!!!

Dynamic Assignment is used to find out which routes the simulated driver really would take. One could assume that everyone is traing to use the fastest route. But what is the fastest route? Look at the network shown in the next picture. It is abvious, that the fastest route is the one in the middle of the network, even when considering the tls at the end of this road. But as soon as we insert many vehicles into the network, all trying to use this route, the edge located at the center soon gets full and vehicles need much more time than estimated to pass it. In fact, they need longer to pass this edge than if they would try to use one of the outer connections.

Figure 5.4. Example DUA-network (from "<SUMO_DIST>/data/examples/dua/dua3s*")

Example DUA-network (from "<SUMO_DIST>/data/examples/dua/dua3s*")

Within Christian Gawron's approach (see [Gawron1998_1]), which we use, each driver has a list of routes. At the beginning, we build a single route for each driver being the shortest route within an empty network - not knowing how many vehicles will use this route. You may wonder that two files are built. The file you have named as output file and a further file having the additional extension ".alt". Within this second file route alternatives - the set of all routes the driver knows - are stored.

After having generated the routes, we let the simulation run forcing it to generate edge-based dumps (see chapter 6, "Aggregated Lane/Edge States (Edge/Lane-Dumps)"). The router is In fact, edge-based dumps are the better choice, because the route is not able to use lane-based dumps at all. Now, we have the information about the state of the network, meaning the real speeds that were driven within it, when all vehicles are using the same route. Now we can pass this information to a second call to DUAROUTER and now - instead of the previous input file - we give the route alternatives file as input using the option --alternatives (or -a for short). Now, DUAROUTER is capable to compute the new shortest routes, based on the real speeds within our simulation. In order to avoid that again all vehicles will use the currently shortest route only some of the drivers will get the new shortest route. Again, two files are generated, a route file which contains the current routes and a new route alternatives file. The entries within the new alternatives file stay the same for all those drivers who keep their old route. Those who got a new route assigned, will get this route stored additionally to their previous route within the file. Whether a route is replaced by a new, better route is depending on how much better the new route is and how fast a driver shall forget his old one. There are two parameters determining this: --gBeta and --gA. Please see (see [Gawron1998_1]) for further information.

Figure 5.5. Sketch showing the effects of Christian Gawron dua-approach on route distribution within the network; blue color indicates that an edge is used within the step, red shows jams

Sketch showing the effects of Christian Gawron dua-approach on route distribution within the network; blue color indicates that an edge is used within the step, red shows jams

Still, as the picture above shows, there may be other faster routes when again running the simulation, so in order to get a balanced assignment, you have to iterate this process several time.

Here, you may again find the procedure to generate a dynamic user assignment:

  1. Generate the network (see chapter 4)

  2. Import your routes (see chapter 5, "Building own Routes from Scratch" or "Importing Routes from other Simulations"), generating a routes file and an alternatives file

  3. Simulate using the network and the routes (see chapter 6) forcing SUMO to write edge-based dumps (see chapter 6, "Aggregated Lane/Edge States (Edge/Lane-Dumps)")

  4. Compute new routes and alternatives using the previously generated alternatives and the edge-based dumps generated within the last step

  5. Continue with step 3 until the DUA is completed

How do we know when the dua is completed? In fact. we don't know any possibility to determine this, yet. Within very large networks we are running mostly about 20 iterations, but this is just a hint. One may say, that the dua is finished if there is no further change in the aggregated vehicles trip duration. DUA is definitely still a research topic. If you are interested in more details than you maybe should take a look at "More On... Dynamic User Assignment".

Specific options:

( --alternatives | -a ) <ALTERNATIVES_FILE>

Forces DUAROUTER to use the previously generated <ALTERNATIVES_FILE> as input. Optional, type:filename, default: none

--gBeta <FLOAT>

Defines Christian Gawron's beta. Optional (pregiven), type:float, default: 0.3

--gA <FLOAT>

Defines Christian Gawron's alpha. Optional (pregiven), type:float, defaults: 0.05

Examples:

  • <SUMO_DIST>/data/examples/dua/due2s_singlestep/ contains configuration files for the first three steps of a dynamic user assignment in a network with two possible ways.
  • <SUMO_DIST>/data/examples/dua/due2s_automatic/ uses the same input as <SUMO_DIST>/data/examples/dua/due2s_singlestep/, but the iterations are done using a script.
  • <SUMO_DIST>/data/examples/dua/due3s_singlestep/ contains configuration files for the first three steps of a dynamic user assignment in a network with three possible ways.
  • <SUMO_DIST>/data/examples/dua/due3s_automatic/ uses the same input as <SUMO_DIST>/data/examples/dua/due3s_singlestep/, but the iterations are done using a script.

5.5.1. Automatic Iteration using 'dua-iterate.pl'

"dua-iterate.pl" helps you to perform the computation of a dynamic user assignment. The script needs at least two parameter: the path to the folder where your SUMO-binaries are located and the number of iteration steps to perform. When started with these two options, the script computes the given number of dua-steps. As input two files have to be located in the same folder as the script: a SUMO-network named "net.net.xml" and a set of trip definitions named "trips.trips.xml". if you want to start with another routes definition, you have to change this within the script's source code.

Within each iteration step, the script generates a configuration file for the DUAROUTER and starts DUAROUTER with this configuration file. Then, a configuration file for SUMO is built and SUMO ist started. Both configuration files are competely defined within the script itself. As default, for each time step, SUMO will generate three dump files with edge-dumps aggregated over 150, 300, and 900s, an emissions and a trip information output. The names of these outputs are numbered over the iteration steps. If you want to change the outputs, you also have to take a look into the script, but you should not disable the edge-based dump for aggregation over 900s, because this is read by the DUAROUTER in the next iteration steps in order to compute the DUA.

When started with a third parameter, the second parameter given will be interpreted as the start iteration step and the third as the end iteration step.

This useful script is located in <SUMO_DIST>/tools/dua_tools/.

Synopsis:

dua-iterate.pl <PATH_TO_SUMO_BINARIES> [[<BEGIN_ITERATION_STEP>]] <END_ITERATION_STEP>

5.5.1.1. Tracking the progress online using "printProgress.pl"

printProgress.pl is a small script which, started in the folder the dua-iterate.pl - iteration takes place - shows how many vehicles were running at the end of the simulation. This helps to see how good the current assignment is (see also "More On... Dynamic User Assignment").

This script is located in <SUMO_DIST>/tools/dua_tools/.

Synopsis:

printProgress.pl

Recent changes:

  • printProgress.pl is a part of the distribution since version 0.9.6.

5.6. Additional Weights

From version 0.8.0.1 on, SUMO is capable to load additional weights for edges. The idea behind this is to virtually increase the costs for an edge in order to make it less attractive to pass. Additional weights are used by DUAROUTER only and are supplied using the --supplementary-weights <FILE> (or --add <FILE> or -S <FILE>) - option. A file containing additional weights looks like this:

<supplementary-weights>
   <interval begin="60" end="119">
      <edge id="1fi" absolute="42" factor="2.5" summand="-21"/>
      <edge id="2o" factor="13"/>

      ... further weights ...

   </interval>
   <interval begin="120" end="179">
      <edge id="1fi" absolute="48" factor="2.5"/>
      <edge id="2o" summand="7"/>

      ... further weights ...

   </interval>

   ... further intervals ...

</supplementary-weights>

When additional weights are supplied, the DUA-Router first looks whether an additional, absolute value has been provide for the currently watched edge (value of the "absolute"-attribute for the current edge and time). If so, this value will be used. If not, either the edge's loaded weight (if available for the current time step) or the default value (length/vallowed) will be changed first by applying the loaded factor (value of the "factor"-attribute for the current edge and time) and than by the loaded addend (value of the "summand"-attribute for the current edge and time).

You can also use GUISIM to generate an additional weights file using the interface which appears when choosing "Edit->Edit Additional Weights...".

Recent Changes:

  • The format has changed in version 0.9.6

5.7. Using Detectors and DFROUTER

Since version 0.9.5, the SUMO-package contains a further routing module named DFROUTER. The idea behind this router is that nowadays, most highways are well equipped with induct loops, measuring each of the highways' entering and leaving flows. Given this information one may assume that the flows on the highway are completely known. DFROUTER uses directly the information collected from induct loops to rebuild the vehicle amounts and routes. This is done in several steps, being mainly:

  1. Computing (and optionally saving) the detector types in the means that each induction is set to be a source detector, a sink detector or an in-between detector

  2. Computing (and optionally saving) the routes between the detectors

  3. Computing the flow amounts between the detectors

  4. Saving the flow amounts and further control structures

In the following we will describe the steps more deeply, giving the command line options that steer the process.

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

Examples: none yet

5.7.1. Computing Detector Types

The idea behind the DFROUTER assumes that a network is completely covered by detectors, meaning that all off- and on-ramps have an induction loop placed on them. Such an information whether an induction loop is a pure source or sink or whether it is placed between such is but not given initially. It must be computed. To do this, the DFROUTER needs the underlying network as well as a list of detector definitions where each describes the position of an induction loop. The network, being a previously build SUMO-network, is supplied to the DFROUTER as usually using the ( --net-file | --net | -n ) <SUMO_NET_FILE> - option, the list of induction loops using --detector-files (or --detectors or -d for short) <DETECTOR_FILE>[;<DETECTOR_FILE>]+. A detector file should look as following:

<detectors>
   <detector_definition id="<DETECTOR_ID>" lane="<LANE_ID>" pos="<POS>"/>
... further detectors ...
</detectors>

This means that each detector is initially described using its id, a lane it is placed on, and a position on the lane. To be exact:

  • id: A string holding the id of the detector
  • lane: The id of the lane the detector lies on. Must be a lane within the network.
  • pos: The position on the lane the detector shall be laid on in meters. The position must be a value between -1*lane's length and the lane's length. In the case of a negative value, the position will be computed backward from the lane's end (the position the vehicles drive towards).

Given a network and the list of detectors, DFROUTER assigns types to detectors (TBD: add a reference) and saves the so extended list into a file if the option --detectors-output <DETECTOR_OUTPUT_FILE> is given. This list looks like the input described above except that an aditional attribute is given for each detector, "type", which may have one of the following values: "source", "sink", "between", and "discarded". You can also generate a list of points of interests (POIs) which can be read by GUISIM where each POI represents a detector and is colored by the detector type: green for source detectors, red for sink detectors, blue for in-between detectors, and black for discarded detectors. To force DFROUTER to do this, use --detectors-poi-output <POI_FILENAME>.

When wished, if for example other parameters chage, the extended <DETECTOR_OUTPUT_FILE> can be fed back again into DFROUTER instead of the previous <DETECTOR_FILE>. In this case the detector types do not have to be computed again. To force DFROUTER to recompute the types though, use --revalidate-detectors.

Specific options:

( --detector-files | --detectors | -d ) <DETECTOR_FILE>[;<DETECTOR_FILE>]+

The list of descriptions of detectors to use. Mandatory, type:filename, default: none

--detectors-output <DETECTOR_OUTPUT_FILE>

The file to write extended detector descriptions into. Optional, type:filename, default: none

--detectors-poi-output <POI_FILENAME>

Writes a list of points of interest into <> where each poi represents a detector and is colored by the detector type. Optional, type:filename, default: none

--revalidate-detectors

Forces DFROUTER to recompute the detector types even if they were given in <DETECTOR_FILE>. Optional (pregiven), type:bool, default: false

5.7.2. Computing Routes

Now that we do know where vehicles enter and where they leave the network, we may compute routes for each of the pairs. The DFROUTER is told to build and save routes using --routes-output <ROUTE_OUTPUT_FILE> where <ROUTE_OUTPUT_FILE> is the name of the file the computed routes shall be written to. The generated file only contains routes, no vehicle type definitions and no vehicles. In later runs, you can omit the routes computation by supplying previously generated routes using --routes-input (or -r) <ROUTE_FILE>. Again, as during the computation of the detector types, you can force DFROUTER to recompute the routes even if suppling them using --revalidate-routes.

Normally, only routes starting at source detectors and ending at sink detectors are computed. Using the option --routes-for-all you can force DFROUTER to also build routes that start at in-between detectors. The option --all-end-follower will make the routes not end at the edge the source detector is placed on, but on all edges that follow this edge (TBD: recheck this). --keep-unfound-ends will also keep those routes where a sink detector could not be found for what may be the case if the network is not completely covered with induction loops.

Specific options:

--routes-output <ROUTE_OUTPUT_FILE>

Names the file to save computed routes into. Optional, type:filename, default: none

( --routes-input | -r) <ROUTE_FILE>

Uses routes from <ROUTE_FILE>. Omits route computation unless --revalidate-routes is set. Optional, type:filename, default: none

--revalidate-routes

Forces DFROUTER to recompute routes even if some where supplied. Optional (pregiven), type:bool, default: false

--routes-for-all

Forces DFROUTER also to save routes starting at in-between detectors. Optional (pregiven), type:bool, default: false

--all-end-follower

Forces DFROUTER to end the routes at edges beyond the sink detectors. Optional (pregiven), type:bool, default: false

--keep-unfound-ends

Forces DFROUTER to keep routes which last detector was an in-between detector. Optional (pregiven), type:bool, default: false

5.7.3. Computing Flows

The next step is to use the computed routes and flow amounts from the real-world detectors to compute flows across the modelled network. The flows are given to DFROUTER using --detector-flow-files (or --detflows, -f for short) <DETECTOR_FLOWS>[;<DETECTOR_FLOWS>]+. They are assumed to be stored in CSV-format using ';' as dividing character. The file should look as following:

Detector;Time;qPKW;qLKW;vPKW;vLKW
myDet1;0;10;2;100;80
... further entries ...

This means the first time has to name the entries (columns). Their order is not of importance, but at least the following columns must be included:

  • Detector: A string holding the id of the detector this line describes; should be one of the ids used in <DETECTOR_FILE>
  • Time: The time period begin this entry describes
  • qPKW: The number of passenger cars that drove over the detector within this time period
  • qLKW: The number of transport vehicles that drove over the detector within this time period
  • vPKW: The average speed of passenger cars that drove over the detector within this time period in km/h
  • vLKW: The average speed of transport vehicles that drove over the detector within this time period in km/h

These are not quite the values to be found in induction loop output. We had to constrain the <DETECTOR_FLOWS> files this way because DFROUTER is meant to read very many of such definitions and to do this as fast as possible. Because even this scheme was too slow for some purposes, flow amounts can also be marked as more valid using the option --fast-flows. If set, DFROUTER assumes that there is no header line and that the values are separated using spaces. In this case, the columns must be in the order time, detector name, qPKW, qLKW, vPKW, and vLKW.

Because in some cases one reads detector flow definitions starting at a certain time but wants his simulation begin at another, it is possible to add a time offset using --time-offset <TIME_OFFSET> which is subtracted from the read times. <TIME_OFFSET> is meant to be an int representing seconds.

(TBD: verify: how long is the time period, are speeds given in m/s, is qPKW/qLKW right, does qPKW/qLKW describe the amount within this period or within one hour)

Specific options:

( --detector-flow-files | --detflows | -f) <DETECTOR_FLOWS>[;<DETECTOR_FLOWS>]+

Describes the files to read detector flows from. Optional, type:filename, default: none

--fast-flows

Says that the flows are stored in a more constrained, faster to read format Optional (pregiven), type:bool, default: false

--time-offset <TIME_OFFSET>

Gives a time offset to be subtracted from the times read from detector flows. Optional (pregiven), type:int, default: 0

Recent changes

  • Changes in version 0.9.6
    • vPKW and vLKW should now be supplied in km/h, not in m/s

5.7.4. Saving Flows and other Values

If flow definitions were supplied, we can let the DFROUTER save the computed vehicles together with their routes. Because vehicles will be emitted at the source detectors which are placed at certain positions of the networks' lanes, emitters (see "Emitter") are used to insert those vehicles into the network. You can force the DFROUTER to generate such emitters using --emitters-output <EMITTER_OUTPUT_FILE>. This file will contain emitter declarations for each of the source detectors. If no value is given, emitters will not be written. Accompanying, there will be emitter definitions written named "emitter_<DETECTOR_ID>.def.xml" where <DETECTOR_ID> is the id of the according source detector. These definitions are called within the <EMITTER_OUTPUT_FILE> and contain vehicles which depart the emitter in accordance to the read flows and have routes computed using the flows.

As some approaches use a speed limit to avoid open-end boundary problems (TBD add a reference), the DFROUTER can generate a list of speed triggers (see "Variable Speed Signs (VSS)") placed on the positions of sink detectors. The name to save the declaration of these speed triggers into is given using the option --speed-trigger-output <VSS_OUTPUT_FILE>. The according speed trigger definitions will be written into files named "vss_<DETECTOR_ID>.def.xml" where <DETECTOR_ID> is the name of the according sink detector.

In order not to end vehicle routes on off-ramps, it is possible to place rerouters (see "Rerouter") at the positions of the sink detectors, too. Giving the option --end-reroute-output <REROUTER_OUTPUT_FILE> will generate a list of rerouter declarations. Please remark that in this case, no rerouter definitions are written, because the DFROUTER has no further information about possible routes beyond the area covered by the detectors.

It's quite nice to have the possibility to check whether the simulation does what one wants. To validate whether the same flows are found within the simulation as within the reality, the option --validation-output <SUMO_DETECTORS_OUTPUT> may be helpful. It generates a list of detector definitions (E1/induct loops, see "E1-Detectors (Induct Loops)") placed at the positions of sink and in-between detectors. Their output will be saved into files named "validation_det_<DETECTOR_ID>.xml" and should be easily comparable to the detector flows previously fed to the router. The option --validation-output.add-sources will let DFROUTER also build E1-detectors for source detectors which are place 1m behind the real-life detector's position.

(TBD: check whether everything is placed into the proper directory; check what's about PKWs/LKWs)

--emitters-output <EMITTER_OUTPUT_FILE>

Forces DFROUTER to write emitter declarations for source detectors into <EMITTER_OUTPUT_FILE>. Additionally, emitter definitions are written. Optional, type:filename, default: none

--speed-trigger-output <VSS_OUTPUT_FILE>

Forces DFROUTER to write speed trigger declarations for sink detectors into <VSS_OUTPUT_FILE>. Additionally, speed trigger definitions are written. Optional, type:filename, default: none

--end-reroute-output <REROUTER_OUTPUT_FILE>

Forces DFROUTER to write rerouter declarations for sink detectors into <REROUTER_OUTPUT_FILE>. Optional, type:filename, default: none

--validation-output <SUMO_DETECTORS_OUTPUT>

Forces DFROUTER to write validation detector definitions for sink and in-betweed detectors into <SUMO_DETECTORS_OUTPUT>. Optional, type:filename, default: none

--validation-output.add-sources

Forces DFROUTER to include source detectors in the validation detector output. Optional (pregiven), type:bool, default: false

5.8. Closing Thoughts (so far)

If you are want to simulate small scenarios only, with a few vehicles, you probably should try to work with routes where each vehicle is duplicated. This needs only a small amount of editing and lets you fill the simulation fast. This has been done for most of the examples within the example data. Trying to generate own OD-matrices is not to be adviced, because handling of such is not really well supported by the package. Using flows generated by hand may be a possibility, but for small scenarios, flows seem more clumsy than routes.

In some cases, flows at each junction are counted and how many vehicles are driving in which direction. This is exactly what JTRROUTER resembles.

5.9. Recent Changes

The following list contains recent changes in the naming or meaning of options. It has been started during the work on version 0.9.2, so earlier changes are not contained, herein. The changes list contains the version where the change occured or will occure. The changes should be valid for the next stable release.

  • Changes in version 0.9.3
    • There was a bug on using flow in prior versions; the end time step was also used making the behaviour not as good predictable. This has been now changed so that the vehicles are emitted in steps starting at <begin> and ending at <end>-1.
    • Types given in trips were always replaced by "KRAUSS_DEFAULT"!!!. This has been patched. Now the type you specify will be used and only if no type information was given, "KRAUSS_DEFAULT" will be used.
  • Changes in version 0.9.5
    • OD2TRIPS was rewritten for the 0.9.5. version. Most things still should work as well with older versions, but the options --vtype, --prefix, --timeline, and --timeline.day-in-hours were not available.
    • The usage of --od-files and --vissim within OD2TRIPS differs from prior versions.
    • --od-files was named --od-file in OD2TRIPS versions prior to 0.9.5.
  • Changes in version 0.9.6
    • printProgress.pl is a part of the distribution since version 0.9.6.

5.10. Missing

--lane-weights is not tested and described

--scheme is not implemented and described

--max-alternatives is not tested and described

--prune-random is not tested and described

spread uniformly of DFROUTER is not described


last change: Wednesday, 30-May-2007 02:13:54 PDT