USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS

1. AMPO TRAVEL MODEL WORK GROUP October 23, 2006 USING SUMMIT FORTRANSIT AND MODEL ANALYSIS

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 User’s 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. 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% Transit Markets

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 transit’s 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. 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 User Benefits

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 mode–path 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 Map–Productions 1 Sample 2

22. User Benefit Map–Attractions Sample 3

23. Problems Noted • 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. • 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 constants–gaining 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