PART III – ISHTAR suite software realisation · 2015. 7. 3. · PART III – ISHTAR suite software realisation 3.1 ISHTAR suite architecture 3.1.1 General composition of Ishtar

PART III – ISHTAR suite software realisation

3.1 ISHTAR suite architecture

3.1.1 General composition of Ishtar Suite To fit the constraints of modularity of integrated software and flexibility of Ishtar Suite, the suite contains 3 main components :

?? a user interface, called Ishtar Suite Interface (ISI), the part of software managing the control of the suite by the user

?? a manager, called Ishtar Suite Manager (ISM), the part of software managing the processes inside the chain, the exchanges of data, the monitoring of elementary tools; this manager corresponds to the integration manager mentioned in previous chapter; this manager will be connected to the set of software tools, SW1 to SW9, carrying the models involved in the suite.

?? The different specialized softwares of the suite.

This architecture can be represented by the following diagram :

Fig. 3..1.1.1 ISHTAR Suite software components

3.1.2 Realisation of data exchanges by use of tool connectors Each elementary software has to send to and receive data from the Ishtar Suite Manager, for further exchange with other software. To achieve that, the elementary software comprises a piece of software, called a connector, the role of which is to prepare the data in a structured, well defined format, agreed by ISM.

ISMISI

Ishtar Suite

Interface

Ishtar Suite

Manager

SW1

SW2

SW3

SW4

SW6

SW7

SW9

ElementarySoftwares

ISMISI

Ishtar Suite

Interface

Ishtar Suite

Manager

SW1

SW2

SW3

SW4

SW6

SW7

SW9

SW1

SW2

SW3

SW4

SW6

SW7

SW9

SW1

SW2

SW3

SW4

SW6

SW7

SW9

ElementarySoftwares

ISHTAR Project Publishable Final Report

2

A connector must do the following functions:

?? Control the exchanges between ISM and Tool send to ISM information on data used by the tool

receive, from ISM, information on data requested by the tool

send to ISM information on data created by the tool

send to ISM information on the status of the tool

?? Control the execution of the tool prepare data requested by the tool

control the run of the tool according to ISM requests

Fig. 3.1.1.2 data exchanges through connectors

ISI

ISM

ISDB

ISGIS

C2 Tool2

C1 Tool1

C3 Tool3

C4 Tool4

C6 Tool6

C7 Tool7

C9 Tool9

SoftwareTools+

Connectors

Ishtar Suite

Interface

Ishtar Suite

Manager

Ishtar Suite DB

Ishtar Suite GIS

ISI

ISM

ISDB

ISGIS

C2 Tool2

C1 Tool1

C3 Tool3

C4 Tool4

C6 Tool6

C7 Tool7

C9 Tool9

C2 Tool2C2 Tool2

C1 Tool1C1 Tool1

C3 Tool3C3 Tool3

C4 Tool4C4 Tool4

C6 Tool6C6 Tool6

C7 Tool7C7 Tool7

C9 Tool9C9 Tool9

SoftwareTools+

Connectors

Ishtar Suite

Interface

Ishtar Suite

Manager

Ishtar Suite DB

Ishtar Suite GIS


3

3.2 ISHTAR suite user interface

The ISHTAR suite software is accessible by the way of two user interfaces : a raw interface, used by developers during the design of the suite, known as « Board ». and a graphical one.

3.2.1 The BOARD The menu driven interface is intended to give full access to all the functions of the Ishtar Suite Manager, allowing to view & edit objects.

The native (included in the code) functions are :

?? managing studies and scenario (create, save, restore, change) ?? launching WP tools (by the way of connectors) ?? start and show the history of work (.log file)

Functions for setting up the study have been added to by-pass work-package 1 & 2 (not integrated at this time) :

?? ground setup : define the library of traffic files, hierarchy of disk ?? choice of pollutant(s) to be computed. ?? Time loop setup.

The last part of functionalities are dynamic, they are not included in the source code, but Board is able to launch various kinds of companions (unauthorised examples are included in the distribution):


4

?? ‘macros’ are list of instructions (written in the same XML syntax as the initialisation files). They allow to start any sequences of operations (internal to the manager, connectors and tools, gadgets, assistants and host operating system commands).

?? ‘gadgets’ are stand-alone applications, they have access to the objects. ?? ‘openers’ are more linked to a class and give the tool to be used by board for handling

objects (displaying or editing) ‘assistants’ are independent documents (Windows speaking), not linked with the manager, they will be started according to the rules on the workstation, as example are a documentation file (with .doc extension), will be opened with MSWord or Wordpad) and a web page (.html) will start the current browser (Internet Explorer if not modified) and show the content.

3.2.2 The graphical user interface. This second part uses the services of a GIS : Arcview 9.x from Esri

Primarily the interface will allow the user to check and use each functionality of the GIS :

?? receiving ‘ground data’ by an XML file (network and zones) ?? extracting and storing back link level data (flows emissions) ?? creating a ‘grid’ to receive concentrations resulting of the dispersion modules (WP 4)

Later the same interface will allow the display of dynamic maps, predefined by the way of Arcview projects (.mxd files)


5

3.3 ISHTAR Data Model & Time Loop Description During the integration activities the ISHTAR Partners identified the need for a detailed definition of data to be exchanged among the tools to be decided and agreed upon by all partners. The purpose of the data model is to make sure that the data being exchanged between all the modules is in a consistent format and can be adapted for in whichever module they are required. As an example the sub division of traffic types can vary between models and this has to be synchronised. The formulation of the IDM has involved an iterative process requiring the agreement of all partners using any particular data. The IDM has allowed us to identify the data requiring aggregation between different modules and to decide where the aggregation is best performed. In tab. 3.3.1 an example of a data described in the data model is given.

Tab. 3.3.1 Data model example

Data category Exchanged/Output

Name of data pollutants emission: per hour, link and km

Type of data (real, integer, alpha) real Unit Kg/(hr*km) Admitted range > = 0 Temporal scale (hr, day, year) per hour Spatial scale (link, grid, domain) Per link Other Attributes (e.g. pollutant, vehicle class…)

per pollutant, per Scenario

Origin (which tool or actor provides it) WP3

Destination (tool receiving this data) WP4

Notes this data has to be presented as output on the GIS

Comments: specify which SW provider is commenting the data, use this cell also for declaring the insertion of a new data

approved by the Coo

GIS Information: Is it a GIS Object? Is it an attribute of a GIS Object?? Which one??

LINK attribute

Database address : Database / Table / Attribute names

to be defined by Jerome

Request for ISHTAR GIS Output to be presented in the Links Layer with a thickness proportional to the emission value

Request for ISI (mainly general data)

none


6

The ISHTAR Suite Time Loop and Description of Use is a guide to how to build in informatic sense, to use and understand the suite. It has been used for reaching the agreement on the temporal sequence of all the actions that have to be made for preparing and managing the running of the suite, for making a ‘study’ that includes ‘scenarios’. Practically it has been also the first draft of the user manual, as it drives the user, step by step, through the actions


7

3.4 Cellular Transport Methodology (CTM) description The Cellular Transport Module (CTM) software estimates the daily distribution and movement of people in a urban context in the form of Origin-Destination matrices. The CTM module is composed by some sub-modules related each other in the following way: The cellular transport module (CTM) produces two main outputs:

1 five origin-destination matrices for each considered mode and purpose (the peak hours matrices and off-peak hours matrices);

2 present population in each zone and in every time period. Models to calculate O/D matrices are built following the classical three-step process:

Trip generation

Trip distribution

Modal split

INPUT DATA

TRANSPORT MODULE

POPULATION MODULE

OUTPUT: O/D MATRICES FOR MODAL SPLIT AND PURPOSE FOR EACH TIME LAG

OUTPUT: PRESENT POPULATION IN EACH TIME LAG


8

The resulting output data are O/D matrices split by different transport modes. The trip generation sub-module calculates the number of trips generated from each zone for a particular trip purpose and user category in each time period. The Cellular Transport Module (CTM) takes as input the distribution of travel demand generators and attractors and other parameters to estimate:

?? the Origin-Destination flows over the 24 hours period, and in particular car flows, to be fed into the ISHTAR suite’s traffic model

?? presence of population over night and day times, to be fed into the ISHTAR suite health impact model

The spatial scale adopted in CTM can be flexible, depending on the type of policy scenario addressed. However, results of the CTM should be re-conducted at the scale of the transport zones used in the ISHTAR case studies to forecast the behaviour of transport variables. Whenever the scale of the cellular analysis is more aggregate (e.g. in the urban sprawl policy scenario the analysis will be usually carried out considering, on average, only few concentric zones – about 10), an interface module between the CTM and the subsequent model of the ISHTAR suite will be used, to split aggregate O-D flows into disaggregated O-D flows, at the needed level of detail and using appropriate criteria.


9

3.5 VISUPOLIS description During the course of the ISHTAR project, PTV has acquired the commercial rights of METROPOLIS and has included its core algorithms into the VISUM suite so that the last version of VISUM contains as well a conventional static assignment algorithm as the dynamic demand algorithm (departure time modelling) and the dynamic traffic flow model (queue modelling) of METROPOLIS. VISUM and Metropolis are linked in a way that VISUM works as fronted with a GUI using the METROPOLIS dynamic assignment model. The result of the Metropolis assignment will be traffic volumes per link and per time slice. That new version of VISUM can be used very easily by most cities in order to "dynamise" their existing static model. The new product would allow to convert very easily existing conventional static traffic models into dynamicones, making possible to deliver much more reliable input data (speed and flows) to the emission and dispersion models. Moreover, by including the METROPOLIS code, the VISEM/VISUM software suite provides to the users all the tools they may want to apply in the process of an urban transportation study, covering completely all the four classical modelling steps from generation/attraction to multimodal assignment. The network for METROPOLIS simulations is derived from the VISUM network as follows:

?? Nodes and zones are directly transferred. ?? Connectors are transferred with their connector time.

Links are transferred directly. Capacities are always taken to be in [veh / hour], regardless of the simulation period. Instead of the capacity restraint function specified in VISUM, METROPOLIS uses a linear bottleneck function. METROPOLIS examines the demand descriptions in VISUM and assigns all demand segments simultaneously. The OD matrix itself is taken from VISUM, but a demand time profile (if present) is ignored. Instead METROPOLIS uses the concept of a desired arrival time distribution per demand segment. Trip-makers are assumed to have an exogenous ideal arrival time for their trip and to (endogenously) choose the best possible departure time under the simulated traffic conditions. The departure time choice model takes the form of additional cost terms for early / late arrival in the generalised cost function. In the current implementation of the METROPOLIS integration, desired arrival times are assumed to be uniformly distributed in a given time interval. The interval boundaries are set in the METROPOLIS parameter dialog within VISUM. All demand segments share the same desired arrival time distribution. The most important METROPOLIS parameters can be specified from the Calculation/Procedures… dialog, when the METROPOLIS procedure is selected. The installation of METROPOLIS is currently performed in two steps: first the end user download/read from a CD a package designed with InstallAnywhere that takes care of all the system-dependent issues:

a) Install the Java machine if necessary, b) Install the .DLL in the system at the good locations, c) Install METROPOLIS GUI shortcuts.

The second step of the installation takes place when the end-user start METROPOLIS for the first time:

d) Check that MYSQL server is up and running, e) Initialize the connection parameter to the MYSQL database, f) Create the required METROPOLIS table.

These initialization tasks have to be performed from the overall installation setup.


10

METROPOLIS uses the same data as any static traffic assignment (network, O-D matrices) except for a few exceptions:

g) Dynamic volume-delay functions h) User-types and behavioural parameters i) Simulation specific parameters

Briefly, the dynamic functions are the congestion functions on each link of the network. These functions can be selected arbitrarily by the end-user. The behavioural parameters are the value of time, the penalty for delayed arrival and the schedules of the vehicles. The simulation specific parameters are, for instance, the number of iterations, the time interval for the outputs, etc. All these input data can be provided by default or can be specified from within the PTVision GUI. A script can be written that will parse the VISUM/VISEM input files and translate them into SQL queries for the MYSQL database. The fact is that METROPOLIS uses only a small fraction of the tables present in the VISUM network file. In addition, METROPOLIS does not have turning penalties for instance, so it might be the role of VISUM of preparing a network where intersections have been split for METROPOLIS. The simulator monitor module is responsible for calling the METROPOLIS executable and to pass it the good arguments to connect to the database. It also monitors the progress of the simulation and potentially reports that progress to the VISUM interface. The monitor stays alive until the simulation is over. At that point, it imports the results in the database and exits. This module is also responsible for reporting error and warning messages. The output translator module is responsible for reading the results from the METROPOLIS database.


11

3.6 Transport Energy Environment (TEE) software description The new version of ENEA-TEE model (TEE2004) has been developed with several features allowing the user to better analyse transport related direct impacts, taking into account vehicle kinematics, cold emission distribution, parking processes, noise emissions and accident occurrence. As it regards vehicles kinematics, TEE calculates link emissions by adopting different options: average speed based emissions, instantaneous emissions, and the innovative ‘kinematics correction functions’ model describing both traffic flow condition and vehicle behaviour. For cold start emissions distribution, TEE offers alternative solutions based on defaults of cold percentage depending on area type and day hour, or on the user input of either a link based cold fraction or the driven distance from trip origin. The parking submodel provides a meaningful treatment of traffic flows from and to parking areas and so allows to better locate cold start vehicles emissions and evaporative emissions in space and time. TEE2004 includes two fully new models: the noise emission model and the accident occurrence model.. The former is sensitive to vehicle speed and heavy duty vehicles presence. The accident model calculates the number of accidents involving only vehicles or vehicles and pedestrians and splits them by severity. These new models broaden the scope of TEE software from emissions modelling to the area of the direct impacts of transport systems. Furthermore a new routine for calculating the effect of the electric loads has been inserted. The new version of TEE software has been assessed both at micro and integral level, always obtaining positive results. Further information will come from the application of the tool in the seven case studies of the ISHTAR Project alongside which the model has been developed. These results will be just available at conference time. The TEE2004 software program, realised along the EC FP5 ISHTAR Project 2001-2005, consists of independent modules, each performing a dedicated action ??The Input module, reading all the requested data from a number of specific input files ??The Traffic module, for the post processing of the information given by the used traffic model ??The Accident occurrence module, estimating the number of accidents link by link ??The Fuel and Energy Consumption module, estimating the consumptions for each microscopic

vehicle category considered (defined by the COPERT methodology) ??The Pollutants Emissions module, estimating the emissions of the pollutants selected by the user ??The Noise Emissions module, calculating the noise emission level, to be used by a noise

dispersion module ??The Output module, providing results with different levels of aggregation. The related calculation steps of the program are the following: ??Input of traffic and network data organised link by link, and of the other data needed by TEE

(fleet composition, parking information, average hourly temperature for each month...) ??Calculation of the fleet and kinematic variables needed for the subsequent steps. ??Calculation of the accidents along the link involving vehicles and crossing pedestrians, or only

vehicles. Accident occurrences are estimated with an adaptation of the TRL methodology, as agreed with INRETS in the ISHTAR Project. ??Calculation of the ‘normal’ consumptions of each single category, based on the COPERT III,

MODEM, DVB data or the KCF approach (see below) depending on the kinematic option selected ??Calculation of the several correction factors for consumptions (e.g. cold start, slope....) ??Calculation of the hot ‘normal’ emissions of each single vehicular category based on the

COPERT III, MODEM, DVB data or the KCF approach (see below) depending on the kinematic option selected ??Calculation of the several correction factors for emissions


12

??Calculation of the noise emission levels expressed in dB(A), related to the flow along the link. The noise emissions calculation is based on the NMPB french methodology (interim model for the EU). ??Calculation of the ‘real’ emissions and ‘real’ consumptions from the ‘normal’ values and the

calculated correction factors, with aggregation of results from the micro level to the link and network level (bottom up approach) ??Output of the results with different aggregation levels (by vehicle class, link by link, by zone or

by the entire network) and creation of different specific output files Hot Consumptions and Emissions calculation is performed in different ways according to the user kinematics choice. The simplest calculation makes use of the basic consumption and emission correlations provided by COPERT III and use only the average flow speed in each link of the network. For each vehicular micro category present in the fleet composition related to a specific link, the ‘normal’ emission values are calculated using the COPERT III and MEET correlations. More detailed emission calculation are performed by using the available databases of instantaneous emissions. This calculation mode is carried out when the most advanced kinematics options are selected by the user (see section 3). The experimental data sources for this type of calculation are MODEM (DRIVE II Project) and DVB (Graz Technical University database). Cold Start Emissions are calculated according to the DG VII MEET and COPERT III methods. The correlations normally used are principally provided by COPERT III and they are functions of the air temperature and, for a set of vehicle categories, of the vehicle speed. The code needs essentially information about the percentage of cold vehicles in the flow. If this data is not available, the code can perform the calculation using a distribution of percentage of cold vehicle depending on the hour of the day and the type of area involved into the calculation. The cold start emissions are closely linked to the parking processes (see section 3). The inserting vehicles from parking areas are generally ‘cold’ and they are important for the correct evaluation of the total emissions along the link. The evaporative emissions are calculated according to the CORINAIR methodology, that is adapted to the microscopic link-based level.. The code considers three type of evaporative emissions: running losses, diurnal losses and hot soak. For these three contributions we must consider the three fundamental types of flows modelled within TEE software: transit, parking and inserting flow. The consideration of these three different types of flow is important because the evaporative emissions calculation needs the information related to the number of vehicles being parked at a given hour (hot soak) and to the vehicles present in the link environment (diurnal emissions). The TEE evaporative emission model is a micro adaptation of the aggregated CORINAIR approach used in COPERT III and takes decisive advantage of the existence of the TEE Parking Model. The TEE code considers several other corrective factors affecting the emissions; maintenance correction, age correction, altitude correction, gradient and load corrections. All these corrections are made by multiplicative functions applied to the ‘normal’ consumptions and emissions. These corrections are essentially performed according to the MEET and CORINAIR methodologies. The new version of the ENEA’s TEE software – developed within the FP5 ISHTAR Project – represents an interesting evolution of the classic traffic emission models in the direction of the multiple impacts analysis, by adding noise and accidents in a common calculation framework based on advanced description of vehicle kinematics including the crucial parking process that has a large relevance on the spatial and temporal distribution accuracy. An example of map produced with TEE output is shown in figure 3.6.1


13

25/11/2005 ENVIRONMENTAL HEALTH RISK 2005 29

TEE – Output - Pollutants emissions- CO – Red= Before : Yellow = after

Figure 3.6.1 : Map of CO emissions in Rore and after the implementation of the measure


14

3.7 ARIA IMPACT description ARIA Impact is a Gaussian Cartesian model for calculating the long-term impact of emissions from industrial sites, vehicular traffic, and diffuse sources. The ARIA Impact program is designed to serve two purposes:

?? To generate statistical output of meteorological data at a specific site, allowing analysis of the atmospheric dispersion conditions at the site;

?? To simulate the dispersion of atmospheric pollutants from one or several emission sources based on Gaussian equation formulations.

The system takes into account meteorological conditions by computing physical parameters relevant for the simulation of pollutant transport and dispersion. The main principle of the software is to simulate the dispersion over several years by using time series of monitored meteorological data related to the specific site. The simulation generates results for pollution concentration at ground level, with a selection of statistical output required for compliance with regulatory norms and guidelines for air quality. The model can account for emissions from different types of sources including: point sources, line sources, area sources, volume sources.

The previous picture shows the Main Window of the ARIA Impact User Interface, where the geographical domain of interest is displayed, along with isopleths of Air Pollution concentration, traffic links, topography and point sources. The management of emissions allows both the simple import of existing time series derived from an emission model such as TEE and the introduction of additional pollution sources such as industrial stacks. Hourly time modulation of sources (e.g. as a function of industrial activity) is allowed in interactive form, and this aspect is one of the major improvements brought to the package during the ISHTAR Project, now available in Version 1.4.


15

Time series analysis (plots, wind roses) is available for all types of meteorological data :

The software allows multiple choices for dispersion parameters in the Gaussian framework. For example, since different formulations may give better results when applied to different types of stacks (large, small, very buoyant), the software allows the user to select his preferred formulation. Among the significant features of the model :

- inclusion of topographic effects (if a terrain file is provided) - puff model activation under calm wind conditions - radioactive decay (for substance category « Activity ») - NO/NO2 conversion for traffic emissions - plume rise - downwash of the gas plume due to turbulence around the stacks, - mixing layer evolution and plume limitation - generation of wind profile and temperature profiles - washout by precipitation

A significant investment has been made by ARIA Technologies in the coding of a Street Canyon option but progress in this direction and the comparisons over Paris cases were not good enough to allow this option to be released in ARIA Impact 1.4. The algorithm should probably be available for Version 2.0 at the end of year 2005.


16

Receivers with a fixed receiver spacing

3.8 SOUNDPLAN description SoundPLAN is implemented in ISHTAR for the noise propagation calculation. Noise levels from the noise propagation calculation are needed in ISHTAR to constitute the basis for the exposure evaluation and for the health risk assessment of the citizens in the “Health Impacts” module. The noise propagation calculation is based on emission levels provided by the module “Transport Direct Impacts”. SoundPLAN, one of the worldwide leading standard acoustics software developed by Braunstein+Berndt Germany, is a complete software suite consisting of independent modules for building the data model, doing the noise calculation, creating informative maps and evaluating the results. The calculation is based on a ray tracing method (see part 2.6). All major international calculation standards for road, railway, industry and aircraft noise are implemented in SoundPLAN. The software suite is used by more than 3000 users in over 30 countries. (please see www.soundplan.com for further information). SoundPLAN offers various noise calculation modes, e.g. single point, façade noise map, grid noise map and city noise map calculations. For the integration of SoundPLAN in ISHTAR we decided to use primarily the “City Noise Map” calculation, a calculation mode which calculates noise levels for receivers at buildings, road edges, screening elements and free field points on the basis of a triangulation (see picture below). In comparison with a grid map which has a fixed receiver spacing, the “City Noise Map” needs many less receiver locations for exhaustive noise maps with the same accuracy.

This SoundPLAN calculation mode provides ISHTAR with the required noise levels in a fast and effective way. According to the Environmental Noise Directive the standard “NMPB-96” is used for the noise propagation calculation in SoundPLAN. ISHTAR uses the original SoundPLAN calculation kernel. All necessary adaptations for SoundPLAN were implemented into the SoundPLAN connector (SPC), a new developed program for the integration of SoundPLAN into ISHTAR.

Receivers based on a triangulation; each vertex of a triangle represents a receiver


17

This program is able to communicate with the ISHTAR Suite Manager (ISM), to build the SoundPLAN data model automatically, to control the SoundPLAN calculation kernel and to provide the “Health Impacts” module with the required data without any user interaction. The SoundPLAN data model is based on already existing geometry data from a GIS as shape files and an emission file provided by the “Transport Direct Impacts” module. The required geometry data are:

?? Terrain information ( 3D point or line) ?? Buildings (3D polygon with the additional properties building height, number of floors and

reflection loss) ?? Population zones (2D polygons with an additional value for the number of occupants in that

zone) ?? Road geometry (3D polygon with the additional properties link ID or node information

(from node, to node) used for a unique identification to link the emission levels) ?? Calculation area (a 2D Polygon which defines the area in which SoundPLAN creates

receivers) The interface can be easily adapted to enable the usage of data from different resources, in different languages and even with a different structure. The SPC assigns the emission levels to the relevant road geometry during the model preparation and distributes the population form the zones to the buildings inside this zone by using their ratio on living space to zone area. The SPC starts the SoundPLAN calculation program and waits until the calculation is finished. Afterwards the SPC prepares the results from the original SoundPLAN results and exports them as a shape file. The calculated results can either be used in the “Health Impacts” module (façade level LDay_Evening_Night, LNight (loudest façade) and number of occupants per building) for doing their own evaluation or in a GIS for creating noise maps (LDay_Evening_Night, LNight for all receivers from the “City Noise Map” calculation). All activities of the SPC will be stored in “WP42log.txt” (communication with ISM) and the “WP42dbg.txt” (connector activities) during the runtime. Additionally to the full automatic use of the SoundPLAN calculation kernel it is also possible to use the complete SoundPLAN package in the ISHTAR suite. This would enable the user to add additional objects to the data model, to do extended model preparation, to use additional calculation modes, to create informative maps and to do own evaluations on the results using the powerful SoundPLAN Spreadsheet module.


18

3.9 Transport EXposure (TEX) description The assessment of the exposure of the population to different concentrations of pollutants depends on where people are at specific times and it is thus highly space and time dependent. As a matter of fact, people are exposed to multiple pollutants sources. Data on time activity patterns are then crucial inputs to exposure models. Within the ISHTAR suite an exposure module, TEX, was developed under a GIS platform in order to be able to match population time activity data with spatial dispersion maps of pollutants. TEX is composed of a collection of different command-buttons on which information can be entered following a logic sequence and estimated number of persons exposed is presented. The tool is based on a static and semi-dynamic approach. This approach combines information on concentration of pollutants with data on population residential habits and time-activity patterns to estimate the exposure of a given population to air pollutants and noise. This module operates within ArcGIS and produces exposure assessment for groups defined by the user, according to different features. The exposure software calculates the exposure of predefined groups along the scenario duration (from 1 hour to 1 year) of the considered case study. The TEX software is dedicated to the assessment of exposure of people to pollutants. All the input data necessary to simulate the behaviour of people were considered in building the software. Key components of the model are: 1) a static exposure module 2) a semi-dynamic exposure module 3) a database with a referenced Time Activity Data 4) I/O ratios. The “normal” adult population is usually modelled when considering available data. In this way, vulnerable groups are generally underrepresented although they include children, the elderly, people with various diseases (e.g., hypertension), people in hospitals or those rehabilitating from disease or injury, pedestrians. The issue of vulnerable subgroups in the population should be considered when modelling population exposure and if developing regulations or recommendations for the management of traffic. TEX: Interface of the software for the assessment of the exposure to traffic risks

The possibility of running different scenarios and organizing data in an integrated way is an important advantage to assess alternative policy measures.


19

3.10 Health Impact of Transport (HIT) description

The HIT software is dedicated to the assessment of Health impacts of transport. The review on health impacts stresses the importance of establishing a set of relevant health endpoints and, for each of them, identifying a concentration-response coefficient and its confidence interval. All the epidemiological implications for which there is availability of a large number of studies were considered in building the Health Impacts software. Health effects can be modelled only at a broad temporal and geographical scale (e.g. yearly for large groups of people) due to their reliance on dose/effect relations determined in epidemiological studies conducted at this high level of aggregation. Among the air pollutants that can possibly be considered for their effects on health, particulate matter (PM), in particular PM10, is of particular interest, given the availability of a large number of epidemiological studies that have developed concentration-response models, allowing the quantitative estimation of its health impact. Considering the most recent evidence of health impacts of noise from road traffic in official use in the E.U it was decided to include dose-response curves for two different health endpoints related to exposure to noise:

?? Annoyance ?? Sleep disturbance.

Traffic crashes are an important cause of deaths, injuries and disability, involving road users in different ways. Speed is a critical factor in determining the severity of accidents and the model included in the software tool uses empirical estimates to developing an assessment in the urban context under investigation. The models used in accidents impact assessment try to identify the form of the relationship between speed, that is a critical risk factor, and the frequency or the severity of a collision between moving vehicles and road users. General risk indicators are available at the scale of the whole road network based on a measure of exposure to the risk, uncertainties remain concerning the type of road-user and the most appropriate measure of exposure for pedestrians or bicyclists. It is worth remembering that there are several limitations that must be considered in the assessment of health impacts, for example: 1) poor exposure assessment; 2) validity of extrapolating results from epidemiological studies carried out on a population to other populations for impact assessment. Regarding the noise health impacts there is sufficient evidence for developing dose-response curves between noise exposure and annoyance and sleep disturbance The accidents processing algorithms are the most experimental part included in the software. They are based on the relationship between a critical risk factor such as speed and the severity of a collision between moving vehicles and road users. It has to be stressed that, while this tool can be devised relatively easily, it remains crucial that the outcomes should be interpreted with care, using expertise in the field.


20

HIT: Interface of the software for the assessment of the health impacts of transport: an example of the air pollution and noise sections


21

3.11 MOnuments DAmage (MODA) description The MODA (Monuments Damage) tool has been developed purposely for the ISHTAR Project with the following capabilities: - compute potential damage based on available equations - keep records of monuments on damage evolution and maintenance activities - keep records on environmental conditions at the monument’s location (i.e. microclimatic data,

atmospheric pollution and built-up space conditions) - investigate the impact of different pollution levels on damage (e.g. due to pollution reduction

policies) - compute the cost between estimated damage restoration and good maintenance practice or

pollution reduction measures The software has been based on the following four modules that also describe the procedure for damage analysis:

1. Data Bases Updating 1.1 Meteo Data 1.2 Pollution Sources 1.3 Built-up Space 1.4 Monuments 2. Preparation of Input & Processing 3. Damage Calculation 4. Cost Calculations

Fig. 3.11.1 Basic architecture of MODA s/w and the connection with the ISHTAR suite

TOOL 7

MonumentModule

DamageCalculation Sub-

moduleVisual Basic

Cost CalculationSub-module

Visual basic

Output Module

ISMISI

ISGIS ISDB Monument DBMS ACCESS

ISI = ISHTAR Suite Main Interface ISM = ISHTAR Suite Manager ISGIS = ISHTAR Suite Geographical Information System ISDB = ISHTAR Suite Data Base


22

The input requirements have been defined as derived from the damage functions. Some input data directly depend on the results of other WPs when MODA is running as part of the ISHTAR suite. However, in the stand alone version the user may input own data. The user can have at his/her disposal the databases where he/she can insert the information on a monument. This information contain: - geometrical data, - materials details, - geographical coordinations, - location characteristics - microclimatic conditions - environmental conditions (i.e. emissions, concentration of pollutants) The structure of the database is easy to use and simultaneously offers guidance to the user. The software has been conceived to fulfil the needs of the user in the best possible way. In addition to evaluating the impact of various pollution reduction policies on damage deceleration the user will be able to compare the cost associated with the implementation of a given pollution reduction policy with restoration and maintenance costs. Furthermore, the software will provide the user with the means to: a) file the monument damage status and be able to keep the damage history in an electronic

environment b) provide information of the built-up space so that the user can judge its impact on the monument

damage evolution. These functions will support in an efficient way the works of the monument preservation competent bodies such as ministries, municipal and regional authorities, museums etc and to all the professionals involved in the diagnostics of ancient constructions. The s/w was produced solely within the ISHTAR project. That means there was not any similar tool or s/w available that one could be based on or built on. In addition to the module embedded in the ISHTAR suite, MODA has been also produced as a standalone tool. Furthermore, the monument data base (see diagram 1) can also be used as an autonomous tool for filing information on monument conditions (i.e historical data, restoration, maintenace etc.). The standalone version operates with Microsoft Access and is written in Visual Basic.


23

3.12 Model for Overall Scenario Evaluation and Synthesis (MOSES) software description

The overall aim of WP9 is to provide a tool which can globally assess1 social, economic and environmental benefits produced by the measures implemented in the test sites. The evaluation tool can be used at both programme and project levels. A tool which would also evaluate policy was felt to be inappropriate to the range of objectives within ISHTAR. The evaluation tool developed is included in the ISHTAR suite as an aid to the users. The appraisal will help and influence the local authorities' choice between alternative strategies of maximisation of the urban quality of life. It is set up to effectively provide a comparison between three scenarios: the opening situation carried forward (the do-nothing scenario) a forecast scenario based on predictions from upstream ISHTAR software models and direct inputs from city authorities, and the situation after the relevant measures have been fully implemented and their effects have had time to work through the system (the actual scenario). The tool can be used to assess those quality of life changes predicted to occur as a result of implemented measures, as well as in evaluating the actual results. It can compare the relative impacts of predicted and actual outcomes. These comparisons help the formulation of new policies and adjustment to ongoing measures. It is crucially important that an appraisal is tailored to provide decision-makers with the means to test the various schemes or policies against the objectives which they are intended to meet. Appraisals frequently fail to include a statement of objectives or to show how principal outputs relate to those objectives. The tool therefore uses an evaluation framework which is adaptable to different purposes, starting from a general level of framework which can be modified as needed with respect to different circumstances. The data for the framework has been defined in terms of the topic measurements and values pertaining to each user. The screenshots below show the form in which the multi-criteria data will be presented. In each case the information from the opening scenario is compared with either the forecast scenario or the actual scenario depending of the view chosen by the user. The screens have data from upstream models, the calculated cost-benefit ratio and the framework data derived from user inputs.

Fig. 3.13.1 Investment cost – Actual scenario, City of Rome case study

1 The word "assess" is used alternatively with "evaluate" and "appraise" to describe the main function of WP9.


24

The investment cost screenshot shows the user inputs regarding sub-categories of investment costs (planning costs, real estate acquisition costs, construction costs, equipment costs, etc.). The sub-categories sum to the total investment costs. The evaluation module can run with inputs either as total investment costs or for each sub-category.

Fig. 3.12.2 System operating and maintenance cost – Actual scenario The user needs to input data regarding system operating and maintenance costs. This can be undertaken either through the sub-categories (administrative and monitoring, periodical and day 2 day maintenance etc) or as a total value.

Fig. 3.12.3 Cost Benefit value The Cost Benefit value screenshot shows the Net Present Value (NPV) and the Cost Benefit Ratio. It is calculated on the basis of the values given in previous sheets on costs as well as inputs from the ISHTAR suite. The calculation of NPV and Cost Benefit Ratio requires that the user determines a discount rate (how future costs and benefits translate into values today) and a project life time.


25

Fig. 3.12.4 MCA tool with “Provide better quality of life” overall goal, and some objectives The user should provide information about the overall objectives considered in the MCA (e.g. Better Quality of Life) as well as specifying individual objectives (e.g. reduce the need to travel by private motorised transport, promote public transport, cycling and walking).

Fig. 3.12.5 Indicators (data from other WPs) - Actual scenario This sheet concerns those MCA indicators determined elsewhere in the ISHTAR suite (e.g. number of casualties, vehicle emissions and traffic levels). No user input is required at this stage. The module calculates the change in these indicators compared to the Do-Nothing. Also a MCA score is calculated taking into account the relative weights for each criterion considered in the MCA.


26

Fig. 3.12.6 Indicators (data from users) - Actual scenario The user has to input scores regarding a number of indicators included in the MCA (e.g. perceived quality of personal security, general accessibility levels of mobility impaired groups, perceptions of safety from traffic). The scores are formed as expert judgements on a scale from +4 to -4. The evaluation module compares the scores from the actual scenario with the ones obtained in the Do-Nothing and calculates the change in score values. Also, a MCA score is calculated taking into account the relative weights for each criterion considered in the MCA.


27

PART IV – Suite and modules applications

4.1 Cases studies introduction Urban areas are affected by emissions from noise and airborne pollutants due to road traffic. The most effective measure to reduce such nuisance would be the reduction of the traffic load. Since this is in many cases not possible, abatement measures have to be set. One of such measures is the improvement of the road network with the main emphasis on improvements in the environmental related aspects, other measures concern changes in modal split, etc. The aim of ISHTAR is the development of an integrated tool for assessment of actions to improve air quality in cities. In order to prove the applicability of the ISHTAR suite case studies have been defined in various regions and cities. These case studies form a forum for testing different modules of the suite as well as the whole suite and allow an application of the tools to various environmentally related measures. In the framework of the ISHTAR project the cities and regions of

?? Athens – Attica region, GR ?? Bologna Province, I ?? Brussels, B ?? Grenoble, F ?? Graz, A ?? Paris, F ?? Rome, I

applied the ISHTAR model suite at a whole or parts of it. The different applications covered totally different measures, starting from long term measures to short term measures as well as from measures covering big areas to measures with a very local impact. While it was at the outset of the ISHTAR project the intention to apply the ISHTAR suite to all of the case studies, it turned out during the course of the project that – due to time restrictions – the majority of the case studies covered the application of single modules of the suite. The case studies can be described as follows (a detailed description of the case studies follows in the next sessions):

1. Athens-Attica region In the Attica region, where Athens is one of the major municipalities (114 municipalities in total), there are more than 2.000.000 vehicles running on the network and more than 5.500.000 person trips (all purposes) every day. The application that will be used for the ISHTAR suite case study deals with the new roadway construction the so-called “Attiki Odos” or “Attica Periphery Road”. This new toll highway will be assessed in terms of traffic, toll strategy and pricing, environmental conditions in the highway and all of its accesses, etc. During the case study ISHTAR suite modules for traffic, emissions and noise have been applied.

2. Bologna region The case study concerns an Environmental Impact Assessment of a new infrastructure for the City of Imola, a municipality belonging to the Province of Bologna. The goal of the simulation procedure was to estimate the impact on air quality of a new infrastructure framework for the City of Imola, in order to provide for a high level of protection of the environment. Different infrastructural scenarios have been considered aiming at supporting the decision-making process to choose between the alternative which is likely to have less significant effects on the environment. During the case study ISHTAR suite modules for traffic and dispersion have been applied.


28

3. City of Brussels

After having observed the strong relationship between road traffic intensity and air pollutant concentrations, the Brussels Capital Region (BCR) has decided to prepare a set of traffic banning measures and suited accompanying measures to be implemented when atmospheric conditions forecasts exceed some pollutant concentration thresholds. Various scenarios describing traffic banning measures were investigated and the benefits for reductions in congestion time and improvements in emissions described. During the case study ISHTAR suite modules for traffic have been applied. Brussels acted in addition as demo location for the new traffic module VISOPULIS.

4. City of Graz

In the city of Graz the historically grown road network lacked in a certain region in a good connection between two major roads. This unsatisfactory situation led to an increased traffic load in residential areas between these two roads. In order to improve that situation a new connection was built in the form of a cut and cover tunnel. As one of the portals of this tunnel is situated very close to residential buildings the concern about environmental impacts was very high. Therefore an environmental impact study was commissioned to prove the effects of this project are in accordance with the noise pollution and air quality standards. Within the framework of ISHTAR the traffic emission and the dispersion module have been applied. In addition a detailed inter-comparison between different emission and dispersion tools has been performed.

5. City of Grenoble Set at the crossing of three alpine valleys, Grenoble (150 000 inhabitants) is the major city of the Grenoble urban area (470 000 inhabitants). This location means that the city has a high density of population on a small surface and that many urban streets have heavy traffic; the population is exposed to noise and air pollution linked with this traffic. The network of public transportation is in constant evolution: two lines of tramway deserve the areas of high density of population and activities, the third one will be in operation in 2005. It will cross Grenoble from east to west, on the main boulevards of Grenoble (over 60 000 vehicles/day). Unfortunately, considering the time period, it is impossible to monitor the tramway implementation in the framework of ISHTAR. Hence, it is intended to monitor the effects of the installation of reserved lanes for public transportation and new traffics lights on boulevards with heavy traffic in Grenoble (60 000 vehicles/day).

6. City of Paris

Every September 22nd, the City of Paris takes part in a car free day called “En Ville Sans Ma Voiture" (EVSMV). In 2002 and 2003, the experiment was implemented in the historical centre of Paris (area concerned: 3 x 2 km). Between 7 a.m. and 7 p.m., this central area was only accessible to public transport, taxis, “green” vehicles (LPG and electric cars) and professional users. The temporal and spatial scale of the experiment focuses the assessment on the short-term road-side air quality impact. The background pollutant concentration, which is a regional parameter with strong weather dependence, sets the context. Airparif's experience prior to ISHTAR has shown that the modeling tools must take into account detailed road geometry and traffic characteristics, in particular fleet composition and traffic congestion. The objective of the ISHTAR case study was to test the enhancements to the modeling tools contained in the ISHTAR suite. The traffic and pollution dispersion modules have been applied during the case study.

7. City of Rome The increased numbers of private cars in Rome have resulted in increased traffic congestion and atmospheric pollution. The city of Rome has established various strategies to tackle traffic problems implementing a framework to rebalance the modal split towards public transport and promote alternative means of transport.


29

An access restriction for non-catalysed vehicles has been implemented within the “Rail Ring”. The “Rail Ring” area, which surrounds the historic centre, is densely populated with a high concentration of activities making it one of the key areas in the city for intervention to lower emissions caused by motorized vehicles. This provision also exempted goods vehicles and specific categories of vehicles and road users. A simulation of the ISHTAR suite was prepared to test the input-output connections among different software of the suite, data exchange with external software, modelling factors, and clarity of output comprehension. The ISHTAR suite run the simulated case study with the traffic, emission, dispersion (air and noise) and exposure modules. The case study of Rome can be considered as the most comprehensive ISHTAR suite application within all of the case studies.


30

4.1.1 Attica Region case study Abstract The Athens Case Study focused on the recent construction of the pioneering and of enormous size, construction, “Attica Road” motorway in the region of Athens.

As in all the cases of large projects, such as the above, as well as all the great advantages offered to the city, some disadvantages might occur. Therefore the objectives of this case study was to record the situation existed

prior to the construction of “Attica Road” motorway and compare it to the environmental (air quality and sound pollution), traffic and health conditions altered due to the operation of the motorway.

For the specific case study, due to the length of “Attica Road” motorway and due to the fact that the entire project did not begin to operate at the same date, but in several stages, they have been selected 3 main parts of “Attica Road” and the entire Western Peripheral Road. (DPLY). As presented in the final report, many extremely useful outcomes were produced by this case study, helping the actors involved to mitigate part of the impacts and improve the majority of the disadvantages caused by the motorway. Therefore, “Attica Road” motorway had a great benefit from this case study and managed to improve its operation status. Introduction In Attica region, where Athens is one of the major municipalities (114 municipalities in total for the whole region), there are more than 2.000.000 vehicles running on the network and more than 5.500.000 person trips (all purposes) every day. The total area of Attica has been modelled under a GIS platform (TRANSCAD GIS and Transport Model V4.7) and it’s available for the ISHTAR applications. In this modelling there are more than 50.000 links (basic roadway network). The total area has been divided in a number of traffic zones (700 to 1300 pending on the focus of the application) where data exist in databases for all the traffic zonal system. The application used for the ISHTAR suite case study, dealt with the new roadway construction the so-called “Attica Road” or “Attica Periphery Road”. This new toll highway was assessed in terms of traffic, toll strategy and pricing, environmental conditions on the highway and all of its accesses/egresses, etc. In addition, all new projects that will impact, one way or another on this new motorway were assessed as part of the total traffic condition in Attica region. Because of the 2004 Athens Olympic Games, various new projects (stadiums, accesses, roadway links, light rail, etc) have been constructed. All of these “projects” as well as the additional needed infrastructure have been implemented in the database. The roadway network is being created according to the standard of the Geographical Data Format (GDF v3.0) and all the databases have been implemented and are available in dbf, xls, txt format etc. Data are available not only in various formats but also for numerous time periods (2001, 2004, 2010, 2015, etc.). The application envisaged is two fold:

1. The largest domain (45 x 45 km²): to provide regional conditions (traffic, air quality, noise, etc.) where the results will be given by the current TRANSCAD Transport Model (with a resolution of 500m)

2. The smallest domain (5 x 5 km² or less): to be assessed by the ISHTAR suite modules (at a street level, accesses, etc. district, area, etc)


31

Data for the Athens case study – Attica region The case study (application) for the Attica region, as far as the part of the transport is concerned, is mainly for the air quality in two types of scale as described above. The data used for the implementation of the project (also available) are: Traffic data Traffic data (15-min counting period) for important intersections and (5-min counting period) for links. Traffic data are also available (based on the TRANSCAD model) for the whole Attica region (2000, 2004, 2010, 2015, etc.) and of course can be modelled for any future horizon, time period, am or pm peak, 18-hour, daily, etc. for any year. Average vehicle flow measurements, Average vehicle speed measurements, Occupancy rates, Level of Service (HCM 2000 – HCS 2) Numerous measurements of effectiveness Description and road simulation, traffic, conditions, geometric characteristics, etc. are available based on the Geographical Data Format (GDF) V3.0 standard. Meteorological and air quality data Meteorological data, were either collected and/or calculated for the Attica region. Meteorological data taken into account are: wind direction, wind speed, standard deviation of wind speed, temperature, relative humidity, solar radiation, precipitation. The following table shows the limits of warning and imposition of extraordinary measures for the region of Attica:

POLLUTANT LIMIT of WARNING

LIMIT OF IMPOSITION OF EXTRAORDINARY METRES

O3 180 µmgr/m3 360 µmgr/m3 NO2 400 µmgr/m3 500 µmgr/m3 SO2 250 µmgr/m3 300 µmgr/m3 CO 20 mmgr/m3 25 mmgr/m3 SMOKE 250 µmgr/m3 300 µmgr/m3

In Attica region there are nine stations for the calculation of concentration of air pollutants. These stations are located in:

?? Patision ?? Peristeri ?? N. Smirni ?? Liosia ?? Marousi ?? Aristotelous Av. ?? Pireaus ?? AGRICULTURAL UNIVERSITY OF ATHENS ?? Athinas Av. ??

Pending the selection of models for the ISHTAR suite and the inputs needed we can reform and/or add to the above referenced parameters.


32

Emission data Emission data are available based on the air pollution models that were used in Athens (our offices). These models have been calibrated and validated for the Attica region fleet (1996). New information is available (fleet 2000) and the models will be calibrated again. Availability of data is for almost all types of emission. Air Pollution Air Pollution Analysis has been undertaken through TEE 2003 model and LAKES Environmental Software with the Support of the Aria Impact Models Measurements

?? 25 points chosen close by Attica Road (Passive receptors) ?? 8-10 points full measurements by the special Mobile Multi-system of the National

Observatory of Athens ?? 70-80 points in the major arteries within the Attica basin (passive) ?? Meteorological data for all days of measurements (various scenarios

Figure 4.1.1.1: An analysis of the NOx pollutant during the operation of the Attica Road (ELESS & DPLY) motorway (real measurements)

Figure 4.1.1. 2: Difference before and after the operation of the Attica Road motorway for the NOx pollutant (real measurements)

Figure 4.1.1.3: An analysis of the NOx pollutant, an output of the Lakes software, after the operation of the ELESS.

Figure 4.1.1.4: An analysis of the NOx pollutant, an output of the Lakes software, after the operation of the DPLY.


33

Noise Analysis Noise Analysis has been undertaken with the SoundPlan Model Measurements

?? 25 points cross sections of Attica Road (based on the Damen Directive) ?? Other measurements (general) on major arteries where flows, classification and

meteorological data are collected at the same time Figure 4.1.1.5: An analysis of the Noise dispersion before the operation of the DPLY. Figure 4.1.1.6: An analysis of the Noise dispersion after the operation of the DPLY. Traffic Analysis Traffic Analysis has been undertaken with TRANSCAD v4.7 (GIS Traffic Model) and the small geographic areas have been undertaken by the TSIS, TRANSYT-7F and HCS s/w. Apsis Ltd., as mentioned above, primarily uses TRANSCAD as the basic tool for the implementation of the Transportation Model of Attica Region. This tool offers the possibility to reduce the modeling (study) area and create an OD-matrix for the sub area chosen. Therefore, for the ISTHAR application, a Sub-area analysis procedure was undertaken and an O/D matrix for the area (sub-area) under consideration was implemented. The geographic files are built on the projection based on Europe class and Greek grid system (GR87=datum, GRS80=ellipsoid). The selected sub-area contains 170 internal zones and 76 external points that are used as feeders for the incoming trips in the sub area from the external zones. Apart from the implementation and design of the traffic model various other analyses and steps where followed like:

?? Speeds measurements on major arteries with floating car technique (7:00 am - 7:00 pm) ?? Traffic flow measurements along the arteries on specific locations (nodes & links) ?? Major arteries mobility utilizing TRANSYT-7F & micro-simulation models (TSIS 5.0)


34

?? Topographic data on very good scales (1:500) or (1:200) on specific micro cases ?? Accident data collection (last 3-5 years) of the under study area ?? Detailed GIS based network (TRANSCAD) for the sub-area analysis under study ?? New Vehicle classification for the Attica Region (a study for the last 5 year changes) by

type of catalytic converter, super, diesel, etc. ?? Various other data under collection management process ?? Correspondence with noise and air pollution measurements

Conclusions ISHTAR provided various benefits to:

?? Ministry of Planning, Environment & Public Works, ?? “Attica Road” JV, and overall ?? the citizens of Athens (especially those living in areas adjacent to the highway)

with the analytical structure of the models and the results, by explaining in clear manner the highway’s operation and its impacts (before & after). One major issue that has to be noted, is that with the operation of the highway, (after case study analysis), 250.000 vehicles travel in Attica Road at an average of 15 km per trip, meaning (250.000 veh x 15 km) 3.750.000 vehxkm daily. All of these vehicles are now in the highway, providing a major relief to the local network of 3.750.000 vehxkm daily. In addition, this highway is becoming very popular for the Athenians, and the traffic is increasing every month, reaching, on certain days and/or certain times of the day (especially am and pm peak periods), congestion levels. In the cases where the noise caused by the traffic was proven to be above the limits for the surrounding settlements, noise barriers have been installed along the motorway achieving the prevention of the dispersion of sound towards residential and other sensitive areas (schools, hospitals, etc.). The analysis of air pollution and noise impacts indicated that this motorway would not cause great negative side effects to the environment. Now, people once opposed to such an enormous project within Athens city’s bounds were re-assured and relieved since no great health impacts were about to be imposed on their lives. Special notice was also shown to the accident factor; the report on this analysis indicated that accidents have been reduced within the region of Attica.


35

4.1.2 Bologna Province case study Objective of the case study The case study concerns an Environmental Impact Assessment of a new infrastructure for the City of Imola, a municipality belonging to the Province of Bologna. The ISHTAR modules used to carry out the case study are the the Direct Impacts Module (TEE2004), the pollutants dispersion module ARIA IMPACT and the noise propagation module SOUNDPLAN. The goal of the simulation procedure was to estimate the impact on air quality of a new infrastructure framework for the City of Imola, in order to provide for a high level of protection of the environment. Different infrastructural scenarios have been considered aiming at supporting the decision-making process to choose between the alternative which is likely to have less significant effects on the environment. The scenarios were built up with reference both to direct interventions of traffic management (new paths, roadway adjustment, intersection regulation) and to indirect interventions (public transport services, etc.). The air concentration of NOx, CO and PM10 from road emissions have been modelled. These pollutants were chosen because they are the most critical ones for the Province of Bologna and because of their important contribution to the photochemical smog and to ozone formation. The simulation of some of the different scenarios offered the opportunity to test the suite as an integrated tool for supporting decision-makers in adopting environment-conscious actions. Case study area/location The proposed work concerns the “Pedagna est-ovest” area and has been designed to facilitate the circulation of vehicles in the north-south direction. It links the existing stretch of the “equipped axis”, at the junction with the SS 9 Via Emilia, with the SS 610 Selice Montanara, upstream of the junction with Viale D’Agostino. Public participation has required a series of meetings during which citizens/committees proposed additional alternatives, which were compared with the submitted project. Among the several alternatives, some proposed by the Municipality and some by the Citizens, three have been simulated with the ISHTAR Suite. The three considered alternatives are three different paths for the “equipped axis”, one proposed by the Municipality called ‘Definitive Project’ and the other two, alternative 5 and alternative 6, proposed by the citizens. Collected data The three scenarios were run for one single day, the 16th of January 2003, a day with a particular high concentration of PM10 due the unfavourable meteo conditions. The meteo data used for the simulation are from the Imola Mario Neri meteo monitoring Station and are used for all the three scenarios in order to make them comparable. We used hourly values of wind speed (average 1.18 m/s; max 3.2 m/s, min 0.2 m/s ) and direction (main direction from West-South-West), temperature ( average 1.12, min –0.8°C, max 2.2°C c) humidity (average 89,5 %). Traffic data The traffic data were provided by the Bologna Province though measurement on the field and the simulation with the strategic model VISUM as it was already calibrated for the area under analysis. The available data were flows and speed for each link of the network during the peak hour plus hourly measurements of vehicular flows and speed in the main roads (Via D’Agostino, Via Saffi, SS. Montanara). The average daily speed and flows profile has then been applied to all of the network links in order to obtain hourly flows and speed for all of the links.


36

The fleet vehicular composition has been derived by the national data available at ACI (Automobil Club d’Italia) and adapted taking into account of the percentage of heavy duty vehicles measured in the main roads. With this data a fleet composition definition compatible with the COPERT and TEE2004 vehicles classification has been prepared. ISHTAR modules used in the case study As the traffic data were already available at the Bologna Province, the suite entry point is the Direct Impact of Transport model TEE2004. Then the TEE output has been used by the pollutant dispersion model (ARIA IMPACT) and the noise model (SOUNDPLAN) in order to compare the environmental impacts of the three scenarios results. Emissions The CO, NOX, PM10 total emissions resulting from the TEE calculation in the morning and afternoon rush hours are shown in the next figures for a quick comparison among the scenarios.

emissioni di co nelle varie alternative di progetto al le ore 7

128.63 128.79

141.95

120.000

125.000

130.000

135.000

140.000

145.000

CO_alt5 CO_alt6 CO_def

emis_co

emissioni di co nelle varie alternative di progetto ore 17

142.45

149.85

175.89

120.00

130.00

140.00

150.00

160.00

170.00

180.00

CO_alt5 CO_alt6 CO_def

emis_co

emissioni di nox nelle varie alternative di progetto

alle ore 7

23,445 21,450

20,481

18,000

19,000

20,000

21,000

22,000

23,000

24,000

Nox_alt5 Nox_alt6 Nox_def

emis

sion

i (K

g/h)

emis_NOx

emissioni di nox nelle varie alternative di progetto ore 17

25.17

26.6029.16

23.00

24.00

25.00

26.00

27.00

28.00

29.00

30.00

Nox_alt5 Nox_alt6 Nox_def

emis

sion

i (kg

/h)

emis_nox

emissioni di pm10 nelle varie alternative di

progetto al le ore 7

0.761

0.837

0.746

0.700

0.720

0.740

0.760

0.780

0.800

0.820

0.840

0.860

PM10_alt5 PM10_alt6 PM10_def

emis_P M 10

emissioni di pm10 nelle varie alternative di progetto ore 17

0.80

0.78

0.88

0.70

0.75

0.80

0.85

0.90

PM10_alt5 PM10_alt6 PM10_def

emis

sion

i (kg

/h)

emis_pm10


37

As clearly shown by the figures above Alternative 5 presents the worst scenario in terms of emissions for all the pollutants. Also the below pictures representing the PM10 emission link by link show that Alternative 5 is worst also because the emission are concentrated in the central zone, with more buildings if compared with the Definitive Project.

Air Quality The punctual concentration provided by ARIA Impact on a grid with a step of 250 m have been transformed in pictures with isoconcentration curves by way of the program Transform, just in order to make them easy to read. As an example below we have reported the isoline concentration of CO without taking into account the background concentration (in order to improve the capability to catch the differences between the scenarios) at 5 pm for the Alternative 5 and the definitive Project. It must be taken into account that the two pictures have a different scale (ending at 390 for the Definitive Project while at 420 mcg/m3 for Alternative 5), the two blue lines represent the isoconcentration line at 300 mcg/m3. So that the alternative 5 has both a higher maximum value and a wider area with concentration higher than 300 mcg/m3 of CO.


38

Noise The noise propagation simulation performed by Soundplan on the bases of the noise emissions calculated by TEE2004 provides the noise levels during the day (Lden) and during the night (Lnight) on the loudest façade for each building. Soundplan requires as input, besides the noise emission levels, a detailed 3 dimensional map of the buildings and the population distribution among them (that can be made automatically by Soundplan on the basis of the number of inhabitants for a certain area). As an example the next page pictures show the noise levels (Lden) for Alternative 5 and the Definitive Project. Next table shows the average noise levels for the population for the three alternatives

Alternative 5 Alternative 6 Definitive Project Lden dB(A) 67.3 67.8 67 Lnight dB(A) 69.7 70.2 69.5

TheThe night levels are higher than the Lden because the morning rush hour, at 7, is included in the night time. In any case the definitive project presents the lowest values, allowing a reduction of noise exposure for the inhabitants (even if really slight if compared to alternative 5). Conclusion The Province of Bologna case study tested the three core tools of the suite integrated in the ISHTAR Suite. The case study was already run by the Province but with the tools not integrated, and the results were obviously similar, with a clear advantage for the Definitive Project. The three scenarios have been run using only the Ishtar Suite Interface. This test has been really useful for and the identification of bugs and necessary development and improvement of the integration SW. We expect to run also other tools based on this case study, in order to test the integration of the integration software for TEX, HIT, and the CBA. This will be done in a follow up demo project of ISHTAR.


39


40

4.1.3 Brussels case study Introduction After having observed the strong relationship between road traffic intensity and air pollutant concentrations, the Brussels Capital Region (BCR)2 has decided to prepare a set of traffic banning measures and suitable accompanying measures to be implemented when atmospheric conditions forecasts exceed some pollutant concentration thresholds. The aims of the case study are the following:

?? Analyse the pollutants concentrations records available for the in the Brussels area; ?? Design crisis scenarios with different severity degrees, these scenarios include the

possibility of banningsome vehicles categories of driving in the Brussels Region territory with the definition of a banned area;

?? Forecast the behaviour of the travellers facing the various scenarios, through preliminary surveys;

?? Design accompanying measures: parking provision at the border of the banned zone, intensified public transport services, … ;

?? Estimate traffic impacts estimated by mean of traffic models; ?? Estimate noise and pollutants emissions in the Brussels area through the ISHTAR models

suite with and without implementing the crisis scenarios.

The main objective was to test the feasibility and the efficiency of a Car Free Day in Brussels. Car free days were supposed to be part of a global ozone plan for the Brussels Capital region. Since the beginning of the "In town without my car!" event, the Brussels Capital Region has been participating. As a result, on average, noise was reduced by ten decibels; while the highest level of NOx emissions recorded at the city’s busiest traffic intersection was eight times lower than for a normal weekday. Car free days are really efficient to reduce pollutant concentrations like NOx, CO and particles but are useless for decreasing ozone levels in short-term. Until now, despite their success, the Car Free Days were planned only on Sundays to limit impacts on economic activities. It is clear that, if a Car Free Day had to take place a workday, some important accompanying measures would be necessary to avoid a mountain of protestations. This report will try to make a review of these particular measures and determine real impacts of such actions in terms of road traffic intensity and of emissions and concentrations of pollutants in the city. We will also compare measures regarding different factors such as measure implementation costs, environmental impacts or exposed population size. If the conclusions of the study were positives, public authorities would be encouraged to practice CFD also during the week. Study Two main characteristics are predominant in terms of pollutant emission:1) the vehicle registration year; 2) the fuel type. That’s the reason why scenarios have been constructed by considering Euro norms and registration years. The following five scenarios resumed in the following table have then been studied in order to test four traffic policies:

Scenarios Fleet composition year

Road traffic flows simulations

Banned vehicles

2 The Brussels Capital region will also be named later as BCA (Brussels capital area).


41

Light vehicles Trucks Buses & Coaches & Taxis & emergency and public services

vehicles

Reference 2002 2002 No No No

Euro 1 2002 2002 Euro 1 not conform

Euro 1 not conform

No


Euro 2 not conform

No


Euro 3 not conform

No

Diesel 2005 2002 Diesel No No

Tab. 4.1.3.1. Scenarios characteristics in terms of fleet and traffic features. Due to the growing importance of Diesel vehicle representation and its high potential impact on health (due to PM), the Diesel vehicles banning has also been studied. In each scenario, there were systematically exceptions for car prohibition. It was the case of public transport company, fire brigade, ambulance service, police force, electric or hybrid vehicles and LPG or natural gas vehicles,… To model the impact of banning measures, a survey has been performed to persons travelling by car as driver at some strategic places in Brussels. This survey has allowed forecasting required crisis car parks and modal choice. New trips matrix for transport models could then be built. The main results were:

?? in terms of transport: o 33 % of trips cancellation; o 51 % of modal shift (the regional public transport company & pedestrian mode); o 11% of measure infringement.

?? In terms of perception : Almost half of concerned people (47%) consider these actions as awkward or very awkward. However it is important to note that nearly 30% of the BCR (BCA) concerned people do not perceive any discomfort in case of car banning policies.

Before applying measures, it was necessary to determine suitable measures to limit impacts on economic factors and facing environmental crisis. The following aspects have been analyzed:

?? Definition of parking areas: crisis car parks were defined in the most strategic locations. Intermodal transfer facilities have been envisaged so that persons leaving their vehicles in the car parks could readily reach the city centre by public transport;

?? Public transport crisis plan: a public transport plan specifically adapted to a much higher demand has been defined;

?? Accompanying and monitoring measures: techniques making it possible to refuse infringing vehicles from accessing the Brussels-Capital Region (label and police or electronic control) as well as measures aiming to avoid problems for inhabitants of the approaches to the Region (restrictions on travel, channelling of vehicles towards crisis car parks), have been examined;

?? Plan of public information: in order that the crisis plan should be observed, it is necessary for the public to be informed about the measures adopted. Different means of communication have been analysed (television, radio, Internet, etc.).

?? Methods of co-ordination of the different players involved in the transition from a normal system to a crisis system: definition of the different players involved in the implementation of a crisis traffic plan and the procedure to be followed.

Thanks to survey data analysis, it was possible to model the effects of their behaviours on the Brussels Network (i.e. a construction of a new origin / destination matrix and affect this matrix on


42

the network). This matrix has been used in SATURN for personal vehicles and in TRIPS for public transports. Traffic simulation results characteristics (speed and flow of each link) were used as input for the traffic pollutant emissions model (MEET spreadsheet). The MEET spreadsheet allows the computation of the following pollutants : CO2; VOC; PM10; NOx; CO. It also allows the computation of the fuel amount consumption expressed as well in kg as in l. Simulations have been computed in order to differentiate the two main emission reduction factors, i.e.:

1 Vehicles amount reduction; 2 More environment-friendly fleet composition.

The following table summarises the modelled reduction of pollutant emissions for each scenario.

Emission reduction in comparison with the Reference scenario Euro 1 Euro 2 Euro 3 Diesel

CO2 -25% -35% -31% -29% CO -43% -49% -66% -21%

VOC -47% -60% -66% -53% NOx -35% -53% -68% -65%

PM10 -32% -61% -73% -82%

Tab.4.1.3.2. Scenarios pollutants reduction in comparison with the Reference scenario A GIS interface has been used in order to get pollutant emission maps. A first step in population exposure computation has been done through the computation of emissions values per km² related to the exposed population. Two types of population have been considered, the inhabitants and the commuters. The results show that the restriction measures (car banishment measures) have a favourable impact on exposure by putting more exposed population at a reduced pollution level. However, these results are a health/environmental indication but require the conversion of exposure emission to immission values (µg/m³) in order to compare the obtained values to WHO norms. It is worth in scenario analysis to be able to distinguish in the contribution of the main factors causing a pollutant emission decrease. The two main factors are the traffic reduction and the fleet technical characteristics improvement. For each of the pollutant the contribution of these two factors has been computed and the results are presented in the next table, computed mean values are presented.

Factors contribution CO2 (kg) CO (kg) VOC (kg) NOx (kg) PM10 (kg) Traffic 99% 85% 80% 70% 70%

Fleet characteristics 1% 15% 20% 30% 30%

Tab.4.1.3.3 Contribution of traffic and fleet characteristics in pollutant emission reduction. Conclusions The main conclusions are the following: Concerning the efficiency of the measure on the emissions reduction, the main conclusions are:

?? Each of the four scenarios has shown significant impact in terms of emission reduction; ?? The Greenhouse Gas Emissions reduction (CO2) was only due to the traffic flow reduction

but not to fleet specificities. Fleet technical characteristics have however a favourable impact on the others pollutant emissions;


43

?? The most efficient scenario was the EURO 3 scenario banning all EURO 3 not conformable vehicles. The results are linked to the traffic flow reduction as well as the fleet technical characteristics improvement due to the more severe norm;

?? The Diesel scenario has got a very significant impact in terms of PM10 emissions reduction. The reduction, in comparison with the Reference scenario is about 80%;

?? The fleet evolution has at least as much impact as the traffic banishment in itself. Concerning the data analysis, the utilisation of a GIS has been of great importance in terms of data representation. Concerning the feasibility of the traffic policy measure, several accompanying measures were required and have been studied:

?? parking areas definition, ?? public transport crisis plan development, ?? monitoring measures, ?? coordination measures, ?? information measures.

All these accompanying measures were feasible. Indeed due to modal shifts and tripcancellations as well as enforcement measures, dissuasion parkings availability, public transport offer were sufficient. As consequence, weekdays car free days can be organised punctually and do not require as it is presently the case in Brussels, the postponement of the European official Car Free Day (22/9) during the weekend.


44

4.1.4 Graz case study Description of the case study In the city of Graz the historically grown road network lacked in a certain region in a good connection between two major roads. This unsatisfactory situation led to an increased traffic load in residential areas between these two roads. In order to improve that situation a new connection was built in form of a cut and cover tunnel. As one of the portals of this tunnel is situated very close to residential buildings the concern about environmental impacts was very high. Therefore an environmental impact study was commissioned to prove the effects of this project are in accordance with the noise pollution and air quality standards. This new connection between two major roads was built in order to reduce the traffic load in residential areas. The main reason for this measure was the improvement of the situation within the residential area concerning:

?? Reducing the risk potential related to accidents

?? Reducing noise pollution

?? Improvement of the traffic situation concerning the connection of the main roads

The Road Tunnel

The Road Tunnel

?

The Road Tunnel

The Road Tunnel

?

Figure 4.1.4.1 : Location of the tunnel project and view of the east portal Collected data To perform the module application data is necessary concerning the geographical, traffic, environmental (air quality and noise pollution), and meteorological situations. These data have to be available for the before (the project) and the after (the project) situation. This required data has been collected during the course of the ISHTAR project, Traffic data is available for the whole network concerned by the measure. This measure concerns only a relatively small part of the total network. Due to the introduction of the new part of the road network an increase in vehicle mileage in the close surrounding of the project has been detected. This local increase is compensated by a reduction in mileage in the road network, mainly in the residential area and in some arterial roads. Noise measurements have been performed on specific places within the study area in March 1997 and March 2002 to define the “before” situation and in May and June 2002 to depict the “after” situation. Air pollution was monitored using two different methods. One was based on regulatory air quality monitoring using permanent monitoring equipment; the other one was based on passive sampling of single pollutants. As part of the air pollution control system in that area two permanent monitoring systems for NO2 and O3 are in operation since the opening of the tunnel.


45

ISHTAR modules used in the case study The Graz case study was never aimed at applying the full ISHTAR suite capabilities. The reason for that is that the Graz case study is a local scale application with little influence beyond the borders of the study area. The main objective of the “measure” was to calm down the traffic in a residential quarter and to improve the traffic connection between two parts of the city. Hence the impact on the traffic is restricted to a small part of the total street network. The impact on air quality is negligible – except at the kerb side locations. The only remarkable influence is expected to be on the noise side. In the framework of the ISHTAR project it was foreseen to use some modules of the ISHTAR suite to check the applicability of ISHTAR even for small scale applications. The modules used were the emission module TEE 2003 and the dispersion model ARIA impact. In addition the emission module was checked against the Austrian standard emission calculation tool (Handbook of Emission factors) and the dispersion tool against the GRAL model. The inter-comparison between the emission tools proved that with TEE2003 reliable emission estimates are to be expected. However, in order to achieve these good results it is necessary to adjust the fleet composition to the local situation and this needs some manpower and a good knowledge about the local fleet distribution. When considering the dispersion tools it has to be mentioned that the ISHTAR dispersion module (ARIA Impact) is neither designed to handle emissions from tunnel portals nor to consider complex terrain (buildings, noise barriers, etc.). Nevertheless, although knowing of these limitations the dispersion module was applied with some modifications (e.g. the portal emissions were treated as volume sources whose size was defined by the emission rate and a maximum concentration). In addition ARIA Impact was tested against measurement results from field experiments. Results The following figures show the results of the dispersion calculations using ARIA Impact and GRAL. As it can be seen the overall effect of the measure on air quality is not very high. There are no major changes at a first glance. Only if looking at direct differences (Errore. L'origine riferimento non è stata trovata.) the local effects can be depicted.

Figure 4.1.4.2: ARIA Impact model’s output visualising NOx dispersion episodes “before” (left) and “after” (right) situation

[µg/m³ ] [µg/m³ ]


46

Figure 4.1.4.3.: NOx dispersion episodes before (left side) and after (right side) situations calculated by the model GRAL

Figure 4.1.4.4.:: NOx difference between “before” and “after” situation calculated with GRAL (left side) and ARIA Impact (right side); the read shaded areas indicate an increase in NOx concentrations, the blue shade indicate a reduction. As shown both models result in the expected differences, an increase in the portal regions and a decrease in the residential area. The differences are more pronounced in the GRAL model as this model is more appropriate for such local scale applications. However, ARIA Impact is capable to deliver the main features of the “before” and “after” situation. The effects on noise are much more pronounced. This can be seen in for daytime and for night time situations.

[µg/m³] [µg/m³]

[µg/m³] [µg/m³] GRAL ARIA Impact


47

45

55

65

H.-Caspar ga. Canerig. 3rdfloor

Canerig. 8thfloor

Fischergasse Korösistr.

LA

eg(d

B)

Before operation After operation

45.0

50.0

55.0

60.0

65.0

70.0

H.-Casparga.

Canerig. 3rdfloor

Canerig. 8thfloor

Fischergasse Korösistr.

LA

eg(d

B)

Before operation After operation

Figure 4.1.4.5: Noise reduction achieved for daytime (left) and night time (right); note that the big reductions archived for the measuring locations Canerigasse are due to a noise barrier which was part of the project. The main effects of the measure on the noise pollution can be concluded as follows:

?? In the central part of the residential area a strong noise reduction was achieved due to the effective reduction of traffic.

?? At the boundaries of the study area no remarkable changes were achieved, this was to be expected.

?? The accompanying measures at the main arterial road lead to a very strong decrease in noise pollution. The traffic increase at that location due to the implementation of the measure does not counteract the benefits gained due to the noise barriers. The changes in traffic in the before and after case is not reflected in the noise measurements. The situation behaves stable.

Conclusion The Graz case study concerned a traffic calming measure for a residential district between two major roads in the north of the city of Graz. Due to the construction of a 600 m long tunnel the traffic - which was formerly directed through narrow streets within this residential district - can now bypass this area. Unfortunately one portal of the tunnel had to be situated in close vicinity to a housing area. To minimize the negative effects of the concentrated pollution exchange at the portal special measures have been implemented. These measures cover the erection of an up to 7 m high noise barrier and a special ventilation control at times with a high air pollution load. The effect of this improvement of the road network on the traffic flow within the city of Graz is relatively small. Hence only a few km of the road network had to be considered and the study domain covers some 2 times 2 km only. Effects on air quality are remarkably only directly at curb side. Effects on noise are much bigger. The measurement programme covered noise and air quality measurements “before” and “after” the opening of the tunnel. The noise measurements showed a remarkable reduction in noise levels in the residential areas – as the traffic load could be reduced dramatically at that locations – but also alongside the main road which bears now much more traffic. This reduction is related to the noise barrier which was part of the project. The changes in air quality can not easily be allocated to the project as the “before” and “after” measurements did not cover the same time of the year. The “after” measurements benefited also from the improved dispersion conditions during the measurement time (spring time vs. late winter time). However, there is an indication that air quality improved at least in the residential areas, while it didn’t grew worse alongside the east portal region of the tunnel, where much more traffic prevails due to the tunnel.


48

As the study domain (the effected area) is relatively small only modules of the ISHTAR suite were applied. A full ISHTAR suite application for such a small area and limited measure would not make any sense (e.g. there is no effect on monuments to be expected). Within this study the following the following ISHTAR tasks were performed:

?? Validation of the emission model TEE

?? Validation of the dispersion tool ARIA Impact

?? Application of TEE to the case study region

?? Application of the dispersion tool ARIA impact to the case study region

?? Comparison of the model results with other dispersion tools

The general conclusion for the tested ISHTAR suite modules is as following: The emission module (TEE) delivers reliable emission rates for calculations in street networks. The fleet composition has to be adjusted manually for each country and base year. The dispersion module ARIA Impact is designed for dispersion purposes in non-built up areas. It delivers reliable results for line sources. The model is not designed for special cases like tunnel portals and noise barriers. The general conclusion for the Graz test case is as follows: The measure was set in order to restrict traffic in a residential zone and divert it into a road tunnel. The positive effect of this measure was proven by noise and air quality measurements. Even in zones with a traffic increase an improvement in noise pollution could be achieved as noise barriers were included into the measure. The effect on air quality was also proven by application of dispersion models. The ISHTAR dispersion module ARIA Impact was able to show the general trend. The trend on the small scale (portal regions) was confirmed by application of more detailed models.


49

4.1.5 Grenoble case study Description of the case study The Grenoble case study, defined in 1999, concerned the impacts of measures for improving the traffic flow and supporting public transport. Hence, new traffic lights and reserved lanes for public transportation on very central boulevards were set in operation. The objective of these measures was:

?? to test the possibility of reducing the number of lanes dedicated to car traffic (from 6 to 4),

?? to improve the average speed of public transport,

?? to reduce car speeds, and monitor the impact on traffic flow.

Within the ISHTAR work the measure should have been assessed in terms of traffic, air pollution and noise. The objective of this ISHTAR case study was to compare the results of the simulations done with the modules of the ISHTAR suite to the measurements done before the project in 1999 and after in 2000. Figure 1 shows the study domain with a length of roughly 1 km and a width of some 100 m.

Figure 1 : Location of the domain of the Grenoble case study Collected data To perform the module application data are necessary concerning the geographical, traffic, environmental (air quality and noise pollution), and meteorological situation. These data have to be available for the before (the project) and the after (the project) situation. These required data has been collected during the course of the ISHTAR project for the before and after situation. Traffic data are available for the roads Joseph Vallier and Marechal Foch. These both roads are mainly concerned by the measure. The measure led to a traffic reduction of some 10%, accompanied by an average speed reduction in the same size. Unfortunately no information has been collected in other parts of the adjacent road network. Noise measurements were performed on two locations in April 1999 (before) and April 2000 (after the implementation). Figure 2 shows one of the two noise monitoring locations. Note that between the left hand side (1999) and the right hand side (2000) changes in the road design have been made.


50

Figure 2 : Location of one of the two noise monitoring locations (right hand side picture taken in 1999, left hand side picture taken in 2000)

Figure 3 : Results of the noise measurement at one location in 1999 and 2000 Figure 3 shows the results at one of the two locations. A reduction in noise level of ~1.5 dB(a) in average was archived. The second monitoring location showed no difference between the before and after situation. In order to check the influence on air quality a mobile monitoring station was installed in the eastern part of the domain. The western part is monitored by a permanent station. Unfortunately the monitoring in the eastern part lasted only for 14 days, which is much too short to sort out the influences due to changes in meteorological conditions. The station in the western part should give here more reliable data. In order to see the influence of a general trend in air pollution between the two monitoring periods January to June 1999 and January to June 2000 the data of a background station were used. Table 1 : NOx changes in air quality between 1999 and 2000 NOx (in µg/m3) given as NO2

permanent station (in canyon street at the western part of the

area)

reference station (background pollution)

mobile station (eastern part of

the area)

specific fortnight

January to June 2000

specific fortnight


April 1999 54,7 71,6 71,4 33,5 38.8

April 2000 50,5 56,3 65,5 30.6 36.0

variation - 8 % - 21,4 % - 8,3 % - 8,7 % - 7,2 %


51

Table 2 : PM10 changes in air quality between 1999 and 2000 PM 10 (in µg/m3)

permanent station (in canyon street at the western

part of the area)

reference station (background pollution)

mobile station (eastern part of

the area)

specific fortnight


specific fortnight


April 1999 30 27,6 27,7 20,3 21,2

April 2000 15 15,3 27,1 11,6 20,7

variation - 50 % - 44 % - 2 % - 43 % - 2 %

Following the results given in Table 1and Table 2 the recorded changes in air quality can not be devoted to the implementation of the measure. The changes in the long term as well as in the short term are more or less in the same order at the stations in the case study area as well as in the back ground station. ISHTAR modules used in the case study The following tools were used to assess the environmental impacts: Traffic no (manual input from DAVISUM results) GIS system SIG Geomedia transferred to ISHTAR-GIS Emissions TEE2003 (ISHTAR module), not adjusted to the French fleet Pollution dispersion ARIA Impact (ISHTAR module) Noise no (measurements available) Results The implementation of the measure (reserved lanes and improved traffic lights) led overall to a small reduction in emissions (~ 3% for CO, NOx and VOC). The effects on air quality have been calculated but could not be displayed due to software problems. However it can not be expected that the small changes in emissions in a restricted area will have a big impact on air quality. The monitoring programme concerned noise measurements at one locations and air quality at two locations. Referring to noise pollution a reduction of 2 dB(a) is reported for one part of the domain while in a second part no changes could be found. Referring to air quality a reduction of some 8% in NOx and up to 40% (!) in PM for short term and 2% in long term were found. The short term (14 days) reduction was definitely biased by the different general meteorological conditions between the monitored period in 1999 and 2000. The long term values (6 months) are much more reliable. 4.1.5.5 Conclusion The Grenoble case study concerned a measure which combined traffic management with an improvement to public transport. As the study domain (the effected area) is relatively small only modules of the ISHTAR suite were applied. A full ISHTAR suite application for such a small area and limited measure would not make any sense (e.g. there is no effect on monuments to be expected). Within this study the following ISHTAR modules were used:

?? the full ISHTAR interface as a module manager

?? the ISHTAR GIS module

?? the emission model TEE

?? the dispersion tool ARIA Impact


52

However, as only single modules of the ISHTAR suite have been applied at least the general trend of the changes due to the action could be followed in the emission calculation as well as in the monitoring values.


53

4.1.6 Paris case study

Case study description: “En Ville Sans Ma Voiture ” Every September 22nd, the City of Paris takes part in a car free day called “En Ville Sans Ma Voiture".

In 2002 and 2003, the experiment was implemented in the historical centre of Paris (area concerned: 3 x 2 km). Between 7 a.m. and 7 p.m., this central area was only accessible to public transport, taxis, “green” vehicles (LPG and electric cars) and professional users. The temporal and spatial scale of the experiment focus the assessment on the short-term road-side air quality impact. The background pollutant concentration, which is a regional parameter with strong weather dependence, sets the context. Airparif's experience prior to Ishtar has shown that the modelling tools must take into account detailed road geometry and traffic characteristics, in particular fleet composition and traffic congestion. The objective of the Ishtar case study was to test the enhancements to the modelling tools contained in the Ishtar suite. Simulation results Traffic, emission and dispersion of pollutants were estimated by modelisation. Traffic results The traffic data were measured by loop detectors. A running fleet composition in the central area is also available (e.g the proportion of two-wheelers and taxis increased in the central zone where other types of vehicles were banned). From these sources, Airparif's existing traffic model produces a coherent output for the car-free day in the central area. The outputs of our traffic model are hourly files with information about flux of


54

vehicles (number of vehicles by hour), mean speed (in km/h), capacity of the link (in veh./h), saturation rate (in %) and cold start estimation (in % of vehicles).

0

500

1000

1500

2000

2500

3000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

hours

Traf

ic

(veh

icle

s/ho

ur)

Monday 15th Sept.Monday 22th Sept.

Figure 4.1.6.1 Hourly traffic in Paris, comparison with the one week before situation: all Paris (left) and for the "Quai des Celestins" located in the central area (right). The traffic model estimates that the traffic decreases by 11.5 % in volume ( 13.1 million of veh.km vs. 14.8 one week before) over all Paris. The shortcoming of this estimation is that to some extent it extrapolates the traffic change in the central area to the surrounding boulevards, while in reality these are more congested than normal during the traffic ban. During the ISHTAR project, a first assessment was made with the VISUPOLIS traffic model. VISUPOLIS uses hourly origin-destination matrices which conserve the total traffic volume. Figure 2 gives an estimation of saturation and shows that congestion shifts from the centre to surrounding Boulevards.

Figure 4.1.6.2 Differences in degree of saturation (Vol/Cap): Base Case 2001 data (left) and Car-free without modal shift (right) Emission results Impacts on emission were estimated by our model. This model is based on COPERT 3 methodology and can provide emissions for 6 pollutants (NOx, CO, COV, SO2, PM and CO2) on each traffic link.


55

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

hours

NO

x (e

mis

sio

n in

to

ns/

ho

ur)


0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

1 2 3 4 5 6 7 8 9 1 0 11 12 1 3 14 15 16 17 18 19 20 21 22 23 24

hours

NO

x em

issi

on

(

kg/k

m)


Figure 4.1.6.3 Hourly emission of NOx in Paris, comparison with the one week before situation: all Paris (left) and for the "Quai des Celestins" (right). Global Assessment given by simulation a decrease of 13.6 % in emission of NOx ( 12.7 tons of NOx vs. 14.7 one week before). Air quality results The car free day impacts directly on the concentration of pollutants in the central area. For example, the concentration of NO2 measured at "Quai des Célestins" monitoring station strongly decreased

compared with the one week before situation, and reached the background concentration of pollutants over Paris.

0

20

40

60

80

100

120

140

160

180

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Hours

[NO

2]

CE

LE

ST

IN (

µg/m

3)

Monday 15th Sept.Monday 22th Sept.Background 22th Sept.

Figure 4.1.6.4 Roadside NO2 concentration "Quai des Célestins" monitoring station : comparison with the one week before situation (in blue) and the car free day situation. During the ISHTAR project, a first assessment was made with the Aria Impact dispersion model. Figure 5 gives a first estimate of concentration at the Champs-Elysées monitoring station.

Figure 4.1.6.5 Roadside concentration Champs-Elysées monitoring station : concentration calculated by Aria Impact (in blue) and measured (in red)


56

Conclusion We have described here our case study. The Ishtar project has given us the opportunity to make a first assessment of traffic simulation in congestion with a new tool called Visupolis. We also tested a new dispersion model (Aria Impact). Globally, an evaluation of Car Free Day 2003 impact on Air Quality in the central area could be estimated ~ 60 % in decrease for the roadside pollution. On the boulevards where the enhanced traffic model points to increased congestion, a further examination of roadside pollution with detailed consideration of fleet composition and road geometry will hopefully be possible in the near future.

0

20

40

60

80

100

120

140

160

20/0

7/20

04

20/0

7/20

04

21/0

7/20

04

22/0

7/20

04

23/0

7/20

04

24/0

7/20

04

25/0

7/20

04

26/0

7/20

04

27/0

7/20

04

28/0

7/20

04

29/0

7/20

04

30/0

7/20

04

31/0

7/20

04

31/0

7/20

04

01/0

8/20

04

02/0

8/20

04

03/0

8/20

04

04/0

8/20

04

05/0

8/20

04

06/0

8/20

04

07/0

8/20

04

08/0

8/20

04

09/0

8/20

04

10/0

8/20

04

11/0

8/20

04

11/0

8/20

04

12/0

8/20

04

13/0

8/20

04

14/0

8/20

04

15/0

8/20

04

16/0

8/20

04

17/0

8/20

04

[NO

2] (µ

g/m

3)

MEASUREMENTS

ARIA Impact


57

4.1.7 Rome case study Case study description

The increased numbers of private cars in Rome have resulted in increased traffic congestion and atmospheric pollution. The city of Rome has established various strategies to tackle traffic problems implementing a framework to rebalance the modal split towards public transport and promote alternative means of transport.

An access restriction for non-catalysed vehicles has been implemented within the “Rail Ring”. The “Rail Ring” area, which surrounds the historic centre, is densely populated with a high concentration of activities making it one of the key areas in the city for intervention to lower emissions caused by motorized vehicles.

The City Council, in order to reduce polluting emissions caused by motorized vehicles in the centre of the city and to speed up the fleet renewal rate, decided (D.G. 790/2001) to phase in traffic restrictions within the “Rail Ring” as follows:

?? diesel motor vehicles registered in accordance with directives prior to EC 91/441 to be banned from the area inside the ““Rail Ring”” as of 1 January 2002;

?? petrol motor vehicles registered in accordance with directives prior to EC 91/441 to be banned from the area inside the “Rail Ring” as of 1 July 2002;

?? residents living within the “Rail Ring” may continue to use vehicles in the above categories until 31 December 2002.

This provision also exempted goods vehicles and specific categories of vehicles and road users. These measures had as their main effect a change in the fleet composition and no effects were expected on traffic flows.

A simulation of the ISHTAR suite was prepared to test the input-output connections among different software of the suite, data exchange with external software, modelling factors, and clarity of output comprehension. The analysis carried on is based on a comparison between two simulated scenarios:

1) Do nothing scenario; 2) Actual scenario (based on the traffic measures described above).

The ISHTAR suite ran the simulated case study with the following modules:

1. Emission; 2. Dispersion; 3. Exposure; 4. Health effects.

Pollutants modelled both by the Emission and Dispersion modules were CO and PM10. CO was also modelled by the exposure module and PM10 by the Health effects module. Area under investigation The Rome case study involves the “Heaven” area within the internal rail-ring (cfr. Fig. 4.1.7.1), excluding the Rome “ZTL” (Limited Traffic zone) that covers part of the historical center. The laboratory area of ISHTAR Project Rome Case Study has a surface of 16.35 square kilometres (see Tab. 4.1.7.1).


58

This area represents a “bridge” between the historical Centre and the peripheral North-Est areas, covering the second municipality and part of the third one. The socio-economic status of the population is particularly high and there is a big flow of traffic going through the area, mainly through the Roman consular streets Nomentana and Salaria, but also through some primary streets such as viale Regina Margherita and corso Trieste. The Area under consideration is inside the ‘Rail Ring’ in the NE central Rome, and contains three Consolari (main roads): Nomentana, Salaria e Flaminia,. Boundaries: (NE) Olimpica and Tangenziale, (S) Muro Torto, (W) Lungotevere, (N) Stadio Olimpico, Stadio Flaminio. Green areas: Villa Borghese e Villa Ada (where there is an air quality monitoring station).

Fig. 4.1.7.1 - Rome: “Heaven” area in detail

Characteristics Rome Investigated area Total area (km2) 1285 16.35 Population 2.750.000 290.000 Population projection 2010 2.600.000 274.000

Tab. 4.1.7.1 - Characteristics of the area under investigation

Data collection

Various data were collected in order to carry out the city case study.

?? Meteorological data: The meteo data used were measured by the Villa Ada Air Pollution Monitoring Station on the 12th November 2001. The temperature measured ranged between 13,9° C and 19,1° C with an average of 16,7° C. The main wind direction was from the northern sector, with an average speed of about 0,57 m/s (max 0,76, min 0,36) with no rain (data provided by STA).

?? Traffic data: The Origin-Destination Matrices (O/D) used in the traffic simulation phase, with the static assignment model TRANSCAD, are based on the data obtained by the National Statistical Institute (ISTAT) census. An update, with the aim of defining more realistic traffic values has been carried out by STA by means of 40,000 telephone interviews and this made possible the evaluation on the daily car and motorcycle O/D matrices. STA provided traffic data as traffic flows and speed, specified for main roads and some secondary roads, working week days, six day-time period (0-6.59; 7.-9.59; 10-13.59; 14-16.59 ; 17-19.59 ; 20-23.59).


59

?? Fleet Composition: The fleet composition is defined in accordance with ACI (Italian Automobile Club) traffic surveys and extrapolations and it is updated annually; in our simulation we used the 2000, 2001, and 2002 fleet composition data, available since 1/3/2003. Vehicle classes, year of the vehicles, motorisation, fuel typology, etc., are available for vehicles circulating in the Rome Province. The total traffic flow is high on the main links and also on some secondary ones (see Fig 4.1.7.2).

Fig. 4.1.7.2 - Total traffic flows

?? Population: Population data include: registered residents in the area in the year 1999, split by gender and age; registered residents in the area in the year 2000; working people (“addetti”) in the 1991. Population data are represented at the level of census zone.

Fig. 4.1.7.3 - Resident population in year 2000


60

Pollutants emissions

Taking into account the traffic data (flows and speeds along all the links) calculated by TRANSCAD, the direct impact model Transport Energy & Environment (TEE) software has been used for the calculation of CO and PM10 emissions. The other direct impacts that TEE is able to simulate, noise and accidents were not calculated as the measure does not affect speeds and flows.

The aggregated result of TEE during the simulation day shows the reduction of CO of about 50%, in terms of emissions, confirms the validity of the adoption of the catalyst system regarding such kind of pollution.

Regarding the Particulate Matter with diameter below 10 micrometer the emission reduction is about 18 percent. (see Tab. 4.1.7.2 and Fig. 4.1.7.4).

CO (Kg/day) PM10 (Kg/day)

Do nothing 19837 45

Actual 10502 37

% of reduction 47 % 17,8 %

Tab.4.1.7.2 - TEE: emissions for the two considered scenarios

Fig.4.1.7.4 - Emissions in the two scenarios (red = do nothing; yellow = actual)


61

Pollutants concentrations

Pollutant concentrations, the 12th of November 2001, have been calculated for CO and PM10 with the gaussian dispersion model ARIA IMPACT (by Aria Tecnologies) taking into account the emission data calculated by TEE, the measured meteorological data, the topography and the background measured by the Villa Ada monitoring station.

The pollutant concentrations due to the emission within the Heaven area are almost negligible, as the area is quite small and surrounded by the city, in fact the concentration increase due to the calculated emissions coming from the road traffic, compared to the background is about 2,5 % for PM10 and 10 % for CO. In any case the difference in terms of concentration between the two scenarios is 0,33 % for PM10 and 4,76 % for CO (see Tab. 4.1.7.3 and Fig. 4.1.7.5).

PM10 (µg/m3) Scenario Daily average

Average in the whole area Do Nothing 30,17

Average in the whole area Actual 30,07

% of reduction 0,33

Background 29,36

CO (µg/m3) Scenario Daily average

Average in the whole area Do Nothing 657,15

Average in the whole area Actual 625,89

% of reduction 4,76

background 574,02

Tab. 4.1.7.3 – modelled dispersion for the two considered scenarios


62

Fig.4.1.7.5 - PM10 concentrations (red = do nothing; yellow = actual)

Exposure evaluation

Assessing exposure to a pollutant requires information on the pollutant concentration at a considered location and the duration of contact with individuals or population groups. When the concentration of a pollutant to which a person is exposed can be measured or modelled, exposure is determined from concentration and time spent in contact with the pollutant. After running the ARIA modelling in ISHTAR it is possible to calculate the assessment of exposure of people to a pollutant through a specific dedicated software, TEX (Traffic EXposure measurements).

Fig. 4.1.7.6 - Exposure simulation output The dispersion values considered for an exposure assessment cover the period of one day (the model refers to the 12th November 2001). The data, obtained from a Transcad output produced by the STA, were considered as an hourly series from midnight to midnight. As time activity (TAP) were not available, they were not considered. As expected, results indicate a stronger exposure of the people living and working on the main arterial network but also some area of high exposure of CO with low population concentration and some areas with lower level of exposure with high population concentrations (see Fig.4.1.7.6).

Health effects simulation

While the exposure output, if all inputs are available, offer an evaluation of the relation between a spatial dispersion of a pollutant and the distribution of the population, the application of dose-response curves happens at a broader approximate level. In fact, as it is well-known to assess the effects of a particular pollutant, in our case of ambient PM10 pollution, over an exposed population, there are two assumptions to be made: the concentration consists of the average measured in the city or area where the population live, everyone is assumed to be exposed to the same average concentration. With this information it is possible to calculate the attributable risk as a proportion, while to obtain the absolute number of attributable cases it is necessary to know, in addition, the observed rates of disease or mortality occurrence in the population under study. Within the ISHTAR suite is included the HIT software, designed to assess the impacts of different sources of


63

traffic-generated pollutants. The estimation of health impacts is possible by applying dose-response curves made available through the analysis of available literature. In the case under investigation the impact of the average value estimated for the PM10 was simulated as if it was an yearly average affecting the whole resident population. Total mortality was chosen as health end-point, both for the do nothing and actual scenarios. Concentrations greater than 20, considering an average of 30 produces a long term effect in terms of estimated number of excess cases of 337 (95% CI =110-558) and short term effects as 27 (95% CI = 23-32). Estimates are not only intended as “impact” on health, but ideally as “gains” or benefits that would be achieved by reducing average concentrations. Conclusions

Two traffic scenarios were tested in an area of the municipality of Rome. Pollutant concentrations data of a day, the 12th of November 2001, have been calculated for CO and PM10 within a semi-central area. Traffic data from O/D matrices were elaborated by a software external to the ISHTAR suite. A simulation of the ISHTAR suite was operated through the use of several software parts of the suite, in particular, as no effect were expected in terms of traffic flows, the model for the simulation of citizen behaviour and traffic have not been used, and, as no effects are expected also in terms of noise and accident, the Suite Entry Point was the direct impacts model for the calculation of pollutant emissions. The data obtained for the testing area of Rome are not indicative, due to some exceptional parameters, but were suitable for a simulation in ISHTAR. CO and PM10 were chosen and modelled, their emissions within the area under analysis have been modelled and used as input for the dispersion model. The PM10 dispersion modelling output were used to generate an exposure and health effects assessment. The simulation gave a negligible difference between the two scenarios in terms of health impacts of the tested policy. Synthetically, it has to be stressed that these results are a simulation of the behaviour of a population assumed as resident all year long in the investigated area and constantly exposed to an average level of pollution. The reality is much more complex and the results have to be carefully interpreted as a rough assessment of the real situation. The very low difference between the scenarios and between the scenarios and the background can be explained with the small dimensions of the area under analisys, that is strongly affected by the surroundings, the pollutant sources that have not been modelled. At the end of the simulation the Emission, Dispersion, Exposure and Health effects models within the ISHTAR suite were used. The part of the ISHTAR suite used in this simulated case study support the possibility of analysing different scenarios and organize data in an integrated way.


64

4.2 Application conclusions The main objectives of the case studies were to:

?? demonstrate the applicability of the ISHTAR suite or modules of it ?? validate the “before” and “after” situation ?? evaluate the “measure” set in the various regions/cities

The case studies proved to be an excellent opportunity to test the applicability of the ISHTAR suite either as a whole or its individual modules. Due to a delay in the development of the ISHTAR software, some problems for the application of the whole suite occurred. Therefore, it was necessary for some cities to run individual modules instead of the whole suite. But this gave the opportunity to check the quality of the individual modules by inter-comparison with other software tools. In the case study of Attica/Athens it was possible to show the positive and negative aspects of the erection of a new highway. One major issue that has to be noted, is that with the operation of the highway, (after case study analysis), 250.000 vehicles travel in Attica Road at an average of 15 km per trip, meaning (250.000 veh x 15 km) 3.750.000 vehxkm daily. All of these vehicles are now in the highway, providing a major relief to the local network of 3.750.000 vehxkm daily. In the case study for Bologna/Imola it could be shown that with the help of ISHTAR suite modules three out of nine alternative routes were chosen for further considerations as those routes showed the minimum negative and maximum positive effects on the environment. The case study of Brussels dealt with different vehicle restriction scenarios concerning the emission standard of the vehicles. It could be shown that with the help of the proper traffic and emission model useful information can be gained. The Graz case study showed that even if only small improvements in infrastructure are to be considered improvements on a local scale can be achieved. In addition inter-comparisons between different emission and dispersion modules showed the appropriateness of the ISHTAR suite modules and their limitations. The Grenoble case study applied the ISHTAR suite interface as manager for the module application. Although problems with the software occurred and hindered a full application of the emission and dispersion module it was possible to show as output that at least the same trends were gained by running the modules as were observed by the measurements. The case study of Paris included the densest road network. The Ishtar project gave the opportunity to make a first assessment of traffic simulation in congestion with a new tool, called Visupolis. In addition a new dispersion model (Aria Impact) was tested. With these tools an evaluation of the Car Free Day 2003 and its impact on Air Quality in the central area of Paris was performed. A 60 % decrease in roadside pollution could be estimated. The case study of Rome proved to be the most comprehensive in terms of application of the ISHTAR suite models. Two traffic scenarios were tested in an area of the municipality of Rome. A simulation of the ISHTAR suite was operated through the use of several software parts of the suite. In particular, as no effect were expected in terms of traffic flows, the model for the simulation of citizen behaviour and traffic have not been used, and, as no effects are expected also in terms of noise and accident, the Suite Entry Point was the direct impacts model for the calculation of pollutant emissions. The part of the ISHTAR suite used in the Rome case study support the possibility of analysing different scenarios and organize data in an integrated way. The modules for effects on monuments and the CBA were not applied in the case studies. However, tests were performed in the framework of the single workpackages. In general it can be concluded, that the case studies proved the applicability of the ISHTAR suite as a whole or its single modules. Hence, it can be concluded that ISHTAR can successfully be used in order to estimate the positive and negative effects of measures set in order to improve the air quality in urban areas.


65

PART V – Conclusions

5.1 Achievements of objectives In terms of scientific results it can be stated that the ISHTAR Consortium has substantially achieved all the objectives that were planned in the DOW. Difficulties were met due to the complexity of the Suite in terms of integration software development, that has delayed the Suite application to the case studies and the realization of the Suite Interface, even with the ten months Project extension. Anyway the Suite has been produced and tested either as a whole integrated tool or through some of its modules. In more specific terms the achievements in each work packages can be summarised as follows: The Cellular Transport Methodology The Cellular Transport Methodology (CTM) is a completely new software tool developed by ISIS (Italy) that simulates the effects of policies and measures on the behaviour of citizens in terms of movements, mainly producing the modified Origin-Destination matrices. This tool is considered as an ‘ancillary element’ of the suite because it is likely that the city teams wishing to use the ISHTAR software will already have a ‘mobility demand model’ or alternative techniques for estimating the modification of the trip matrices. The Transport toolbox After an analysis of the available transport models, the VISUPOLIS model has been described as the best tool to integrate within the suite. This model, rather recent, has been developed by PTV (Germany) integrating VISUM and the innovative tool ‘Metropolis’ by Prof. A. De Palma from the University of Clergy Pontoise (F). However the potential users are free to continue to use their own traffic model (as most of the cities participating in ISHTAR Project). VISUPOLIS is going to be tested in the Paris case study. It is likely that a significant fraction of the future users of the suite will use the PTV software, while the majority of the user will have their own traffic model and will have to export the related output into the ISHTAR database. The Transport Direct impacts module The direct impact model chosen for the suite is TEE2004, developed by ENEA and ASTRAN (Italy). This tool is particularly flexible in terms of space and time, includes advanced modelling of kinematics and cold start effects on the emissions, and feeds several downstream suite elements by calculating the emissions of pollutants and noise and the occurrence of accidents. This tool is compatible with most of the traffic models output. In fact the large number of options about the description of vehicle kinematics, the definition of the local fleet at link level and the approach for estimating the fraction of cold vehicles should guarantee an easy coupling between TEE2004 and the upstream used traffic model. Noise propagation and pollutants dispersion module The pollutants dispersion can be calculated with one of the two tools provided by ARIA Technologies depending on the spatial and time scale. For urban scale and long term analysis the suite will rely on ARIA Impacts, while for meso scale and short term events ARIA Regional will be the future reference, not yet fully integrated in the suite. For the noise propagation the Soundplan software (by Braunstein & Berndt GmbH, Germany) has been integrated within the Suite. These software tools operate on a common and harmonised set of input data needed for representing the dispersion processes.


66

Exposure and Impacts on Health module For assessing population exposure to pollutants and noise, a completely new software denominated TEX (Transport Exposure) has been developed by WHO (ECEH office in Rome). Such a tool provides exposure of population groups in their residential areas or along the trips in the city network. The evaluation of the health risk related to the exposure to pollutants, noise and accidents is run with the H.I.T. software, also developed by WHO. This tools provides estimates of life years lost due to the effects of air pollution, noise annoyance and accidents effects. Impacts on monuments The air pollutants impact on monuments is simulated by a software purposely developed for ISHTAR by ENEA (Italy) and PHAOS (Greece). This software named MODA (Monuments Damage) can assess the loss of material or the deposition of crust and the money needed for maintenance. This module receives information from the air pollution software and gives useful output data to the module for the overall evaluation of the scenarios. The model can provide estimates of damage for specific monuments or for types of monuments and buildings. Overall scenarios analysis tool For the overall analysis of the policy scenarios two methodologies and software pieces are available: the Cost-Benefit Analysis and the Multi-Criteria Analysis. These tools gather the data from the upstream models (following the required aggregations) and give the results of the comparison of the scenarios developed. In any case the MCA takes into account the results of the CBA. Both of them are developed by TRaC – LMU (UK). This module needs the availability of a commercial software called LDW. Software Integration As important as the previous tools is the software developed by INRETS (F) for integrating the various tools in a Suite. The integration is made by a Software Manager that launches the so called ‘software connectors’. The connectors are pieces of software that upload the data needed by the single tool in the appropriate format, launches the tool and then downloads the results of the run in the ISHTAR Suite Database making them available for other tools or for the output through the Geographic Information System (ARCGIS) used for managing geographic data. Case Studies The suite has been tested with the following seven case studies involving the ISHTAR cities: The Athens case study ‘Attiki Odos’ addresses the new roadway construction, Attica Periphery Road, which is assessed in terms of traffic, toll strategy and pricing, and environmental impacts. The Bologna Provincial Authority case study concerns the evaluation of infrastructure scenarios for the city of Imola with reference of alternative road paths. The aim of the Belgian case study is to prepare the implementation of traffic banning measures in the Brussels area, according to the Plan Ozone of the Federal Government. In the Brussels case study the focus is on the population behaviour, the modelling of traffic flows and the effects of the measure on pollutant emissions. The Graz case study is based on the traffic and noise impact evaluation of a 600 m long new road tunnel causing a relevant local traffic rerouting. Grenoble case study is intended to monitor the effects of the installation of reserved lanes for public transportation and new traffic lights on boulevards with heavy traffic. The focus in this case is on traffic and emissions. Every September 22nd the city of Paris takes part in a car free day. This typical short term event has been modelled with the ISHTAR suite of modules. For this case the usage of the new traffic model Visupolis is planned. The results include emissions of pollutants and air pollution. The Rome large scale case study involves the Heaven Project area banning to the more polluting vehicles. In the northern part of the city centre a number of models of the suite have been used, from the locally available traffic model (Transcad) to the Overall Evaluation module.


67

5.2 Exploitation Plans Since MTA in January 2003, partners started to discuss concretely the needed exploitation strategy. This process has lead to the definition of an agreement among the partners (the ‘Software Agreement’) i.e. a document signed by Partners and External software providers in order to have preliminary definition of rights and duties of software provision, use, and future marketing, and allowing the participation as ENEA subcontractors of such External Organisations, namely PTV and B&B both in Germany. The final version considers three time windows a) During the project duration, when the suite has to be built and tested with the seven case studies, the sw providers agreed to provide their tools and assistance to the project partners. b) a post project pre-commercialization phase when (some) partners expect to further test and improve the tool before marketing (expected duration 1 year along which sw providers guarantee correction of evident errors identified by partners) c) a marketing phase, to be managed by the members of the Exploitation Task Force and starting with the signature of another key document : the Agreement on the Marketing of the ISHTAR Suite – AMIS) An ENEA spin-off project for the creation of new Advanced Technology Based Firms (see www.consorzioimpat.it – IMPAT proposal) based on the development and marketing of decision support tools (such as the ISHTAR suite) has been approved and funded by the Italian Ministry of Industry, and is now in the incubation phase. This initiative will very probably lead to the creation of an Italian SME that could be the first legal entity having agreements with ISHTAR software providers and rights/duties for marketing the suite either in terms of providing a full apckage or in terms of selling services of calculation based on the use of the suite. The application of the ISHTAR suite to the main Italian Metropolitan areas, in order to assess the users capability to run the tool and identify and eliminate possible further software bugs, is the objective of a Project under definition by ENEA and APAT (Italian National Agency for the Environment Protection). This initiative is intended to involve interested ministries as sponsors or co-funders. Most of the ISHTAR sw providers have already confirmed their interest in this initiative that could start the workby the end of 2005. ISHTAR Partners are also considering the possibility of creating an European Economic Interest Group , based on Council Regulation (EEC) n. 2137/85 of 25-07-1985

5.3 Recommendations and Further Work Even if the ISHTAR Project represented a very challenging Project for its multidisciplinary approach and its level of integration of different decision support software tools it has shown one of its limits in the modelling of just the urban area. Withouttaking in to account pollutant emitted outside the city boundaries we lose the very high contribution to the urban air pollution due to the background values coming from the industries, agriculture, other cities and so on. In this direction the ISHTAR Consortium identified the need of a ‘regional simulator’ as essential for a better understanding of air pollution in cities, but also for the exposure to air pollution.In fact the phenomenon of urban sprawl causes difficulties in assessing exposure, as compared to the city centres there are always less inhabitants while the number of commuters is continuously rising. For improving the simulation of air pollution the need of a better simulation of other sources within the city is also required in particular the residential emissions. Another limit, or better, another possible improvement, could be the simulation of combined exposure. It would be interesting to study the interactions of exposure to air and water pollutants, food contaminants, EM sources (non ionising radiations) and Radioactive sources (ionising radiations) with an integrated methodology.


68

PART VI : References [1] Negrenti, E. et al. : ISHTAR Project Proposal to EC DG RES (Issued by ENEA as Project Coordinator), p. 1-99 , 2000 [2] Negrenti, E. et al : ISHTAR Contract EVK4 CT-00034 (issued in Brussels by EC DG RES) p. 1-xx , 2001 [3] Negrenti E. et al. : ISHTAR web site : http://www.ishtar-fp5-eu.com , 2002 [4] Negrenti, E and Hoglund P. ‘ISHTAR : an Integrated Models Suite for Sustainable Regional and Town Planning – Cities of Tomorrow Conference – Goteborg (S) – 23-24 August 2001 [5] Negrenti, E. ‘ISHTAR Project : Building a Model Suite for Urban Sustainability - 21st ARRB/11th REAAA Conference ‘TRANSPORT - our highway to a sustainable future’ – Cairns – 18-23 May 2003 [6] Negrenti, E. Agostini, A. ‘ISHTAR’ : ‘integrated software for health, transport efficiency and artistic heritage recovery’ ‘Transport and Air Pollution conference – Boulder (CO), September 2004


69

Appendices


70

App1 : ISHTAR Flow Chart

??Broken line block is the input data into module. ??Solid line block is the input data from other

modules.

??Broken line block is the GIS information input to the module.

??Solid line block is the output data to other modules.

?? GIS information

- Geography: Zone description (as traffic zone attribute) (per traffic zone)- provided by GIS user (S)

- Geography: Zone: id (as traffic zone attribute) (traffic zone attribute)(per traffic zone) provided by GIS user (E)

- Geography: Zone: Distance between centriod zones (i,j) [km] (per traffic zone) - provided by GIS user (S)

Pollution Emission& Energy Consumption (WP3) ??Time: duration of peak period and all day-time

periods (per day time period and per day type) [hour]

Pollution Dispersion (WP4)

?? WP User (S)

- General data: case study: Number of the modes in the case study [number]

- Cost: Average travel cost between zones (by mode, by time period) [€]

- Population: age stratification (per traffic zone) [%]

- Population: employed (per traffic zone) [n. of persons]

- Population: percentage with full time/part time job (urban area) [%]

- Population: Resident (per traffic zone) [n. of persons]

- Population: Activity description, number of activity status considered in the case study [n. of activities]

- Time: duration of peak period and all day-time periods (per day time period and per day type) [hour]

- Time: Number of day-time periods (NDTP) [number]

- Trips: Distribution of not systematic movement on 24 hours(per hour, per traffic zone)[%]

- Trip: Matrix of O/D trips between zones (i,j) at the peak period (per traffic zone)

- Trip: Mode description - Trip: Number of trip purposes considered

- Trip: Purpose description - Trip: Time of travel between zones and

mode (i,j,m) [Minutes]

- Total daily movement of population (not systematic) (pre day, per network) [trips number]

?? WP User (E)

- Geography: Zone: number of traffic zones (per network)

??Population: present (per hour, per traffic zone) [n. of persons]

ISM (WP8) Health Impact (WP6) ?? Time: Day category [number] ??Population: present (per hour, per traffic zone) [n.

of persons] ??Population: age stratification (per traffic zone) [%]

ISM (WP8)

Cellular Transport

Module (CTM) (WP#1)

??Geography: Zone: id (as traffic zone attribute) (traffic zone attribute)(per traffic zone) provided by GIS user (E)

??Geography: Zone: number of traffic zones (per network)

??Time: duration of peak period and all day-time periods (per day time period and per day type) [hour]


71

NOTE:

M information relevant METROPOLIS S information relevant SATURN V information relevant VISUPOLIS

??Broken line block is the input data into module.

??Solid line block is the input data from other modules.

Vertical broken arrow represents output data from the previous module input to

the module.



Policies/Actions

(WP1)

??General data: output: Daily traffic profile [PCU/h] (optional with WP2 user input)


??Trips: O/D Matrices (per hour, per persons) (optional with IS user Input)

?? GIS information

?? Geography: Centriod of traffic zones-

coordinates (as attribute of traffic zones)-provided by GIS user

?? Geography: Node coordinate (as node attribute)- provided by WP2 user (S)

?? Geography: Node: id. number (as node attribute)- provided by WP2 user (E)

?? Geography: Node: Type of junction ?? Link: traffic signal cycle total time (as link

attribute) [sec.] -provided by WP2 user (E) (also go to WP3)

?? Link: traffic signal Green [%], flow [veh./h], Length [km], Speed limit [km/h](as link attribute)-provided by WP2 user (E) (also go to WP3)

?? Link: Saturation flow [PCU /h] (as link attribute)-provided by WP2 user (S)

Pollution Dispersion (WP4) ??Geometry: Geometry for ARIA Impact (as

GIS information) (optional with input fromWP4 user)

??Kinematics: secondary stops [number of Stop/h]S

??Link: Link flow by Traffic Model Vehicle Group [veh./h]

Health Impact (WP6)

?? IS User (I)

- Trips: O/D Matrices (per hour, per

persons)] (optional with WP1)

?? WP User (S)

- Cost: Earlier arrival penalty (Beta)[€/h] - Cost: Arrival time expected cost [€]V - Cost: Departure time choice [€]M - Cost: Distance [€/km] V - Cost: Late arrival penalty(gamma)[€/h]M - Cost: Value of time (travel time & schdule

delay costs) (alpha) [€/h] M - Kinematics: Speed-flow curves [km/h and

veh./h] - Link Type for traffic models (code) - Link: Turn data: Lanes available S, Priority

rules S, Saturation flow[veh./h]S - Population: Behavioural factors (default

values provided) - Trips: Mode choice

?? WP User (E)

- Fleet: Number of traffic model vehicles Groups (NTMVG) M, S

- Fleet: Code of vehicle group for each vehicle microcategory

- Link id. Number (per link), Lanes number [number] (also go to WP3)

- General data: output: Dairy traffic profile [PCU/h] (optional with WP1)

??Link: travel time (for the exposure model)

[hour] ??Population: Travelling (n. of persons)

ISM (WP8) Overall Analysis (WP9) ?? Time: Day category [number] ?? Trips: O/D Matrices (per hour, per persons)

(optional with WP1)

??MCA indicator: Tram/light rail passenger numbers (per year, per scenario) [Numbers of person] (It’s optional, if it’s from multimodel, it will go to WP9)

??Trips: annual traffic flow per link [Pcu] ??Trips: Travel time [pcu.h]

to be identified the destination

Transport Module

(WP#2)

??Population: Number of users arriving too late, on time, too early (n. of persons)


72


modules.

Vertical broken arrow represents output data from the previous module input to

the module.



Transport Module

(WP2)

??Kinematics- Speed Cycle (per link) (optional with WP3 user input)

??Kinematics-Speed Cycle Information(per link) ??Kinematics - Primary stops [n. of Stop/h] ??Link: Link flow by Traffic Model Vehicle Group

[veh./h] ??Link: Cold start info: cold [%] ??Link: Cold start info: driven distance [km] ??Link id. Number (per link), Lanes number [number] ??Trips: Driven distance from the origin to the given

link (per hour, per link) [km]

GIS information

?? Kinematics - average speed along the link (as

link attribute)[km/h]-provided by WP2 (E) ?? Link: traffic signal cycle total time (as link

attribute) [sec.] -provided by WP2 user (E) ?? Link: traffic signal Green [%], flow [veh./h],

Length [km], Speed limit [km/h](as link attribute)-provided by WP2 user (E)

?? Link: Link flow by traffic model vehicle group [veh./h] (as link attribute)-provided by WP2

?? Link: Banning area code (as link attribute)-provided by WP2-GIS user

?? Parking Distributed Density (as a link attribute) [veh./km]- provided by WP3 user (S)

?? Pedestrian crossing flow (per hour, per link) (as link attribute) [person/(h*km)]- provided by WP3 user (S) (also go to WP9)

GIS object output ??Consumption: fuel consumption ( per link, hour,

fuel and vehicle macro category)[kg/h] (attribute of link)

??Consumption of energy per link over the Scenario Time Window [KWh]

??Pollutants emission: per hour, link and km. (link attribute)[Kg/h*km] (also go to WP4)

??Pollutants emission: per hour, link and km. and macro vehicle category [Kg/h*km]

??Pollutants emission: per link integrated on the scenario time window

Health Impact (WP6) ??Fleet: Vehicles occupation [person/vehicle] ??IOH: Accident number (veh-ped, veh-veh) [n.

of accident] –not yet for GIS ??Pollutants emission: Pollutants id. Code

Artistic Heritage Impact (WP7) ??Pollutants emission: Pollutants id. Code

Software Integration (WP8)

?? WP User (S)

- Consumption: consumption of fuel ( per link and hour)[kg/h] (S)

- Consumption: fuel consumption (per link, per hour and km.) [kg/(h*km)] (Attribute of the link)

- Fleet: Vehicle anual mileage (VAM) (per year) [km/year]

- Fleet: Fleet charateristics-Static fleet composition (SFC)(per year)[n.of vehicles]

- Geography: Altitude [metre (above sea level)] - Kinematic option (code) (per network) - Kinematics - Speed Cycle (per link) (optional with

WP2) - Link Type for TEE (code) - Link: Area type (code) - Meteo : sunrise and sunset time [day hour] - Parking Concentrated: id.number, occupancy rate

[%], type - Parking Concentrated: distance to the link inlet [m],

distance to the link end [m] - Parking Concentrated: capacity [vehicles] - Parking Concentrated: average parking time [hour] - Parking Distributed: avg. parking time [hour],

occupancy rate [%] ?? WP User (E)

- Consumption: Fuel code (per fuel) (encoded in WP3)

- Fleet: Vehicles occupation [person/vehicle] - Fleet: Link fleet composition [% of flow for each

micro category] (E) - Fleet: Number of traffic model vehicles Groups

(NTMVG) - Fleet: Code of vehicle group for each vehicle

microcategory - Fleet: Age of vehicle micro categories [y] - Fleet: Matenance level of vehicle micro categories

[month] - Pollutants emission: Pollutants id. Code (encoded

in this WP) - Fleet: Banning codes for banning areas and vehicle

micro categories (per banning area and per micro category)

?? GIS User (S)

- Meteo: temperature of the ambient(air) [deg.C] - Link: number of secondary intersections

?? GIS User (E)

- Link: link Slope (gradient)

Pollution Emission

& Energy Consumption

(WP#3)

??Fleet: Macro categories (also name as vehicle classes)-coding

??Fleet: Macro categories (coding)


73

Cellular Module (WP1)

Overall Analysis (WP9) ??Time: duration of peak period and all day-time

periods (per day time period and per day type) [hour]

ISM (WP8) ?? Time: Day category [number]

??Consumption: Fuel code (per fuel) ??Consumption: Fuel consumption aggregated for

WP 9 (per fuel, per scenario)[l/year for the full network]


??Fleet: Macro categories (coding) ??MCA indicator: number of walk trips (per

day)[Trip number] ??Pedestrian crossing flow (per hour, per link) (as

link attribute) [person/(h*km)]- provided by WP3 user (S)

??Pedestrian crossing flow (annual avg.) [Pedestrian trips]

??Pollutants emission: total [kg]

WP3’s Output

(WP#3) continue

??Consumptions: consumption of fuel (per link, per hour and km.) [kg/h*km]

??Dynamic fleet composition [% of each micro category]


74


modules.

Vertical broken arrow represents output data from the previous module input to the module.



Pollution Emission& Energy Consumption (WP3)

??Pollutants emission: Pollutants id. Codes

?? WP User (S)

- Meteo: Meteorology for ARIA impact and

ARIA Regional (also go to WP7): Wind direction [degrees], Stability class

- Meteo: Meteorology for Noise (NMPB) - Noise: calculation area (x, y coordinates)

[m] - Noise: emission: other sources [dB] - Pollutants conc.: background conc.(hour)

[µg/m³]

GIS information

?? Geometry: Geometry for ARIA Impact-

provided by WP4 user (S) (optional with output from WP2)

?? Geography: Geometry of buildings and road [m]-provided by WP4 SP user (I)

?? Geography: Land-use for ARIA regional (CORINE Land-use categories) [% of area]- provided by WP4 SP user (S)

?? Geography: Topography (height of ground) [m]- provided by WP4 user (S)

?? Geography: Concentrated parking position]- provided by WP4 GIS user (S)

?? Noise-Road emission NMPB [ dB(A)] (as link attribute) - provided by WP3

?? Noise: Other objects (noise barriers etc) ?? Pollutants emission: from disturbed parking (per

hour, per link) [Kg/h] – provided by WP3 ?? Pollutants emission: from concentrated parking

(per hour, per concentrated parking) [Kg/h] – provided by WP3

?? Pollutants emission: evaporative (VOC) from parked vehicles in concentrated parking (per hour, per concentrated parking) [Kg/h] – provided by WP3

?? Pollutants emission: evaporative (VOC) from parked vehicles in distributed parking (per hour, per link) [Kg/h] – provided by WP3

?? Pollutants emission: other emissions (area, point, line) [Kg/h]- provided by WP4 user (S)

?? Pollutants emission: per hour, per link (link attribute)[Kg/h] - provided by WP3

?? Pollutants emission: per hour, link and km. (link attribute)[Kg/h*km] - provided by WP3

Cellular Module (WP1) Artistic Heritage Impact

(WP7) ??Population: present (per hour, per traffic zone)

[n. of persons]

Transport Module (WP2)

??Geometry: Geometry for ARIA Impact (as GIS information) (optional with input from WP4 user)

??Kinematics: secondary stops [number of Stop/h] S ??Link: Link flow by Traffic Model Vehicle Group

[veh./h]

??Met. for monuments: Rain [m/year], Wind rose (intensity and direction)

??Met. for monuments: Time of wetness [%] (optional with WP7 user)

??Monuments: Carbonaceous Particles deposition velocity [cm/s], SO2 deposition velocity [cm/s], NOx deposition velocity [cm/s], SO2 deposition flux [µm/m2*year]

??Pollutants conc. (per pollutant: SOx, NOx, CO2, VOC, PM) (per kind of source, peak/annual avg./ seasonal avg.) .) (as GIS information)[µg/m³]

ISM (WP8)

GIS output ??Time: Day category [number]

Air Pollution/Noise

Dispersion

(WP#4)

??Pollutants emission: per hour, link and km. (link attribute)[Kg/h*km] - provided by WP3

??Pollutants emission: per hour, link and km., and macro vehicle category (link attribute)[Kg/h*km] - provided by WP3


75

* NOTE: WP6-a is the Exposure software TEX WP6-b is the Health Effect software HIT


modules.




Air Pollution/Noise

Dispersion (WP4)

??Noise-Lden; level loudest facade (per building) [dB(A)]

??Average pollutants conc. (PM 10, PM 2.5, SO2, NO2, O3 (not given by ARIA), CO) ( for the health effects module, avg. for the whole city) [µg/m³] (from ARIA)

??Yearly distribution of concentration by steps

?? IS User (S)

- IOH: Epidemiological statistics (Baseline

values, RR etc.)(WP6 will provide some default data)

- Pollutants conc.: Indoor/Outdoor ratio (per microenvironments, per pollutant) (WP6 will provide some default data)

?? WP User (S)

- Time activity patterns (per micro

environment) [%]

GIS information

?? Geography: Centroids of census zones –Coordinates (real) (provided by GIS user)

?? Noise-Lden (per facade and/or triangulated points) [ dB(A)] (as attribute of buildings) – provided by WP4

?? Pollutants conc. (hourly conc. map) (for health effects: PM10, PM2.5, SO2, NO2, O3, CO) and exposure module) (as GIS information)[µg/m³]- provided by WP4

?? Pollutants emission: from distributed parking (per hour, per link ) [Kg/h]- provided by WP3

?? Pollutants emission: from concentrated parking (per hour, concentrated parking) (as GIS information) [Kg/h]- provided by WP3


Overall Analysis (WP9) ??Population: present (per hour, per traffic

zone)[n. of persons] ??Population: age stratification (per traffic zone)

[%]

??IOH: Accidents: Severity of accidents [n. of accident]

??IOH: Years of Life Lost [year] ??IOH: morbidity, mortality rates (per year) [n. of

persons] ??IOH: noise: annoyed, exposed, sleep disturbed

[number of adults annoyed]

Transport Module (WP2) ??Link: travel time (for the exposure model)

[hour] ??Population: Travelling (n. of persons)

Pollution Emission& Energy Consumption (WP3) ??Fleet: Vehicles occupation [person/vehicle] T ??IOH: Accident number (veh-ped, veh-veh) [n.

of accident] –not yet for GIS ??Pollutants emission: Pollutants id. Code

ISM (WP8)

??Time: Day category [number]

Health Impacts (WP#6)

WP6-a (E) to WP6-b*

??IOH: Avg. exposure to air pollution during travelling (all pollutants monitored) [mcg*h*person/m3]

??IOH: Avg. population exposed to air pollution (all pollutants monitored) [person]


76


modules.



?? WP User (S)

- Cost: Monument: cost of maintenance;

cost of restoration (per type of monument per year) [€/m2]

- Met. for monuments: Rain acidity (H+) [mg/l], Sunshine hours [h/year], Wind frequency [%]

- Met. for monuments: Time of wetness [%](optional with WP4)

- Monuments: Pollution rose or pollution direction, RH (%)

- Monuments: risk rating - Monuments: status description - Monuments: detail characteristics: ID,

name, properties... ?? WP User (I)

- Monuments calculation option - Monuments: Number of monuments

GIS information

??Pollutants conc. (per pollutant: SOx, NOx,

CO2, VOC, PM) (per kind of source, peak/annual avg./ seasonal avg.) (as GIS information)[µg/m³]- provided by WP4

Overall Analysis (WP9) Cost: monument: cost of maintenance and/ or

restoration [€/m2] (Go to CBA) Cost: monument: Heritage Impacts [€/m2]

(Go to CBA)


ISM (WP8) ??Pollutants emission: Pollutants id. Code

??Monuments option

??Monuments: coordinates (real) [m] (has to be defined as WP4 needs)

Pollution/Noise Dispersion (WP4)

IS Final User (Output) ??Average pollutants conc. (PM 10, PM 2.5, SO2,

NO2, O3 (not given by ARIA), CO) ( for the health effects module, avg. for the whole city) [µg/m³] (from ARIA)

??Average pollutants conc. in monuments position ??Met. for monuments: Rain [m/year], Wind

rose (intensity and direction) ??Met. for monuments: Time of wetness [%]

(optional with WP7 user) ??Monuments: Carbonaceous Particles

deposition velocity [cm/s], SO2 deposition velocity [cm/s], NOx deposition velocity [cm/s], SO2 deposition flux [µm/m2*year]

??Meteo: Summary of meteo. and pollution data for monuments

ISM (WP8) ISI (Output) ??Time: Day category [number]

Artistic Heritage Impact

(WP#7)

??Monuments: Deposition of material [µm/year or g/m2*year] (Go to MCA)

??Monuments: Loss of material [µm/year or [g/m2*year] (Go to MCA)


77


modules.




Artistic Heritage Impact (WP#7)

??Monuments option

?? IS User (I)

- General data: Case study description - General data: Scenario description - General data: Suite entry point - General data: Output requirements

flags - Time: Final Time of Scenario (FTS)

[year, month, day, hour] - Time: Initial Time of Scenario (ITS)

[year, month, day, hour] - Time: hour [hour]

?? IS User (E)

- Duration of the analysis (Scenario)

[hour] ?? GIS User (E)

- Geography: Zone: id (traffic zone

attribute)(per traffic zone)

GIS information

(provided by GIS user)

?? Geography: Domain of analysis (GIS file) ?? Geography: Census zones (Shape file) ?? Geography: Traffic zones (Shape file)


??Geography: Zone: id (as traffic zone attribute) (traffic zone attribute)(per traffic zone) provided by GIS user (E)

??Geography: Zone: number of traffic zones (per network)



OUTPUT ??Fleet: Macro categories (also name as

vehicle classes)-coding ??Fleet: Macro categories (coding)

??Geography: Domain of analysis (as GIS file) - provided by GIS user

Artistic Heritage Impact (WP7)

??Monuments option

Software Integration [ISHTAR Suite Manager(ISM)]

(WP#8)


78


modules.



?? WP User (S)

- MCA indicator: Bus passenger numbers (per

day) [Trip numbers] - MCA indicator: Level of general accessibility

to facilities [min.] - MCA indicator: Mobility/access levels of

mobility-impaired - MCA indicator: Number of cycle trips (per

day) [Trip numbers] - MCA indicator: Number of visitors to

heritage sites(per day)[Visitor numbers] - MCA indicator: Perceptions of personal

security - MCA indicator: Perceptions of traffic safety - MCA indicator: Quality of public space - MCA indicator: Revenue of public transport

operators (per year, per scenario) [€] - MCA indicator: tram/light rail passenger

numbers (per year, per scenario) [Numbers of person] (optional with WP2)

- Time: Project life projections [days, months, years]

GIS information

?? Pedestrian crossing flow (per hour, per link) (as link attribute) [person/(h*km)]- provided by WP3 user (S) T

Transport Module (WP2)

??MCA indicator: Tram/light rail passenger numbers (per year, per scenario) [Numbers of person] (It’s optional, if it’s from multimodel, it will go to WP9)

??Trips: annual traffic flow per link [Pcu] ??Trips: Travel time [pcu.h]


??Consumption: Fuel code (per fuel) ??Consumption: Fuel consumption

aggregated for WP 9 (per fuel, per scenario)[l/year for the full network]


??Fleet: Macro categories (coding) ??MCA indicator: number of walk trips (per

day)[Trip number] ??Pedestrian crossing flow (annual avg.)

[Pedestrian trips] T ??Pollutants emission: total [kg] T

Health Impact (WP6)

IS Final User ??IOH: Accidents: Severity of accidents [n.

of accident] ??IOH: Disability Adjusted Life Years

(DALYs) [year] ??IOH: morbidity, mortality rates (per year)

[n. of persons] ??IOH: noise: annoyed, exposed, sleep

disturbed [number of adults annoyed]

Overall Analysis

of Case Study

(WP#9)

Multi Criteria Analysis (MCA)

??General data: Descriptive transport statistics

??MCA: Multi-criteria Analysis scores (1) ??MCA: Multi-criteria Analysis scores (2)


79


modules.



?? WP User (I)

- Cost: Cost of fuel [€/litre] ?? WP User (S)

- Cost: Discount rates [%] - Cost: Investment: construction costs

Disruption costs, Planning costs, Real estate acquisition costs [€]

- Costs: System operation and maintenance; Periodical maintenance of measures; Administrative and monitoring costs; Equipment or renewal costs [€]

?? WP User (S) or EUNET valuation

- Cost: casualty serious, slight [€] - Costs: Value of a life [€]

Artistic Heritage Impact (WP7)

IS Final User ??Cost: monument: cost of maintenance and/

or restoration [€/m2] ??Cost: monument: Heritage Impacts [€/m2]

Overall Analysis

of Case Study

(WP#9)

Cost-benefit Analysis (CBA)

??Cost-benefit matrices and charts [€]

App2 : Contacts Details

N° Institution/Organisation Street name and number Post Code Town/City Country

Code Family Name First Name Telephone N° Fax N° E-Mail

Web site

1 ENEA Via Anguillarese, 301 Santa Maria di Galeria

00060 Rome I Negrenti Emanuele +39 06 3048 4112 +39 06 3048 6611 [email protected]

www.enea.it

2 ASTRAN Via Monfalcone 22 01100 Viterbo I Parenti Antonio +39 339 5831942 178 2228308

[email protected]

www.astran.it

3 ROME Via Cola di Rienzo , 23 00192 Roma I Canofani Annamaria +39 06 322 6864 +39 06 360 855 85

[email protected]

www.comune.roma.it

4 ISIS Via Flaminia 21 00196 Roma I Enei Riccardo +39 06 3612 920 +39 06 3213049

[email protected]

www.isis-it.com

5 WHO Via F. Crispi 10 00187 Roma I Martuzzi Marco +39 06 4877 520 +39 06 4877 599

[email protected]

www.who.it

6 STRATEC Avenue A. Lacomblè 69-71 B 1030 Brussels B Duchateau Hugues +32 2 7350 995 +32 2 7354 917

[email protected]

www.stratec.be

7 BOLOGNA Via Zamboni 13 40121 Bologna I Bollini Gabriele +39 51 218 888 +39 51 218 883

[email protected]

www.provincia.bologna.it

8 AIRPARIF Rue Crillon 7 75004 Paris F Gombert Dominique +33 1 4459 4100 +33 1 4459 4767

[email protected]

www.airparif.asso.fr

9 CBC 47 Rue de Lancry 75010 Paris F Baudez Gildas +33 1 4241 2121 +33 1 42 41 70 40

[email protected]

www.cbconseil.com

10 TraC Stapleton House, 277-281 Holloway Road N7 8HN London UK Shaw Steve +44 20 7753 5754 +44 20 7753 3336

[email protected]

www.unl.ac.uk/trac

11 INRETS 2 Avenue du General Malleret-Joinville

94114 Arcueil - Paris F Flavigny Pierre Olivier +33 1 47407128 +33 1 45475606 [email protected]

12 GRENOBLE 11 Boulevard Jean Pain 38021 Grenoble F Bartone Bahier Isabelle +33 4 3837 2250-1 +33 4 3837 2237 [email protected]

13 PHAOS 25, Kifisias Avenue 11523 Athens GR Athanassakos Eva +30 10 6441094 +30 10 6441016 [email protected]

14 STA Via Ostiense 131 L 00154 Roma I Nussio Fabio +39 06 5711 8469 +39 06 57118 547 [email protected]

15 TU GRAZ Inffeldgasse 25, A 8010 Graz A Sturm Peter +43 316 8737584 +43 316 873 8080 [email protected]


82

N° Institution/Organisation

Street name and number Post Code Town/City Country Code

Family Name First Name Telephone N° Fax N° E-Mail

Web site

16 APSIS Dimitsanis str. 3 – 5 - GR 183 46 Athens GR Teophilopoulos Nick +30 10 4838 938 +30 10 4836 807 [email protected]

17 YPEXODE 70 Panormou str. 23 GR 115 Athens GR Kitsos Dimitrios +30 1 6999 402 +301 6983 448 [email protected]

18 ARIA 17, Route de la Reine 92517

Boulogne Billancourt -

Paris F Moussafir Jacques +33 1 5519 9976 +33 1 5519 9962 [email protected]

19 Ville de Paris Rue du Louvre 40 75001 Paris F James Bernard +33 1 4028 7430 +33 1 4028 7415 [email protected]

External Partner Organisation (subcontractors)

20 B&B

21 PTV

22 KMG

23 BERRY Ltd

24 NORDPLAN

25 ROMA I Un.

Documents

PART III – ISHTAR suite software realisation · 2015. 7. 3. · PART III – ISHTAR suite software realisation 3.1 ISHTAR suite architecture 3.1.1 General composition of Ishtar