USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS AMPO TRAVEL MODEL WORK GROUP October 23, 2006

Baltimore Metropolitan Council

USING SUMMIT FORUSING SUMMIT FORTRANSIT AND MODEL ANALYSIS TRANSIT AND MODEL ANALYSIS

AMPO

TRAVEL MODEL WORK GROUP

October 23, 2006


Summit SoftwareSummit Software

• Developed by Federal Transit Administration

• Measures “user benefits” of differences between transportation networks

• Runs under DOS/Command Prompt window

• Control file specifies inputs and outputs• Version 0.994a


Summit CapabilitiesSummit Capabilities

• Summarize and compare trip tables through district-to-district aggregation and reporting

• Summarize and compare zone attributes through district-to-district aggregation and reporting

• Generate GIS mapable outputs

User’s Guide to Summit, summit_user_16.doc, FTA


Finding Problems Using the Summit Finding Problems Using the Summit ProgramProgram

• Compares two scenarios• Does not pinpoint model problems• Can identify zones with problems or

inconsistencies between scenarios• User intervention required to find actual

cause


Summit InputsSummit Inputs

• Trips• Exponentiated auto utility• Share of zone in Can Walk area• Transit share of Can Walk area• Share of zone in Must Drive area• Transit share of Must Drive area


Logit Model and SummitLogit Model and Summit• Utility for a mode determined by C1V1 + C2V2 +

… + CnVn + K• Utility exponentiated (eU)• Non-transit exponentiated utility passed to

Summit• Transit utility can be calculated by non-transit

exponentiated utility and transit share • Equivalent time calculated by dividing the

utility by the in-vehicle time coefficient• Time difference times number of trips yields

user benefits


Transit MarketsTransit Markets

• TAZ 30• 83% Walk

• TAZ 552• 38% Walk

• Can Walk Area• .83 x .38=31.54%

• Must Drive Area 30→552• (1-.83) x .38=6.46%

• Must Drive Area 552 →30• (1-.38) x .83=51.46%

• No Transit Area 30→552• 1-.3154-.0646=62.00%

• No Transit Area 552→30• 1-.3154-.5146=17.00%


Summit CalculationsSummit Calculations

• Divide trips into nine markets (Can Walk, Must Drive, No Transit → Can Walk, Must Drive, No Transit)

market %

Build

Can WalkMust Drive

No Transit Total

Base

Can Walk 37.5% 0.0% 0.0% 37.5%

Must Drive 12.5% 0.0% 0.0% 12.5%

No Transit 25.0% 0.0% 25.0% 50.0%

Total 75.0% 0.0% 25.0% 100.0%


Summit Calculations (Continued)Summit Calculations (Continued)• Calculate non-transit price change (equivalent

minutes)

• Calculate transit utilities and price change

IVT

U

IVT

U

C

e

C

e NTBaseNTBuild )ln(_

)ln(

)11

(

TM

UU

P

ee

NT

TM

IVT

U

IVT

U

C

e

C

e TMBaseTMBuild )ln(_

)ln(


Summit Calculations (Continued)Summit Calculations (Continued)

• Calculate total price change

• Calculate user benefits (price change x trips) for all modes

IVT

UU

IVT

UU

C

ee

C

ee TMBaseNTBaseTMBuildNTBuild )ln()ln(


Summit Calculations (Continued)Summit Calculations (Continued)

• Calculate transit user benefits (total user benefits times transit’s share of exponentiated utility difference)

)()( NTBaseNTBuildTMBaseTMBuild

TMBaseTMBuild

UUUU

UU

eeee

ee


Summit InputSummit Input

• Summit reads binary files• Sample data converted to text:

Inc Per Trips A/T Trips Auto Eu Can Walk % CW Tr Shr Must Drv % MD Tr Shr

1 0.10286835 0.10286835 0.55187620 0.31540000 0.49425589 0.06460000 0.00094337

2 0.11026155 0.11026155 0.53926151 0.31540000 0.49207123 0.06460000 0.05305123

3 0.47601062 0.47601062 0.53001270 0.31540000 0.19431005 0.06460000 0.02449020

4 0.29271898 0.29271898 0.52105541 0.31540000 0.00070117 0.06460000 0.00020188


Summit OutputsSummit Outputs

• Report file• Row/column sums for all working tables• District-district reports• Row/column values for selected tables

and zones• Row/column totals for selected tables• Trip-length frequency• Stratified trip tables


User BenefitsUser Benefits zone rs5 cs5 1 15967 762 2 6869 34 3 15072 104 4 7187 121 5 1265 26 6 1509 30 7 7593 84 8 14801 671 9 6446 46 10 3236 51 11 6123 152 12 4892 7 13 7167 18

• User-defined Table 5 is output with the row and column sums for each TAZ

• These are equivalent person-minutes of user benefits

• These data can be imported into a GIS program to produce maps


Mode Choice StructureMode Choice Structure

(B)CRail

(B)Rail

Bus

(B)Drive

(B)CRail

(B)Rail

Bus

Walk

(B)Transit

DA

(B)SR3+

SR2

(B)SR

Auto

Person

Baltimore Metropolitan CouncilMode Choice Model Structure

Legend

SR=Shared RideDA=Drive AloneCRail=Commuter Rail(B)=Carries Bias Coefficent


Mode Choice IssuesMode Choice Issues

• Mode choice with multiple modes can be very sensitive to slight changes

• Paths built for six access/mode combinations:• Walk Bus• Walk Rail• Walk Commuter Rail• Drive Bus• Drive Rail• Drive Commuter Rail


Mode Choice Issues (Continued)Mode Choice Issues (Continued)

• Modes are favored/disfavored for pathbuilding by factoring time to a perceived time

• Sometimes non-favored modes still win in the pathbuilding• Loss of the favored mode/access combination

• Newer software developments will require favored mode to be in a path (if available), but this has not yet been implemented



• Mode-specific weighting factors are not included in mode choice calculations• This causes situations where shorter

perceived times in the build scenario are actually longer, leading to a loss of UB

• This is standard practice but under discussion with FTA



• Mode choice calculations for three areas• Can Walk includes auto, walk transit, drive

transit nests

• Must Drive includes auto, drive transit nests

• No Transit includes only auto nest

• Pathbuilding uses actual walk times; skims use zonal defaults for each mode–path changes can cause some surprising results


Finding ProblemsFinding Problems

• Find zones with large, unexpected UB changes

• Find corresponding zone in a zone pair with large absolute UB change

• Examine mode choice calculations for that zone pair

• Examine transit skims for that zone pair• Trying to explain UB change can point

out problems


User Benefit MapUser Benefit Map–Productions–Productions

1

2


User Benefit MapUser Benefit Map–Attractions–Attractions

3


Problems NotedProblems Noted

1. When Red Line (Rail) is Built, the Drive to Commuter Rail path is lost–Red Line is more attractive even with mode weighting. DC constant disappears. Transit utility drops, producing a loss of user benefits.

2. Quirk in walk access program adds slightly longer (4.8 Second) Walk Rail time to build. While small, when multiplied by a large number of trips, there is a significant loss of user benefits.


Problems Noted (Continued)Problems Noted (Continued)

3. Adding Red Line switches Walk Rail path to a longer path that is perceived as shorter because of mode favoring. This decreases the transit share and user benefits of the build scenario for trips to these zones


Additional Problems Indicated by Additional Problems Indicated by SummitSummit

• Adding a rail line can show loss of benefits with improper zonal access to rail (requiring a bus transfer in the corridor)

• Found some unrealistically high mode-specific bias constants–gaining or losing that path produces an unrealistically large change in UB


Additional Problems Indicated by Additional Problems Indicated by Summit (Continued)Summit (Continued)

• Updated access links for one scenario and not the other causing unusual UB change

• Found an error in the script where commuter rail walk egress time was included in rail walk time

• Factors applied at wrong nesting level produced strange transit shares


Additional Problems Indicated by Additional Problems Indicated by Summit (Continued)Summit (Continued)

• We were using an attraction-end accessibility measure• Some path shifts would change accessibility to

one zone

• Unexpected and illogical UB changes resulted

• Eventually scrapped accessibility


Capped User BenefitsCapped User Benefits

• Transit price change for Can Walk→Can Walk and Must Drive→Must Drive trips is capped at ±45 minutes

• Large price change for same market can indicate problems with model (extreme coefficients and constants, coding errors)


Capped User Benefits ExampleCapped User Benefits Example

• Compound error here• Found a path where a network error allowed

building the Red Line to lose a Walk to Commuter Rail path

• Walk to Commuter Rail had a bias constant of 10

• Losing this path causes loss of the bias constant

• At lowest level nest, this is equivalent to 1250 minutes of time savings.


ConclusionsConclusions

• Summit has proven itself a quite useful tool for analyzing networks and mode choice models

• It helps the user catch errors that may have been overlooked in the past

• Using Summit requires staff familiarity with the inner workings of the mode choice model

Documents

USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS AMPO TRAVEL MODEL WORK GROUP October 23, 2006