Transcript Activity Schedule Model for Tel Aviv Metropolitan: Outline

Activity Schedule Model
for Tel Aviv Metropolitan:
Outline and Application
Issues
by Leonid Kheifits, Boris Shmulyian,
Shlomo Bekhor
EMME User’s Conference,
Montreal, October 2010
Introduction


The model was developed for MOT of Israel by
Cambridge Systematics, Ltd. with participation of
local team (data collection and processing and
model implementation)
The model is intended for use by transportation
planning agencies as a mutual base for analyzing
transportation projects of various types:






Congestion pricing,
Parking policy,
Land use and growth management,
Introduction of new public transportation systems (LRT,
BRT)
Highway improvements
The model is maintained by Ayalon Highways
Company (MOT)
Project area
About 1,500 square Km and
3.3 million habitants in 2009
Model Dimensions
1219 TAZ
13,000 regular links
1000 Transit lines
Main Modes: car driver,
car passenger, taxi, bus,
rail, Mass Transit
(BRT/LRT)
Access modes: walk,
transit, Park&Ride,
Kiss&Ride
Model Structure
Base List
of Persons
POPULATION
GENERATOR
Persons
By Zone
Zonal Data
Estimated
Models
Networks
TOUR
GENERATOR
Full List
of Tours
Level of
Service
Initial
Demand
TRIP
GENERATOR
ASSIGNMENT
UNIT
OD
Matrices
Population Generator
POPULATION
GENERATOR

Input:


Base list of persons (NTHS)
Zonal constraints for each TAZ for target year








Zonal population
Distribution by gender and age
Average household size
Average number of workers
Method: multi-dimensional IPF
Output: Synthesized population
Software: Stand-alone module (FoxPro)
Run time: 10 to 15 minutes
TOUR
GENERATOR
Tour Generator
Reproduces trip patterns observed:
Up to 2 home-based tours during a day with 0 or
1 intermediate stop between home and main
destination and with 0 or 1 intermediate stop in
trip back home
 Input:






Synthesized population
Zonal attributes
Level of service
Method: set of logit models
Output: Day travel schedule of each person
Software: Integrated C# application
Tour Generator. Flow Chart
Car availability
Zero
One
Two +
Main Activity
Work
Education
Shopping
Other
No Tour
Time Periods
Tour start
Morning AM peak Midday PM peak Evening
Tour End
Morning AM peak Midday PM peak Evening
Tour Generator. Flow Chart
Main Destination
Destination 1
Destination …
Destination 1
Destination 2
Destination 3
Destination … Destination 1219
Tour Main Mode
Taxi
Driver
Passenger
Bus
Rail
MT
Walk,
P&R,
K&R
Walk,
Bus + MT,
P&R,
K&R
Walk,
Bus,
P&R,
K&R
Tour Generator. Flow Chart
Intermediate Stops
No Stops
Before
Work
After
Education
Before and After
Shopping
Other
Location of Intermediate Stops
Destination 1
Destination 2
Destination 3
Destination … Destination 1219
Mode Switching at Main Destination
No Mode Switch
Switch to Driver
Switch to Passenger Switch to Transit
TRIP
GENERATOR

Trip Generator
Input:


Day travel schedules
Additional demand
External trips
 Trucks and commercial vehicles


Output:


Origin-destination matrices by mode and period of
day
Software: C# application and EMME macro
ASSIGNMENT
UNIT

Tasks:






O-D matrices by mode and time of day
Road and transit networks and parking data
Outputs:




Determination of mode choice set
Assignment of combined modes
LOS calculation and storing
Summarizing results
Input data:


Assignment Unit
Level of service matrices
Mode choice feasible sets
Highway and transit assignments
Software: EMME macros & auxiliary C++ application
TRIP
ASSIGNMENTS

Motivation:





Logit mode choice model does not exclude any itinerary
EMME assignment procedure cuts out non-competitive itineraries
The probability of mode choice obtained from logit model cannot be
reproduced by assignments
The mode choice set should correspond to both choice model and assignment
procedure
Solution:


Feasible Mode Choice Sets
Define “feasible” set of alternatives for each OD pair
Possible approaches:


Define rules for excluding “not reasonable alternatives”
Take advantage of consistency of EMME assignments
Example of feasibility rules
Destination
Origin
BUS
RAIL
Feasibility rule: IVTBUS / IVTRAIL < k
Side effect: increase in train
speed may result in decrease in
ridership
Adopted Approach
Make Trial Assignment
Mark OD-pairs with no
use of given mode as
not feasible
Save feasibility mask
in a matrix for next
iteration
Advantages:
 Assures consistency of mode choice
 Cuts off non-competitive alternatives
Assignment Unit. Modes for assignment
Taxi
Driver
Passenger
14 modes of
Tour Generator
Simple Modes
10 modes of
AU
Driver
+Taxi
Bus
Walk access
Bus
Rail
MT
Walk,
P&R,
K&R
Walk,
Bus + MT,
P&R,
K&R
Walk,
Bus,
P&R,
K&R
Combined Modes
Bus
P&R access
MT (LRT/BRT)
Bus/walk
access
Rail
MT/Bus/walk
access
Bus
K&R access
MT (LRT/BRT)
P&R access
Rail
P&R access
MT (LRT/BRT)
K&R access
Rail
K&R access
Assignment for combined
modes
Should be consistent with mode choice model
Two approaches were considered (example of Rail,
Park & Ride access):
Combined mode assignment - 1
1.
2.
3.
4.
5.
Make auto
assignment to
obtain access
travel time
Make transit
assignment to
obtain LOS
indices
Find the station of
boarding
Make auto
assignment
(Origin-> parking
lot)
Make transit
assignment
(Parking lot ->
destination)
Origin TAZ
Roads
P&R
parking
lot - 1
Walk
P&R
parking
lot - 2
Walk
RAIL
Destination TAZ
Combined mode assignment -2
1.
Make auto
assignment
to obtain
access travel
time
Origin TAZ
Roads
P&R
parking
lot
Walk
P&R
parking
lot
Walk
RAIL
Destination TAZ
Combined mode assignment -2
1.
2.
3.
Make auto
assignment
to obtain
access travel
time
Create
access links
(auxiliary
transit) to
represent car
access
Make transit
assignment
Origin TAZ
Access links
RAIL
Destination TAZ
Combined mode assignment -2.
Summary
•
•
•
•
Total number of stations with P&R/K&R access: 190
Total number of access links: about 10,000
Average number of outcome access links per TAZ:
53
Average number of income access links per station
with P&R/K&R: 52
LOS calculation and storing
LOS indices needed for Tour Generator:
 In-vehicle times
 Total travel times
 Waiting times
 Number of transfers
 Access/egress times
Total of about 80 matrices for one POD including
feasibility masks:
 Obtained directly from assignments
 Obtained from assignments with additional
options
Use of MatInOut.exe – application for
export/import matrices (binary format)
Other Features
Disaggregate tour-based approach
allows accurate handling of return trips
for P&R access modes and accounting
for occupancy of parking lots during
the day
Extended usage of read/write files
helped in adding/deleting/modifying
access links and in preparation
summary files for EXCEL
Model Performance



Disk space required for regular project – about
4GB
Memory required – about 1.5 GB
Run times (Intel® Core™2 CPU 6300, 1.86.GHz):


Tour Generator and Trip Generator for sample of 10%
(about 330,000 persons) is: about 1 hour for first iteration
that includes car ownership model, and 25 minutes for
regular iteration
Assignment Unit is about 45 minutes for one POD:




Auto assignments – (4 assignments): 12 minutes
Transit assignments (53 assignments): 22 minutes
Creation of access links – 3 minutes
Matrix calculations and read/write files: 9 minutes
Conclusions

The structure of modes should be simplified to
assure consistency with mode choice model:



Driver, Passenger, Transit, P&R, K&R
Usage of feasible set of modes for each OD
proved to be efficient
Opened issue: combined mode assignment
with a single mode change point and cut-off of
unreasonable alternatives vs. “logit”-type
model with several possible mode change
points and inclusion of all alternatives
Future developments
Next version of the model will include
parallel processing: Tour Generator will
take advantage of all available
processors, and Assignment Unit will
work simultaneously with 3 POD (in 3
separate banks)
Expectations
Following are the main types of processing required
for complex models, which are not covered now by
EMME:
 Work with groups of objects (define selection set,
add/delete/modify entire group)
 EMME macro language is irreplaceable in everyday
work, but it is not powerful enough for common
programming tasks required for complex models
 Work with databases
 Reporting
Expectations - 2



Integration of Python may allow
implementing future models within EMME
Extended import/export abilities (for
matrices DBF, CSV, and binary formats, for
networks – EXCEL, csv) would be highly
useful
Advance in transit assignment procedures
may improve performance of the model