ampo travel model work group october 23 2006 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS PowerPoint Presentation
Download Presentation
USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS

Loading in 2 Seconds...

play fullscreen
1 / 30

USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

AMPO TRAVEL MODEL WORK GROUP October 23, 2006. USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS . Summit Software. Developed by Federal Transit Administration Measures “user benefits” of differences between transportation networks Runs under DOS/Command Prompt window

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'USING SUMMIT FOR TRANSIT AND MODEL ANALYSIS' - noam


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ampo travel model work group october 23 2006
AMPO

TRAVEL MODEL WORK GROUP

October 23, 2006

USING SUMMIT FORTRANSIT AND MODEL ANALYSIS

summit software
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
summit capabilities
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

finding problems using the summit program
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
summit inputs
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
logit model and summit
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
transit 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%

Transit Markets
summit calculations
Summit Calculations
  • Divide trips into nine markets (Can Walk, Must Drive, No Transit → Can Walk, Must Drive, No Transit)
summit calculations continued
Summit Calculations (Continued)
  • Calculate non-transit price change (equivalent minutes)
  • Calculate transit utilities and price change
summit calculations continued10
Summit Calculations (Continued)
  • Calculate total price change
  • Calculate user benefits (price change x trips) for all modes
summit calculations continued11
Summit Calculations (Continued)
  • Calculate transit user benefits (total user benefits times transit’s share of exponentiated utility difference)
summit input
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

summit outputs
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
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

User Benefits
mode choice issues
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
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 choice issues continued18
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
mode choice issues continued19
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
finding problems
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
problems noted
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.
problems noted continued
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
additional problems indicated by summit
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
additional problems indicated by summit continued
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
additional problems indicated by summit continued27
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
capped user benefits
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)
capped user benefits example
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.
conclusions
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