Activity Schedule Model for Tel Aviv Metropolitan: Outline and Application Issues

1
Activity Schedule Model for Tel Aviv
Metropolitan Outline and Application Issues

• by Leonid Kheifits, Boris Shmulyian,
• Shlomo Bekhor

EMME Users Conference, Montreal, October 2010
2
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)

3
Project area
About 1,500 square Km and 3.3 million habitants
in 2009
4
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, ParkRide, KissRide
5
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
TRIP GENERATOR
ASSIGNMENT UNIT
Initial Demand
OD Matrices
6
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

7
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

8
Tour Generator. Flow Chart
Car availability
Zero
One
Two
Main Activity
Work
Education
Shopping
Other
No Tour
Time Periods Tour start Tour End
Morning AM peak Midday PM peak Evening
Morning AM peak Midday PM peak Evening
9
Tour Generator. Flow Chart
Main Destination
Destination 1
Destination
Destination
Destination 1
Destination 2
Destination 3
Destination 1219
Tour Main Mode
Passenger
Driver
Taxi
Bus
Rail
MT
Walk, PR, KR
Walk, Bus, PR, KR
Walk, Bus MT, PR, KR
10
Tour Generator. Flow Chart
Intermediate Stops
No Stops
Before
After
Before and After
Work
Education
Shopping
Other
Location of Intermediate Stops
Destination 1
Destination 2
Destination 3
Destination
Destination 1219
Mode Switching at Main Destination
Switch to Driver
Switch to Transit
Switch to Passenger
No Mode Switch
11
Tour Generator. Interaction between models
LogSum (Destinations)
Car Availability
Main Activity
LogSum (Destinations)
Periods of Day
LogSum (Modes)
Main Destination
Mode
Type of Intermediate Stops
Intermediate Stop Activity
Intermediate Stop Location
12
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

13
Assignment Unit
ASSIGNMENT UNIT

• Tasks
• Determination of mode choice set
• Assignment of combined modes
• LOS calculation and storing
• Summarizing results
• Input data
• O-D matrices by mode and time of day
• Road and transit networks and parking data
• Outputs
• Level of service matrices
• Mode choice feasible sets
• Highway and transit assignments
• Software EMME macros auxiliary C application

14
Assignment Unit. Flow Chart
15
Feasible Mode Choice Sets
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
• 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

16
Example of feasibility rules
Destination
Origin
BUS
RAIL
Feasibility rule IVTBUS / IVTRAIL lt k

• Side effect increase in train speed may result
  in decrease in ridership

17
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

18
Assignment Unit. Modes for assignment
Passenger
Driver
Taxi
Bus
Rail
MT
14 modes of Tour Generator
Walk, PR, KR
Walk, Bus, PR, KR
Walk, Bus MT, PR, KR
Simple Modes
Combined Modes
10 modes of AU
MT (LRT/BRT) Bus/walk access
Rail MT/Bus/walk access
Bus PR access
Driver Taxi
Bus Walk access
Bus KR access
MT (LRT/BRT) PR access
Rail PR access
MT (LRT/BRT) KR access
Rail KR access
19
Assignment for combined modes

• Should be consistent with mode choice model
• Two approaches were considered (example of Rail,
  Park Ride access)

20
Combined mode assignment - 1

1. Make auto assignment to obtain access travel time
2. Make transit assignment to obtain LOS indices
3. Find the station of boarding
4. Make auto assignment (Origin-gt parking lot)
5. Make transit assignment (Parking lot -gt
   destination)

Origin TAZ
Roads
PR parking lot - 2
PR parking lot - 1
Walk
Walk
RAIL
Destination TAZ
21
Combined mode assignment -2

1. Make auto assignment to obtain access travel time

Origin TAZ
Roads
PR parking lot
PR parking lot
Walk
Walk
RAIL
Destination TAZ
22
Combined mode assignment -2

1. Make auto assignment to obtain access travel time
2. Create access links (auxiliary transit) to
   represent car access
3. Make transit assignment

Origin TAZ
Access links
RAIL
Destination TAZ
23
Combined mode assignment -2. Summary

• Total number of stations with PR/KR 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 PR/KR 52

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

25
Other Features

• Disaggregate tour-based approach allows accurate
  handling of return trips for PR 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

26
Model Performance

• Disk space required for regular project about
  4GB
• Memory required about 1.5 GB
• Run times (Intel Core2 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

27
Conclusions

• The structure of modes should be simplified to
  assure consistency with mode choice model
• Driver, Passenger, Transit, PR, KR
• 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

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

29
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

30
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