Travel Model Two Assignment System ¶

Overview ¶

The Travel Model Two (TM2) assignment system converts travel demand into traffic flows and transit ridership by simulating traveler route choice on transportation networks. The assignment system consists of two primary components: highway assignment and transit assignment, each using equilibrium-based algorithms to model realistic travel patterns.

System Architecture ¶

graph TD
    START[Base Network] --> TOD[Create TOD Scenarios]
    TOD --> READY[Period-Specific Networks
EA, AM, MD, PM, EV]
    READY --> A[Travel Demand
From CT-RAMP]

    A --> B{Assignment Type}
    B -->|Auto Trips| C[Highway Assignment]
    B -->|Transit Trips| D[Transit Assignment]

    C --> E[Highway Network Loading]
    E --> F[Volume-Delay Functions]
    F --> G[Updated Travel Times]
    G -->|Feedback| C

    D --> H[Transit Network Loading]
    H --> I[Capacity Constraints]
    I --> J[Updated Transit Times]
    J -->|Feedback| D

    C --> K[Highway Skims]
    D --> L[Transit Skims]
    K --> M[Level-of-Service Feedback
to CT-RAMP]
    L --> M

Network Preparation ¶

Base Network Requirements ¶

Before running TM2PY assignment, you must have a base Emme network scenario with specific required attributes. The assignment system expects two separate networks:

Highway Network Requirements ¶

Required Base Scenario Attributes:

The all-day base scenario (typically scenario ID 0) must have these link attributes already defined:

Attributes Created by create_tod_scenarios:

The create_tod_scenarios component will create these attributes (they should NOT be in your base network):

• @area_type - Area type classification (0-5), calculated from MAZ density
• @capclass - Capacity class, derived from @ft and @area_type
• @free_flow_time - Free flow time, calculated from length and speed
• @capacity - Link capacity, set by facility type and area type
• @trantime - Transit travel time
• Plus many assignment result attributes (@flow_, @cost_, etc.)

What You Need to Provide:

Your base network must come from a network creation process (e.g., OpenStreetMap, cube network conversion) that establishes: 1. Topology - Nodes and links with proper connectivity 2. Facility classification - @ft values matching TM2 standards (1=freeway, 2=expressway, 3=ramp, 4=arterial, 5=collector, 6=local, 7=connector, 8=managed lane, 99=special) 3. Operating characteristics - @free_flow_speed, num_lanes
4. Access restrictions - @drive_link, @walk_link, @bus_only, @rail_link

Transit Network Requirements ¶

Required Base Scenario Attributes:

Transit networks should be created in their own Emme database, separate from highway. Required:

The transit network references the highway network through shared links. The prepare_transit_network component copies auto travel times from highway assignment results to update transit segment times.

What create_tod_scenarios Does:

For transit, create_tod_scenarios copies the base transit network to time-period-specific scenarios and sets up attributes like @schedule_time, @trantime_seg, but does NOT calculate transit times - that happens in prepare_transit_network using highway assignment results.

Create Time-of-Day Scenarios ¶

Component: create_tod_scenarios (runs first in iteration 0)

The create_tod_scenarios component creates time-of-day specific network scenarios in Emme from a single all-day base scenario. This component must run before any assignment can occur, as it establishes the fundamental network infrastructure for all time periods.

Time Periods ¶

The model operates with five distinct time periods:

Highway TOD Scenario Creation ¶

Volume Delay Functions (VDFs): The component sets up congestion functions that relate traffic volume to travel time:

Freeway VDFs (fd1, fd2):

BPR Formula: time = free_flow_time × (1 + 0.20 × ((volume/capacity)/0.75)^6)
Plus reliability factors based on Level of Service thresholds

Arterial/Road VDFs (fd3-fd7, fd9-fd14, fd99):

Akcelik Formula: time = free_flow_time + 60 × (0.25 × (v/c - 1 + sqrt((v/c - 1)^2 + ja × v/c)))
Plus reliability factors

Fixed Time (fd8): No congestion effects

Link Attributes Created:

• @area_type: Density-based area classification (0-5)
• 0: Regional core (density ≥ 300)
• 1: CBD (100 ≤ density < 300)
• 2: Urban business (55 ≤ density < 100)
• 3: Urban (30 ≤ density < 55)
• 4: Suburban (6 ≤ density < 30)
• 5: Rural (density < 6)

• Density = (1 × population + 2.5 × employment) / acres within 1-mile buffer

• @capclass: Capacity class = 10 × area_type + facility_type

• @free_flow_speed: Speed from capclass lookup table (mph)
• @free_flow_time: 60 × link_length / free_flow_speed (minutes)

Reliability Parameters: Congestion-based travel time reliability factors

Transit TOD Scenario Creation ¶

Transit Modes: Configured from model settings with attributes: - In-vehicle perception factor (default: 1.0) - Initial boarding penalty (default: 10 min) - Transfer boarding penalty (default: 10 min) - Headway fraction for wait time (default: 0.5) - Transfer wait perception factor (default: 1.0)

Transit Link Times:

Fixed guideway (calculated from link length and mode speed):

Bus on streets: time = 60 × length/speed + boarding_time

Transit Line Attributes: - @invehicle_factor: Mode-specific in-vehicle time perception - @iboard_penalty: Initial boarding time penalty - @xboard_penalty: Transfer boarding penalty - @orig_hdw: Original headway from schedule

Period Filtering: Transit lines only operate in their designated time periods. Lines with #time_period not matching the scenario period are removed.

Period-Specific Attribute Copying ¶

The component automatically handles time-of-day specific attributes:

1. Identifies TOD attributes: Finds all attributes ending with period names (e.g., @volume_EA, @volume_AM)
2. Creates period scenarios: Copies base scenario for each time period
3. Copies period values: Transfers period-specific values to non-suffixed attributes
4. Removes other periods: Deletes attributes for other periods to save memory

Example: For AM period scenario: - @volume_EA, @volume_MD, @volume_PM, @volume_EV → deleted - @volume_AM → copied to @volume → @volume_AM deleted

Coordinate Projection ¶

Networks are projected to NAD83(HARN) California State Plane Zone 6 (feet) if not already in this coordinate system. This ensures consistent spatial calculations for area type classification.

Runtime ¶

Typical execution time: 20-27 minutes (based on full regional model) - Highway scenarios: ~5-10 minutes - Transit scenarios: ~10-15 minutes
- Attribute processing: ~2-5 minutes

Highway Assignment ¶

Highway Assignment Overview ¶

The highway assignment component simulates vehicle route choice on the road network, accounting for congestion effects and traveler preferences for time, cost, and convenience.

Highway Assignment Features ¶

Multi-Class Assignment: Supports different vehicle types with distinct characteristics:

Equilibrium Algorithm: Uses Emme’s SOLA (Second Order Linear Approximation) algorithm for:

• Traffic Assignment: Route choice based on generalized cost minimization
• Convergence: Iterative process until stable flow patterns
• Volume-Delay Functions: Dynamic link travel times based on traffic volumes

Network Representation ¶

Geographic Coverage: 9-county San Francisco Bay Area Network Size: ~180,000 directional links, ~85,000 nodes (approximate - varies by model version) Temporal Resolution: Five time periods (AM peak, PM peak, midday, evening, early AM)

Link Attributes:

• Capacity: Maximum vehicle throughput
• Free-Flow Speed: Uncongested travel speed
• Volume-Delay Function: Congestion relationship
• Facility Type: Freeway, arterial, local, ramp
• Toll Information: Bridge tolls, express lane tolls
• Vehicle Restrictions: HOV requirements, truck restrictions

Generalized Cost ¶

Highway assignment uses value of time to convert monetary costs to time-equivalent units:

Value of Time in Highway Assignment - Detailed documentation of VOT parameters and implementation

Volume Delay Functions - Mathematical specifications for link travel time calculations

Components:

• Travel Time: Link-specific travel times (minutes)
• Distance Cost: Operating cost × distance (cents/mile)
• Toll Cost: Bridge tolls, express lane tolls (cents)
• Value of Time Conversion: $18.93/hour (2010 dollars)

Transit Assignment ¶

Transit Assignment Overview ¶

The transit assignment component simulates passenger route choice on the public transportation network, including buses, rail, ferry, and multi-modal connections.

Transit Assignment Features ¶

Capacity-Constrained Assignment:

• Initial Assignment: Unconstrained shortest path assignment
• Capacity Evaluation: Check vehicle capacity limits
• Crowding Effects: Increased perceived travel time for overcrowded vehicles
• Reassignment: Iterative process with capacity constraints

Multi-Modal Network:

Access/Egress Modes ¶

Walk Access: Direct walking to/from transit stops Drive Access: Park-and-ride facilities Kiss-and-Ride: Drop-off/pick-up access Bike Access: Bicycle access to transit (bike parking/bike-on-board)

Temporal Representation ¶

Service Periods: Coordinated with highway time periods Headway-Based: Frequent services represented by average wait times Schedule-Based: Lower frequency services with specific departure times

Level-of-Service Feedback ¶

Highway-Transit Integration ¶

Competitive Modes: Highway congestion affects transit competitiveness Park-and-Ride: Highway access costs influence transit ridership Cordon Pricing: Area-based tolls affect mode choice

CT-RAMP Integration ¶

Skim Generation: Assignment produces level-of-service matrices Accessibility Measures: Network performance influences activity location and mode choice Feedback Loops: Multi-iteration process between demand and assignment

Technical Implementation ¶

Software Platform ¶

Emme: Primary assignment platform

• Highway: SOLA traffic assignment algorithm (confirmed in code)
• Transit: Strategy-based transit assignment (uses OPTIMAL_STRATEGY)
• Integration: Python API for TM2 coordination

TM2 Python Framework:

tm2py/components/
├── network/
│   ├── highway/           # Highway assignment components
│   │   ├── highway_assign.py
│   │   ├── highway_maz.py  
│   │   └── highway_emme_spec.py
│   └── transit/           # Transit assignment components
│       ├── transit_assign.py
│       ├── transit_skims.py
│       └── transit_capacity.py

Performance and Scalability ¶

Computational Requirements (estimated based on typical model performance):

• Highway Assignment: ~15-30 minutes per time period (varies by network size and convergence criteria)
• Transit Assignment: ~10-20 minutes per time period (varies by service complexity and capacity constraints)
• Total Runtime: 2-4 hours for complete assignment set (including all time periods and iterations)
• Memory Usage: 8-16 GB RAM recommended (depends on network size and number of zones)
• Parallel Processing: Multi-core CPU utilization (configurable via emme.num_processors)

Validation and Calibration ¶

Highway Assignment Validation ¶

Traffic Counts: Comparison with observed link volumes Travel Time Validation: GPS-based travel time comparisons Toll Facility Usage: Express lane and bridge crossing validation

Transit Assignment Validation ¶

Ridership Counts: Operator-provided boardings data Load Profiles: Peak-direction, peak-period capacity utilization Transfer Patterns: Multi-operator journey validation

Configuration and Customization ¶

Assignment Parameters ¶

Convergence Criteria: Gap functions and iteration limits Volume-Delay Functions: Facility-specific congestion relationships
Value of Time: Mode and income-specific time valuations Capacity Constraints: Transit vehicle capacity and crowding effects

Scenario Analysis ¶

Infrastructure Projects: New facilities and capacity improvements Service Changes: Transit service modifications Pricing Policies: Tolling and fare policy evaluation Land Use Scenarios: Development pattern impacts

Related Documentation ¶

Technical Documentation ¶

• Highway Value of Time - VOT parameters and calculations
• Network Summary Component - Assignment result analysis
• Configuration Guide - Assignment parameter setup

Model Integration ¶

• CT-RAMP Overview - Demand model integration
• Model Workflow - Complete model execution process
• Outputs - Assignment result interpretation

Last Updated: November 2025
Model Version: Travel Model Two v2.2
Authors: MTC Staff & GitHub Copilot