-
Notifications
You must be signed in to change notification settings - Fork 2
TechnicalOverview
Date: | feb 1, 2011 |
---|---|
Author: | Yoann Pigné |
Organization: | University of Luxembourg |
Contact: | yoann@pigne.org |
Version: | 1 |
Copyright: | 2010-2011, University of Luxembourg |
Summary
This document is an overview of the implementation and functioning of the VehILux tool.
There are 2 main steps int VehILux. First, the generation of mobility patterns based on different sources of information and configurations. Second, the evaluation of the generated traffic in comparison to control data.
Java-classes architecture tries to figure out this duality. Classes dedicated to the generation are in sub-package:
lu.uni.routegeneration.generation;
with Class RouteGeneration
as main class.The evaluation resides in:
lu.uni.routegeneration.evaluation ;
with Class RouteEvaluation
as main Class.
The main trait of this project is that it collects data from several sources to generate traffic. The generation itself is driven by somme parameters, found in différent configuration files of given a run time. By convention configuration files are named after the SUMO convention (e.g. myProject.net.xml for the network file, myProject.rou.xml for the route file).
The main class RouteGeneration
handles all the generation process. 3 global parameters are used at each step of the generation:
- baseName that representes the base name of the different configuration files that will be read/written. (Default=LuxembourgVille).
-
baseFolder
is the folder in which all the files should reside. In this way you may create a folder per project. (Default=./test/). -
stopHour
. By default traffic data is on a 24 hours bases, starting at midnight. Here, only the morning comute is simulated, so the traffic should not be generated for the all day. The start hour is 0h and cannot be tunned for the moment. (Default=11).
A baseName.net.xml file with SUMO's network format is needed to:
- compute the boundaries of the area;
- get the name of all edges to ensure the position of real data traffic sources.
For the sake of optimization, baseName.net.xml files are converted into another format: DGS files.
A baseName.osm.xml file is required to discover zones. Building steps are:
- Read the file for zones.
- create zones (Commercial, Residential, Industrial) with
Zone
objects. - Store zones in the 'zones' map.
Note
Note for speedup. Is it possible to store one Dijkstra on one "reference" node for each residential zone?
- pros: speed up computation
-
- cons:
-
- larger DGS files stored,
- strengthen dependency to DGS files
A baseName.areas.xml file is required to initialize
- Attractivity areas,
- and the default weight for zone types.
Building steps are:
- File is read and the areas are created (
Area
Class). - Areas are stored in the
areas
list. - Zone types probabilities are set, normalized and stored to
ZoneType.RESIDENTIAL.probability
...
An example baseName.areas.xml file:
<areas residential_proba="5" commercial_proba="80" industrial_proba="15"> <area id="1" type="COMMERCIAL" x="20418" y="14500" radius="1500" probability="10"/> <area id="2" type="COMMERCIAL" x="22400" y="16700" radius="1500" probability="15"/> </areas>
A baseName.veh.xml file is required to initialize the different types of vehicles that will be created. Each will be represented with equal density.
One file example:
<vtypes> <vtype id="porsche" accel="2" decel="7" sigma="0.6" length="4" maxspeed="50" color="1,0,0" /> <vtype id="206" accel="1.7" decel="6" sigma="0.5" length="4" maxspeed="40" color="0.4,1,0.4" /> <vtype id="306" accel="1.7" decel="6" sigma="0.5" length="4.5" maxspeed="40" color="0.4,0,1" /> <vtype id="twingo" accel="1.4" decel="6" sigma="0.8" length="3.5" maxspeed="35" color="0.4,0.8,1" /> <vtype id="cx" accel="1.1" decel="5" sigma="0.5" length="5" maxspeed="35" color="0.9,0.9,0.9" /> </vtypes>
A baseName.loop.xml file is required to get the real traffic information. FRom this file are created Loop
and Flow
object.
- The
Loop
represents a real counting loop device. It is linked to an edge (with an id existing in the .net.xml file). For each hour from 1 (12am to 1am) to 24 (11pm to 12am), it has an associated flow. - The
Flow
Class representes for one loop at one given hour the load of traffic expected for trucks and cars.
One file example:
<loops> <loop direction="Aire de Wasserbillig - Echangeur Munsbach" id="1430" edge="10929032#1"> <flow cars="80" hour="1" trucks="35"/> <flow cars="70" hour="2" trucks="35"/> <flow cars="56" hour="3" trucks="38"/> [...] <flow cars="164" hour="23" trucks="48"/> <flow cars="112" hour="24" trucks="41"/> </loop> <loop direction="Belgique - Luxembourg" id="20" edge="-24716829#4"> <flow cars="14" hour="1" trucks="1"/> <flow cars="9" hour="2" trucks="0"/> <flow cars="10" hour="3" trucks="0"/> [...] </loop> </loops>
The inner traffic ratio is a parameter of the main program, set as a parameter at run time.
The evaluation of the traffic is done by running the microsimulation tool SUMO. The mobe is used to generate the traffic. That traffic is evaluated at the same positions in the network as the position of real counting loops. For the sake of speed of execution it is also possible to compute the theoretical amount of traffic, hour by hour that the model would generate. This evaluation is done by counting in the model the appearance of the edges where real counting loops are located.
The Mobility model outputs a baseName.rou.xml that can be used to compute the microsimulation in sumo. The output data given by sumo will be the counting of simulated vehicles passing through the counting loops. These counting loops are placed according to the position of the real control loops with the help of so called detectors defined with another configuration file: baseName.e1.xml.
One baseName.e1.xml file example:
<additional> <e1-detector id="401_0" lane="-22964079#7_0" pos="1" freq="3600" file="LuxembourgVille.e1.401_0.xml" friendly_pos="1"/> <e1-detector id="401_1" lane="-22964079#7_1" pos="1" freq="3600" file="LuxembourgVille.e1.401_1.xml" friendly_pos="1" /> </additionnal>
Output appears on other xml files that need to be processed by the SumoEvaluation
Class. For instance:
java lu.uni.routegeneration.evaluation.SumoEvaluation --baseName=LuxembourgVille --baseFolder=./test/ --stopHour=8
This will output a baseName.sumo_eval.log file that contains the essential information needed to compare, evaluate and optimize the model. It’s a matrix with hours as rows and detectors as columns:
time 1431 1429 445 433 416 415 404 432 407 401 400 403 420 413 412 1 55 24 11 38 5 8 5 5 8 21 28 2 4 3 1 2 59 20 11 28 4 4 2 3 5 16 36 4 3 3 1 3 57 23 10 21 1 5 0 7 4 11 39 2 3 2 0 4 56 25 17 27 6 7 1 5 3 16 35 1 1 0 2
The ApproximativeEvaluation
Class computes the baseName.approx_eval.log from the evaluation of the generated baseName.rou.xml mobility model.
The RealEvaluation
Class computes the baseName.real_eval.log from the evaluation of the real counting data found in the baseName.control.xml file.