USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS

1
USING SUMMIT FORTRANSIT AND MODEL ANALYSIS

• AMPO
• TRAVEL MODEL WORK GROUP
• October 23, 2006

2
Summit 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

3
Summit 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
• Users Guide to Summit, summit_user_16.doc, FTA

4
Finding Problems Using the Summit Program

• Compares two scenarios
• Does not pinpoint model problems
• Can identify zones with problems or
  inconsistencies between scenarios
• User intervention required to find actual cause

5
Summit 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

6
Logit 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

7
Transit Markets

• TAZ 30
• 83 Walk
• TAZ 552
• 38 Walk
• Can Walk Area
• .83 x .3831.54
• Must Drive Area 30?552
• (1-.83) x .386.46
• Must Drive Area 552 ?30
• (1-.38) x .8351.46
• No Transit Area 30?552
• 1-.3154-.064662.00
• No Transit Area 552?30
• 1-.3154-.514617.00

8
Summit Calculations

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

9
Summit Calculations (Continued)

• Calculate non-transit price change (equivalent
  minutes)
• Calculate transit utilities and price change

10
Summit Calculations (Continued)

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

11
Summit Calculations (Continued)

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

12
Summit 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
13
Summit 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

14
User 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

15
Mode Choice Structure
16
Mode 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

17
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

18
Mode Choice Issues (Continued)

• 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

19
Mode Choice Issues (Continued)

• 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 modepath changes can
  cause some surprising results

20
Finding 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

21
User Benefit MapProductions
1
Sample
2
22
User Benefit MapAttractions
Sample
3
23
Problems Noted

• When Red Line (Rail) is Built, the Drive to
  Commuter Rail path is lostRed Line is more
  attractive even with mode weighting. DC constant
  disappears. Transit utility drops, producing a
  loss of user benefits.
• 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.

24
Problems Noted (Continued)

• 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

25
Additional Problems Indicated by Summit

• 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 constantsgaining or losing that path
  produces an unrealistically large change in UB

26
Additional Problems Indicated by 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

27
Additional Problems Indicated by 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

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

29
Capped 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.

30
Conclusions

• 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