Difference between revisions of "Demand/Importing O/D Matrices"

From Sumo
Jump to navigation Jump to search
(Describing the TAZ)
(note on normalization)
Line 221: Line 221:
* All time lines describe the hourly percentage of the complete traffic
* All time lines describe the hourly percentage of the complete traffic
* values are normalized to 100% (so they don't need to add up to any specific value)
* It is not possible to derive time-lines for all week days
* It is not possible to derive time-lines for all week days

Revision as of 08:16, 23 March 2015

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

Because OD2TRIPS was only used to import data stored in VISUM/VISION/VISSIM formats, it assumes O/D to be stored in one of the formats used by these applications. Not all VISUM/VISION/VISSIM formats are supported, by now only two, namely the "V"- and the "O"-format. If you do not own matrices stored in these formats, you still have three possibilities:

  • convert them into one of the supported formats,
  • write your own reader for OD2TRIPS, or
  • convert them into flow definitions and then give them to DUAROUTER (see Chapter "Using Flow Definitions").

Since SUMO 0.21.0 there is the additional possibility to read matrices in the Amitran format given by http://sumo-sim.org/xsd/amitran/od.xsd.

All supported formats are described in #Describing_the_Matrix_Cells below. You may either give a list of matrices to OD2TRIPS using the --od-matrix-files <FILE>[,<FILE>]* (-d <FILE>[,<FILE>]* for short) option followed by the list of files separated using a ','.

OD2TRIPS reads all matrices and generates 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 <FILE> (-o <FILE> for short). You can specify a vehicle type to be added to the trip definitions using --vtype <STRING>. Please remark that vehicles will have no type unless not given in the O/D-matrices or defined using this option. The command line 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 <TIME> (-b <TIME>) and --end <TIME> (-e <TIME>), 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 be inserted into the network within a certain time period, OD2TRIPS has to compute the vehicle's explicit departure times. Normally, this is done by using a random time within the time interval a O/D-matrix cell describes. It still is possible to insert a cell's vehicles with an uniform time between their insertion. Use the option --spread.uniform to enable this.

You can scale the amounts stored in the O/D-matrices using the --scale <FLOAT> option which assumes a float as parameter. All read flows will be multiplied with this value, 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.

Describing the TAZ

A file containing a mapping from traffic assignment zones (TAZ) to edges looks as following:

   <taz id="<TAZ_ID>">
      <tazSource id="<EDGE_ID>" weight="<PROBABILITY_TO_USE>"/>
      ... further source edges ...

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

   ... further traffic assignment zones (districts) ...


This means that a TAZ is described by its id, being a simple name, and lists of source and destination edges. A TAZ 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 insert and remove vehicles into/from the network respectively. The probability sums of each the source and the destination lists are normalized after loading.

If you do not want to distinguish between source and sink edges and give all edges the same probability you may as well use the following abbreviated form (it is also posible to mix both styles):

   <taz id="<TAZ_ID>" edges="<EDGE_ID> <EDGE_ID> ..."/>

   ... further traffic assignment zones (districts) ...


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 vehicle type information is used by OD2TRIPS by passing it to the generated vehicles. The type definition itself will not be generated, but the vehicle will have set the attribute type="<TYPE>". The time informations are assumed to be in the form <HOURS>.<MINUTES>. Please note that the end is exclusive; for example, if

0.00 1.00

is given, the generated vehicles' depart times will be second 0 to second 3599.

The V format

The V-format stores the O/D matrix by giving the number of districts (TAZ) 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:

* vehicle type
* From-Time  To-Time
7.00 8.00
* Factor
* some
* additional
* comments
* District number
* names:
         1          2          3
* District 1 Sum = 6
         1          2          3
* District 2 Sum = 15
         4          5          6
* District 2 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 seem to be left-aligned 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

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 occurs after the type identifier "$OR" in the first line):

* From-Time  To-Time
7.00 8.00
* Factor
* 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

The Amitran format

The Amitran format defines the demand per OD pair in time slices for every vehicle type as follows:

<demand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://sumo-sim.org/xsd/amitran/od.xsd">
   <actorConfig id="0">
       <timeSlice duration="86400000" startTime="0">
           <odPair amount="100" destination="2" origin="1"/>

For details on the types and units see the schema at http://sumo-sim.org/xsd/amitran/od.xsd

Splitting large Matrices

OD2TRIPS allows splitting matrices which define a long time period into smaller parts which contain definite percentages of the whole. There are two ways of defining the amounts the matrix shall be split into. In both cases, the probabilities are automatically normed.

Free Range Definitions

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:

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.

Daily Time Lines

The second case is rather common in transportation science. It allows to split the matrix into 24 subparts - this means the number of fields 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 inserting a vehicle within the according hour.

Some common daily time lines from Germany may be retrieved from: Schmidt, Gerhard; Thomas, Bernd: Hochrechnungsfaktoren für manuelle und automatische Kurzzeitzählungen im Innerortsbereich. Hrsg.: Bundesministerium für Verkehr, Abteilung Straßenbau: Forschung Straßenbau und Straßenverkehrstechnik. Heft 732, Bonn-Bad Godesberg, 1996

Applicability of generic Time Lines

Name Description Reference
TGw2_PKW.txt passenger vehicles, Tuesday-Thursday, cities in West Germany, type#2 = ~streets at inner city border S.95
TGw3_PKW.txt passenger vehicles, Tuesday-Thursday, cities in West Germany, type#3 = ~streets at city border S.95
TGs1_PKW.txt passenger vehicles, Saturday/Sunday, cities in West Germany, group#1 = ~inner city streets, large amount of trips to/back work, freeways with no connection to recreation areas S.100 - 103
TGw_LKW.txt transport vehicles, Monday-Thursday, cities in West Germany S.98
TGs_LKW.txt transport vehicles, Sunday, type: ~long distance roads, strong heavy duty vehicle numbers S.102, 105

So, in dependence to the week day and the type of traffic, one could assume using the following time-lines:

vehicle type Monday Tuesday-Thursday Friday Saturday Sunday
HDV TGw_LKW.txt TGw_LKW.txt X X TGs_LKW.txt
passenger, far-distance X TGw3_PKW.txt X TGs1_PKW.txt TGs1_PKW.txt
passenger, near-distance X TGw2_PKW.txt X TGs1_PKW.txt TGs1_PKW.txt

One may note, that no time lines are given for passenger trips on Mondays.

The time lines as such are given below, they can be directly copied into the command line

Generic Time Lines

Name Time Line
TGw_LKW 0.3,0.4,0.4,0.6,0.8,2.0,4.8,7.5,9.0,8.7,9.0,9.0,7.5,8.4,7.8,6.9,5.4,4.0,2.7,1.8,1.2,0.9,0.6,0.3
TGw3_PKW 0.9,0.5,0.2,0.2,0.5,1.3,7.0,9.3,6.7,4.2,4.0,3.8,4.1,4.6,5.0,6.7,9.6,9.2,7.1,4.8,3.5,2.7,2.2,1.9
TGw2_PKW 0.8,0.5,0.4,0.3,0.4,1.2,4.5,7.4,6.6,5.2,5.0,5.0,5.2,5.3,5.6,6.7,8.4,8.6,7.4,5.0,3.9,3.0,2.1,1.6
TGs(1)_PKW 3.3,2.8,2.0,1.5,1.2,1.3,1.2,1.5,2.5,3.7,4.8,5.5,6.0,6.7,7.0,7.1,6.9,7.4,7.0,6.0,4.7,4.1,3.5,2.3
TGs_LKW 1.3,1.1,0.6,0.8,0.9,1.5,2.6,3.1,3.5,3.8,4.5,4.9,5.0,5.3,5.6,5.7,5.9,6.0,5.7,5.3,4.8,4.6,10.0,7.6


  • All time lines describe the hourly percentage of the complete traffic
  • values are normalized to 100% (so they don't need to add up to any specific value)
  • It is not possible to derive time-lines for all week days

The time lines describe how the traffic (100%) spreads over the whole day. In order to have proper demands for week-end days, one can scale down the week day traffic. The same reference as above gives the following scaling factors at page 31.

Daily time-line scale factors

area Sat1992 Sun1992 Sat1993 Sun1993
NRW highways 76,1% 72,7% 72,8% 69,4%
NRW other streets 82,6% 74% 78,3% 71,6%
Bavaria 75% 67,2% 73,9% 64,7%

One may note that this information is 15 years old. Additionally, no information about the type of vehicles is given.

A 24h time line a given O/D-matrix shall be split by may be given to OD2TRIPS using the following options: --timeline.day-in-hours --timeline <TIME_LINE> where <TIME_LINE> is a list of 24 percentages as given above. The amount of traffic defined within the O/D-matrix may be scaled via --scale <SCALE>. Example call to OD2TRIPS:

od2trips -n <NET> -d <MATRIX> -o <OUTPUT> --scale <SKALIERUNG> \
   --timeline.day-in-hours --timeline <TIME_LINE>

Dealing with broken Data

OD2TRIPS behaves here as following:

incomplete districts

  • missing origin OR destination district: error
  • missing origin AND destination district: warning

incomplete connections

  • missing connection to an origin OR a destination district: error
  • missing connection to an origin AND a destination district: error

See also

Seventh Framework Programme AMITRAN project This part of SUMO was developed, reworked, or extended within the project "AMITRAN", co-funded by the European Commission within the Seventh Framework Programme.