Skip to content

TechnicalOverview

Jump to bottom
pigne edited this page Mar 4, 2011 · 3 revisions

Technical Overview

Date: feb 1, 2011
Author: Yoann Pigné
Organization: University of Luxembourg
Contact: yoann@pigne.org
Version: 1
Copyright: 2010-2011, University of Luxembourg

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).

Traffic Generation

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).

Input Data

Sumo's Network

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.

OpenStreetMap's Network

A baseName.osm.xml file is required to discover zones. Building steps are:

  1. Read the file for zones.
  2. create zones (Commercial, Residential, Industrial) with Zone objects.
  3. 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

Areas Definition

A baseName.areas.xml file is required to initialize

  • Attractivity areas,
  • and the default weight for zone types.

Building steps are:

  1. File is read and the areas are created (Area Class).
  2. Areas are stored in the areas list.
  3. 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>

Vehicles types

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>

Real traffic data

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>

Parameters

The inner traffic ratio is a parameter of the main program, set as a parameter at run time.

Traffic Evaluation

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.

MicroSimulation Evaluation with SUMO

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

Approximative Evaluation

The ApproximativeEvaluation Class computes the baseName.approx_eval.log from the evaluation of the generated baseName.rou.xml mobility model.

Real Data Evaluation

The RealEvaluation Class computes the baseName.real_eval.log from the evaluation of the real counting data found in the baseName.control.xml file.

Clone this wiki locally