WP4 Construct common model software implementation tool

1
WP4 Construct common model software
implementation tool

• Otto Anker Nielsen, oan_at_ctt.dtu.dk
• Professor, Ph.D.
• Technical University of Denmark (DTU)
• Centre for Traffic and Transport (CTT)

2
Presentation overview

• Main structure
• Interfaces
• Storage of data and integration of (sub)models
• Role of partners

3
MAIN STRUCTURE new blue-print

• Very important that this is finally agreed upon

4
INTERFACES

• Trade model
• Freight modal split
• Logistic model
• Passenger model
• Economic model
• Assignment
• Impact models
• Emissions, accidents, etc.

5
Freight models

• 3 model components
• Trade model (production / attraction)
• Modal split model
• Logistic model
• TNO/NEA
• TNO/NEA specifies how the 3 models are to be
  integrated into the blue-print
• And how this is to be taken care of by the ArcGIS
  model builder interface

6
Trade model

• Input
• The transport component only includes OD-matrices
• These are delivered by the modal split model
• There is a deterrence variable in the model, but
  this is not defined as input? It would be better
  to use average LoS than the best/minimum
• How is the interaction with CGEurope specified?

7
Modal split - freight

• Input Etis freight matrix
• For pivot purposes
• Is this consistent with the trade model
  (increased demand), and CGEurope (changed trade
  patterns?)
• Unimodal level of Service matrices
• Mode
• Not all modes are available between all OD-pairs
• Availability matrix
• Waiting time and cost can only be guessed, since
  no data on frequencies or time-tables are
  available in the networks
• No data at all on reliability
• Rates and mode specific information (e.g. speed
  per mode) are exogenous information, that need to
  be provided for the assignment procedure is
  this delivered by TNO?

8
Logistic module

• Input
• No information on tolls are available in the road
  network database
• Network possibilities
• Possible, but need to be solved by recoding the
  software
• Output
• Only NSTR 0,1,5,8,9
• Are the other NSTR delivered by the model choice
  model?
• TNO/NEA need to provide a procedure to provide
  matrices for all NSTR
• This may be added to the blueprint
• A lot of parameters/variables are requested
• Value density, etc.
• They should be stored in a database, making it
  easy for the user to change the settings

9
Passenger demand model

• Input
• Unimodal matrices
• Access/egress time per mode this is part of a
  multi-modal chain, and should be taken care of by
  the demand model, e.g. car or train to airport
• Frequency per public transport mode - can only be
  a rough guess, since no information is available
  in the networks
• Transfers in public transport not available,
  since we do not have a time-tables and line info
  in the network

10
Passenger model to ASTRA link

• ASTA and VACLAV are separate models
• IWW specifies how these are to be integrated into
  the ArcGIS/ModelBuilder interface

11
CGEurope (CAU) links

• LoS must be log.sums from the logit-based models
• I.e. freight mode choice
• Logistic model
• IWW passenger model
• Monte-carlo averages from simulated SUE
• The latter averages are provided indirectly as
  unimodal LoS input to the mode choice models
  mentioned above
• The optimal route (fastest, less costly, lowest
  general cost), DOES NOT SECURE CONSISTENCE
  between models
• Populations forecasts?
• In general where are this stored (recommended in
  the ArcGIS interface), and who forecast this?

12
LoS feedback, passengers

• Log.sums must be calculated from passenger demand
  models

13
LoS feedback from freight

• Can this be done by log.sums?

14
CAU output freight demand model input

• Output from CAU are commodity flows at a OD-level
• HOWEVER, is the freight demand model consistent
  with this (no), since this information is not
  required as input to the freight model
• Policy evaluation measures
• Is this part of the input data to the freight and
  passenger demand models?

15
CGE Europe demand model interface
16
Impact models (ISIS)

• How and where are they implemented
• And how are they integrated into ArcGIS
• The simpler may be just implemented directly in
  ArcGIS
• Or as .exe file, etc.

17
Conversion between NUTS

• Aggregation of LoS easy (log.sums or simulated
  averages)
• But disaggregation of demand?
• Where?
• CGEurope socio-economic data to NUTS 3
• Freight matrices from NUTS 2 and 2½ to NUTS 3 OD
  matrices
• Passenger matrices NUTS 3 NUTS 2½ (airports) to
  matrices

18
Splitting of freight matrices

• NUTS II to harbours
• NUTS II to III split by regional GDP
• Harbours split based on turnover
• Distance based deterrence function
• Double cell-constrained gravity model (NUTS II
  and harbours before split)
• NUTS II to NUTS III
• NUTS II to III split by regional GDP
• Distance based deterrence function
• Double cell-constrained gravity model (NUTS II)

19
Passenger matrices airports

• Chains car/train -gtairport-gtcar/train
• To be discussed further between CTT/Rapidis and
  IWW

20
WORK PROCESS ideal

• Mode specific OD-matrices delivered to CTT (NUTS
  and harbours/airports)
• Freight still missing (tons to trucks conversion
  method, NUTS III)
• Assignment models are run
• LoS matrices are delivered to IWW (passenger
  traffic) and NEATNO (freight transport)
• Demand models are estimated and calibrated on the
  LoS (among other data, IWW NEA)
• Log sums need to be incorporated into demand (see
  other slides)
• CGE Europe receives log.sums and LoS (aggregated
  on OD-level) from the two demand models (freight?
  and passenger), i.e. one number per OD-pair and
  category

21
Aggregation of LoS

• OD-matrices are split into mode-specific
  sub-trips before assignment
• Unimodal LoS matrices used for feed back from
  assignment to demand
• Module for uni-modal sub-trip combinations is
  part of demand models (IWW, NEA)
• To aggregate LoS from NUTSIII to NUTSII
• Weighted average
• First over routes, then over regions, is done by
  CTT

22
Transfer of OD from demand to assignment

• Information on NUTS-matrices transferred from
  demand models to assignment
• Region or port from freight models (NEA)
• Region or airport from passenger models ?
• CTT will then split to NUTSIII and pseudo NUTSII½
  zones (harbours and airports)
• But this can first be done, when demand modellers
  have decided upon harbours and airports
• This in on the critical path

23
STORAGE OF DATA

• All variables used in the models is stored in the
  same environment (ArcGIS), and transferred to the
  various sub-models (e.g. the demand model)
• This includes not only network data but also e.g.
  socio-economic data on NUTS, cost data on
  transhipments

24
Integration of sub-models

• The various sub-models are integrated into the
  common model using the Model Builder
• Model Builder uses ArcGIS Geoprocessing tools or
  stand-alone executable programs, that can be run
  from a command line
• Consequently, all sub-models import/export
  routines and results processing must be either
  Geoprocessing tools or a stand-alone executable
  program

25
Integration of sub-models 2

• The Assignment models are already implemented as
  native Geoprocessing tools
• A good part of the needed import/export routines
  and processing of results can be done by using
  existing standard ArcGIS Geoprocessing tools
• Most likely the demand models and other sub
  models should be delivered as executables, that
  can be used in the Model Builder

26
Software requirements

• Sub models, which are not native Geoprocessing
  tools, should
• Run under Microsoft Windows XP
• Be either
• executables that can be run from a command line
  or
• bat files acting as executable files
• Accept all parameters (paths to input/output data
  for the model etc.) on a single command line
• All parameters are enclosed in and separated
  by space
• Missing parameters are specified by
• Preferably Use text-files or database tables for
  input and output of data, which needs to be
  exchanged with other sub-models

27
Data storage requirements

• The Model Builder is part of ArcGIS, and uses
  ArcGIS for data access
• ArcGIS supports these data formats for use in
  model builder
• MS Access
• ESRI Shape files
• Text files
• Decimal separator is .
• Columns delimited by ,
• Enterprise Databases
• Read/write with ArcSDE Spatial server, read-only
  without ArcSDE
• Oracle
• SQL Server
• DB2

28
Data format requirements

• Assignment models are a central part of the
  common model and already implemented as a native
  Geoprocessing tool
• Other models (executable files) will be wrapped
  as Geoprocessing tools to fit into the framework
  of the common model
• To exchange data with the assignment model, a
  specific data format is required

29
ROLE OF PARTNERS (refer to minutes from Rome
meeting)

• NEA deliver NUTSIII and transhipment point info
  (harbours) to CTT
• NEA specify cost (LoS) formula to CTT for the
  freight model, CTT deliver data joint
  discussion about how to store data (e.g.
  transhipment cost) in the database
• NEA/TNO suggest what to do with vans
• IWW specify interaction between passenger demand
  and assignment (passengers to cars)
• IWW deliver NUTSIII and maybe transfer point info
  (airports)
• IWW send key for changes of zones to CTT (E.g.
  Estonia)
• IWW send new feeding points to CTT
• IWW send GA-matrix for passengers to CTT
• Passenger VoTs are sent to CTT
• ISIS specify methods for external impacts
• Socioeconomic data to be delivered by NEA and IWW
  (database format with link to NUTS)
• CTT write notes on access modes to airports
• CTT write note on NUTSII to NUTSII½ to NUTSIII
  freight matrix split

30
Critical path

• IWW send changes of zones in Estonia,, to CTT
• IWW send GA matrices to CTT
• Crucial for modelling local traffic and
  congestion
• Split of matrices into harbours (NEA/TNO) and
  airports (IWW) feeding points
• CTT calibrates assignment model
• CTT deliver LoS to NEA/TNO and IWW

31
How to proceed

• CTT and Rapidis will write technical interface
  documents (protocols)
• Input variables (scenarios) and formats
• Control variables (e.g. rates of interest, price
  development,)
• Parameter files (programme/method settings)
• Output variables and formats
• Error messages handling
• Executable requirements
• Some of the interfaces may require bi-lateral
  meetings