An Activity-Based Model for Cube Voyager

Agenda

Background & motivation Structure of the model Scripting features Application case study

The Four-Step Modeling Process

One (extremely common) method of forecasting travel demand Trip ends (productions and attractions) are generated based upon socioeconomic and demographic factors These are distributed between zones based upon aggregate travel costs Logit models are used to split person trips between different travel modes Trips by mode are factored by time of day and assigned to specific network paths Modern versions of this process feedback costs from assignment to earlier steps

Trip Generation

Trip Distribution

Mode Choice

Network Assignment

Limitations of Trip Based Models

With Person-trips as the unit of analysis: No interactions between trips made in the same trip chain No interactions between trip chains made during the same day No interactions between the trips made by people in the same household Spatial aggregation of Trips: Trip origins and destinations modeled as if they are located at the same point in space Demographic aggregation: All households within a given zone are treated as identical or segmented along a few dimensions Temporal aggregation: Only a few periods of the day are considered Proportion of trips made in each period treated as constant

Activity Based Models

Early recognition that travel is a derived demand
derived from a persons desire to engage in activities that are spatially separated Focus of the model should be on the underlying behavior: What people want to do, not where people want to go

Early attempts at implementing tour based models

San Francisco Bay Area, The Netherlands, Boise Idaho, Stockholm, New Hampshire, Italy

Current implementations of activity-based travel demand model systems

Portland OR, San Francisco County CA, New York City, Columbus OH, Atlanta, San Francisco Bay Area (MTC)

Activity and Tour Based Modeling

Alternative to four-step modeling approach popular in the academic transportation research community and becoming more common in practice (although still less than FSM) Disaggregate simulation using synthetic populations based upon micro-data Complete tours, or chains of trips, are analyzed, rather than individual trips

Auto Ownership Model

Activity Day-Pattern Choice

e.g. Home > Work > Shop > Home

Activity location and scheduling models Mode choice applies to entire tour Ideally suited for dynamic traffic assignment and meso-simulation

Tour Generation & Time-of-Day

Joint Mode/Destination Choice

Motivation for the Work

What? An activity-based microsimulation model implemented completely in Cube Voyager scripting language (no external code) Why? A learning tool for (potential) model users A forecasting tool for small/medium cities A test bed for model developers

Why Cube Voyager instead of ______?

Most existing activity-based models are custom programs written by consultants in third-party programming languages
Examples: Java, C++, C#, Python, R Steep learning curve to develop & maintain Relatively difficult to scale the model to match resources

Using Voyager instead offers significant advantages:

Intelligible to non-programming modelers = easy to learn & use Easily scalable (using Cube Cluster for distributed processing) Data models, not object models = less complex code Model structure is transferrable, not agency- or consultant-specific

The Model System Structure

1. 2. 3. 4. 5. 6.

Population synthesizer Zonal accessibility measures Activity and travel simulator Travel aggregator Traffic assignment Feedback loop / equilibration

For background on theoretical development of model structure see: Bowman, John L. and Mark A. Bradley (2005) Disaggregate treatment of purpose, time of day and location in an activity-based regional travel forecasting model, European Transport Conference, October 2005, Strasbourg, France.

Simple Population Synthesizer

Uses household and person records from PUMS 5% microdata Uses Census Table CTPP1-75, by TAZ
HH size (1, 2, 3, 4+) HH income (0-15K, 15-30K, 30-50K, >75K)

Draws households randomly from PUMA to match marginal distribution in each TAZ

Highway and transit networks

6 highway variables
SOV distance, time and toll HOV distance, time and toll

5 transit variables

Walk access/egress time First wait time Transfer time In-vehicle time Fare AM peak, Midday, PM peak, Off-peak

4 time periods

Zonal accessibility measures

Aggregate mode/destination choice logsums:

3 travel purposes

Work (total employment) School (K-12 enrollment) Other (retail employ. + service employ./2)

4 times of day

AM peak, Midday, PM peak, Off-peak Traveling away from zone, returning to zone With SOV available, without SOV available

2 directions

2 car availability situations

Activity and Travel Simulator

Main loop on households
Household car ownership model Loop on people in household
Full day tour/trip activity pattern choice Loop on tours in the day
Tour time of day choice models (both directions) Tour main mode and destination choice Loop on trips in the tour
Intermediate stop location choice model Trip mode choice (usually same as tour mode) Write trip record (with tour, person and HH info)

Travel Aggregator
Aggregates records to create trip matrices by: 4 time periods

AM peak, Midday, PM peak, Off-peak SOV, HOV, transit, walk

4 modes

Flexible to allow other breakdowns, e.g.:

Separate assignment by income class

Traffic assignment

Uses CUBE Voyager highway assignment 3 separate assignments: AM peak, Midday, PM peak Off-peak LOS uses uncongested speeds.

Initial application in Cubetown

Coded by Victor Siu & Ken Vaughn Used the Cubetown demo networks and zonal files System of 25 zones and highway, transit networks, based on an area of Fargo, ND Synthetic population of 70,006 persons, based on 1990 CTPP data for similar zones Ran 4 full iterations with assignment

2009 Update to Activity-Based Model

Re-implementation using DBI Simple population synthesizer Enhanced integration:

Cube Cluster Model Catalog Geodatabase inputs GIS Mapping Cube Reports

Added to 5.1 Cubetown demonstration model set

Get it at www.citilabs.com/tutorials.html

Tutorial Model Catalog

Conclusions
Back to our motivations A learning tool for (potential) model users A forecasting tool for small/medium MPOs A test bed for model developers

As a learning tool

A quick and easy way to learn about the properties of activity-based microsimuation
Sensitivity tests on a wide range of policies Reporting on several levels and variables (network, trip, tour, person, household) Practical context for advanced Cube Voyager functions

Further development
Further standardize data model & parameters Explore benefits of multi-dimensional arrays in 5.1

As a forecasting tool

Provides many advantages over 4-step The framework is feasible for small and mediumsized regions. You can always integrate custom programs with Cube Voyager (e.g. for large regions) if preferred Further development
Calibrate and validate on region-specific data Transfer to other regions (structure and many parameters should be transferable) Continue to improve run-time performance