Contenu
Home
The methodology defined
The proposed indicators
Methodology application - Two case studies
The web based application

Sustainable Mobility Indicator

HOME

Urban mobility is a decisive aspect for the sustainable development of a city, with specific concern on air quality. In particular, traffic congestion is considered by most people to be the main cause of the deterioration of living conditions in our towns.

One of the aims of the CITEAIR II project is the development of a methodology and a tool that is able to describe the situation of traffic and the related impacts in urban agglomerations by means of an indicator. The methodology and the tool has been designed trying to find a compromise between an easy comprehension of the measure for citizens (non expert) and the scientific value of the procedure (expert). In order to take account of the various aspects of urban transport the methodology comprises rather a set of indicators than only a single one.

The main input to describe the traffic situation will come from traffic measurements, with special attention to flows and speed. Regarding the description of the traffic impacts on the environment and on the citizens, a link with the Common Air Quality Index (CAQI) defined within the CITEAIR project (more info at http://www.airqualitynow.eu) has been established with the final aim of defining the citizens exposure to traffic.

The structure of the indicators has been designed flexible enough in order to consider as many aspects as possible: different time scale, spatial scale, transport mode.



THE METHODOLOGY DEFINED

To obtain a time-dependent indicator of traffic and mobility that is consistent and comprehensive requires in theory the continuous monitoring of the entire transport network, which implies measuring every few minutes the flow state (speed and density) of at least each major link.

Today, through an advanced methodology based on the simulation of transport demand, of drivers route choice and of the traffic phenomenon, it's possible to extend field data retrieved from just a limited number of road links to cover the entire transport network.

This approach requires a relevant modelling effort (road graph, o-d matrices, traffic models) that may be considered out of scale, and above all it could create unsolvable problems for that cities where deep knowledge on traffic models aren't available.

As a result, the proposed indicators will be based simply referring to the links where a traffic measure is available (e.g. loop detector, traffic control camera, travelling vehicle), although this clearly may affect consistency and comprehensiveness. In other words, we accept the assumption that the measured links are a significant sample of the whole urban network, so that an average made on the sample, or on a part of it (if the indicator refers to specific portions of the network), well reflects reality.

Clearly the methodology will work both with data coming from automatic traffic measures or from traffic models.



THE PROPOSED INDICATORS

To describe the two main issues of the project, two sets of indicators have been designed in order to evaluate:

  • Traffic situation in urban agglomeration - Transport and Mobility Indicators
  • Traffic impacts in urban agglomeration - Exposure indicators

Transport and Mobility Indicators

Regarding the description of the traffic situation in urban agglomeration, seven possible indicators have been defined going from the simpler approach related to traffic (that refers to the transport supply, closer to the administration point of view) to the more comprehensive one related to mobility (referring to the transport demand, closer the user point of view). It's clear that the measure obtained represents the average situation of the whole urban agglomeration (or the zones in which it has been divided).

The seven possible indicators are listed and explained below:
  • NAS - network average speed. It represents the average speed of vehicles throughout the whole road network. So it is a broad measure of the performance of the entire road network.
  • NSI - network speed indicator. It has been derived from the NAS by relating the speed measured on each road with the free flowing speed of that road (i.e. the "ideal speed", typically achieved when very few vehicles travel on the road). It gives an indication on "how much close" to the free flowing speed is the speed measured on each link and throughout the whole road network.
    The value of NSI indicator ranges from 1 (i.e. when the average speed measured on the road sections are equal to the free flow speed) to 0 (i.e. traffic jam).
  • VAS - vehicle average speed. It represents the average speed of vehicles on the network, being weighted by the flow that experiences the measured speed. The indicator, better than NAS, represents the performance of the network by linking it to the traffic flows.
  • VSI - vehicle speed indicator. As the NSI, it has been derived from the VAS by relating the speed measured to the free flowing speed. It gives an indication on "how much close" to the free flowing speed the vehicle (because the speed is weighted by the traffic flows) that are travelling on the whole road network are.
  • NTI - network time indicator. It represents the time spent on the network by vehicles compared to the time spent "ideally" by the same vehicles if they could travel at free flow speed.
    In case NTI = 2 then this means that vehicles are travelling on the network at half of the free flow speed doubling so their overall travel time; in case NTI = 1 vehicles are travelling in ideal condition (free flow speed).
  • NDI - network delay indicator. It represents the amount of delay that is overall experienced on the network by vehicles.
    In case NDI = 0 then this means that NTI = 1, thus vehicles are travelling on the network at free flow speed and are not experiencing delay. In case NDI = 1 then this means that NTI = 2, thus vehicles are travelling on the network at half of the free flow speed and are experiencing a delay that doubles their overall travel time.
  • ATT - average trip time. It represents the average time spent on the network from the users that on average will travel for a certain distance (average value for the urban agglomeration) at the average speed whose value is VAS.

Exposure indicators

The computation of Traffic impacts in urban agglomeration needs the combination of two information:

  • mobility: information on the time spent by citizens in traffic condition. The information needed are two: the average travel time ATT (updated with the traffic state) and the standard travel time STT (expected value of ATT);
  • air pollution: index of roadside pollution level. CTI - Citeair Traffic Index defined within the CITEAIR I project (for more info see http://www.airqualitynow.eu).

In particular, the exposure to traffic condition (impacts) is calculated through the difference between the actual trip time ATT and the standard trip time STT, under the consideration that one minute more into traffic means one minute less in background situation (home, office, leisure). This difference is the time that a car driver, due to the traffic condition improvements/worsening, has been less/more exposed to traffic pollution level given by the roadside index CTI.



METHODOLOGY APPLICATION - TWO CASE STUDIES

The methodology before described has been tested with real traffic data gathered in the cities of Paris and Rome. The analysis carried out concern the indicators related to mobility issues (Transport and Mobility Indicators).
In particular, in the following it has been analyzed:

  • Rome and Paris methodology test overview.
  • Input data used in the indicators evaluation.
  • Results from the calculation of some indicators (most representative).
Rome and Paris methodology test overview

These two case studies have been chosen for the huge amount of traffic data available on each of them. The comparison analysis that follows refers to indicators' value of the private mode even if in the city of Rome also data regarding public transport have been gathered.

As before said the procedure is absolutely capable to work with any data source. In fact data could be gathered with any type of technology available in the city that wants use it. These two case studies confirm this possibilities because traffic data for the city of Paris come from a traffic model while in Rome they derive from ITS (Intelligent Transport System) devices.
With regards to the gathering periods: Rome data refers to the year 2009 while Paris data refers to 2007 year.

Rome and Paris application - Results

These case studies have been undertaken to test and demonstrate the applicability and usefulness of the methodology and the tool. It is not meant to be a true comparison of the traffic situation between Paris and Rome.

In the following pictures a comparison between the results for some indicators have been reported. In particular the reported pictures compare - both on hourly and monthly basis - the results of some indicator computation obtained for Rome and Paris. Even if the reference year is different, the comparison has been performed on equivalent periods.

From the results' analysis emerge that similar trends in traffic status exist between the two case studies even if absolute values are different.

That's the case, for example, of the average vehicle speed: VAS.

The analysis carried out, both on a monthly basis (from January to October) and on a hourly basis (48 hours in mid September to show his trend between Sunday and Monday), show how the trend is quite similar but the absolute values are different.
On monthly basis the way of traffic is similar, and so the highest speed are achieved during the summer period - when less vehicles travel - while in the working period the VAS values are quite stable during the months. The main difference between Rome and Paris is the value of VAS during the working period. In fact while in Paris this value is about 40 km/h, in Rome it's a little bit lower: 35 km/h.
Keep looking at the VAS but going down on the hourly basis (48 hours in mid September, Sunday and Monday) the comparison shows that, on average, in Sunday higher speed than in Monday are achieved. This result depends by the fact that in Sunday less vehicle are in the network and so there is no congestion.
Looking at the average travel time - ATT - it emerges clear how the values between the two cities are different: 10 minutes in Paris and 22 in Rome. This result depends by two factors:

  • the different average trip distance: 7 km in Paris and 12 km in Rome;
  • the different value of the VAS that, as seen before, is higher in Paris than in Rome.



THE WEB BASED APPLICATION

This section is dedicated to present a new web-based application to compute and present the indicators proposed and described above.
Actually the two functions (compute and present) are implemented through two different applications on different technologies:

  • (a)  an off-line scientific software that on a daily base retrieves the traffic measures and the other information from a database, makes the necessary mathematical calculations, and writes the indicators values in the same database;
  • (b)  a web page where users can plot the temporal and spatial pattern of the desired indicator, by a guided query to the database.
The database is composed by three sets of tables:
  • the first one (input) gathering real time measures incoming by all sources (to apply the methodology in an automatic way a standard format data format has been defined),
  • the second one (periodized) storing the data read from the first one (input), aggregated by hour,
  • and the third one (output) storing the indicators calculated along the available period basing on the data read from the second table set (periodized).
After the indicators have been calculated by the algorithm and stored to the database, they can be queried and plotted by the user via a web interface. There are in place:

(a) a group of controls he selects in order to compose the query. In the details:
  • the city and the corresponding zones
  • the mode
  • the indicator
  • the aggregation type
  • the aggregation start and end dates
(b) a static image showing the selected city and the shape of its zones
(c) a linear chart plotting the queried data
(d) a table with the exploded data, so that the user can copy/paste them in a worksheet and operate further computations



    © copyright CITEAIR 2007 FacebookTwitter | Flux RSS | Nous rejoindre | Contacts | Plan du site | Mentions légales