A New Technique for Destination Choice TRB Planning Applications Conference Houston May 2009 William G. Allen, Jr., P.E. Transportation Consultant

Changes in Destination Choice Old: gravity model New: logit model Old: aggregate zone-zone totals New: individual tours Old: both productions and attractions constrained New: only productions constrained As part of the shift to tour-based models, destination choice models are changing Almost all 4 step models use the gravity model to allocate trips between zones Most tour-based models use a logit model to allocate individual trips Mathematically, these approaches aren’t as different as you might think One big difference between these 2 types of models is that in conventional models, both productions and attractions are constrained at the zone level But in most tour-based models, attractions are not constrained

Distribution Functions Gravity model Logit model For the record, here are the equations of the gravity and logit models I show this slide to point out that both functions say kinda the same thing: that the trips from zone i to zone j are a function of the attractiveness of zone j relative to the attractiveness of all zones

Discrete Tour-Based Models These are becoming popular Operate on individual trips (tours) Destination choice model creates tours Each tour is modelled individually Tour-based modeling is on the rise, as we all know Biggest difference with the new models is that they operate on individual tours, not aggregate zone-to-zone movements

Discrete Destination Choice Models Probability of trip from zone I going to zone J Correct number of trips leaving zone I Trips attracted to zone J may not match expectations No attraction model What if you want to estimate zonal attraction totals? The new destination choice models estimate the number of trip productions in a zone, usually with a tour frequency model Then they look at every individual origin and decide which destination zone it goes to After all trips are allocated, these models do NOT check to see that the number of trips attracted to each zone matches the initially estimated attractions This is because there ARE no initially estimated attractions Most tour-based advocates defend this by saying that our attraction models aren’t very good anyway But… what if you LIKE your attraction model, or for any reason, want to estimate a certain number of attractions in a zone? You can’t do that with most, if not all, tour-based models because they’re singly-constrained

Travel Probability Gravity calculations are normally aggregate But a gravity model can be applied in disaggregate fashion Probability of trip from zone I going to zone J Stochastic selection of attraction zone, similar to logit model Another thing that is “given” in the new models is that the destinations MUST be allocated using a logit model Maybe the logit model is superior for this purpose, but I haven’t seen anyone prove that yet What if you have a gravity model that you happen to really like, or for some reason, just want to keep using? Many people don’t realize that you can apply a gravity model to individual trips Now I’m not saying this would definitely give better results than a logit model, I’m just saying it can be done

New Methodology Conventional model is applied stochastically Use standard gravity formula to calculate probabilities Calculate trips in random order by P zone As trips are allocated, adjust attractions So that’s really what this presentation is all about I’m going to describe a way to use a doubly-constrained gravity function to allocate individual trips like a tour-based model This slide basically explains how to do it I’ll get into more details in a minute

Why do this? Maybe the attraction model is important Check on production total Jobs/housing balance Permits comparison of aggregate vs. discrete procedures Stepping stone towards advanced tour-based process Speed up existing model with many zones But first, we always have to have this slide: WHY? I’m sure all the tour-based advocates out there are saying that right now: Why would you want to do this? As I said, some planners LIKE having an attraction model and want their distribution process to match those numbers Some planners LIKE their gravity model This method could be used to do a pure comparison of conventional vs. the new procedures For some, this could be a reasonable step towards a tour-based model It is also a way to apply a conventional model differently, which could reduce running time and file size as you increase the number of zones in your area

Procedure Randomize production records by zone For each record, gravity model calculates probability of travel to all zones Allocate trip to destination zone J (Monte Carlo) Decrease remaining attractions in J by 1 Repeat until all trips are allocated to destinations So how does this procedure work? Here’s the way I have implemented it – I’m sure there are other variations The details are described in the paper The first step is to put all production records in random order by production zone – you need to do this in order to avoid geographic bias Then you use the gravity function to calculate the probability of travel to all zones Then use those probabilities to allocate a trip to one attraction zone, using the same Monte Carlo method as in all tour-based models Now, here’s the real secret to this process: you then reduce the number of attractions to the selected zone by 1, to make it slightly less attractive Then repeat the same process until all trips are allocated In this way you can match the initially estimated attractions in one pass – and don’t need multiple iterations

Software Conceptually simple, computationally not Scripting in Cube possible, but run time is long Faster in Fortran: 90 min to 13 min It’s relatively simple in concept, but requires a LOT of calculations I first wrote it in Cube, which was easy, but it ran a bit slowly There may be a way to shorten it in Cube, I don’t know I would guess it can be written using other software packages For this project, I re-wrote it in Fortran, which reduced the running time by a factor of 7

Real World Example Metropolitan Washington COG model of Commercial trips Separate models for I/I and external trips Simple trips, not tours Balanced trip ends by zone (orig. = dest.) 1,972 real internal zones Totals: 901K I/I, 63K external trips To test the idea, I found a real-world example The Washington area model of commercial trips This is not necessarily the best type of trip for this test, but it was available Washington area has almost 2000 zones 900,000 internal trips, 63,000 externals in 2005

Steps Normal trip generation Create 1 prod. record per trip, in random zone order Calculate Fij factors Allocate each prod. record to attr. zone Also run time of day in discrete fashion Build trip tables from trip records There was no change to conventional trip generation A step was added to create 900,000 production records, in random order by origin zone For each origin zone, run gravity model to get probability of trip going to each destination zone For each production record, look at the probabilities and allocate the trip to a destination Then go to the next record After completing the destination model, run the time of day model in the same discrete fashion to allocate the trip to a time period

Results Conventional and new trip tables are very similar Average trip lengths: old=25.87, new=25.96 Trip length distributions almost identical COM VMT: old=10.8 M, new=11.5 M Distribution takes longer, assignment is shorter It’s easy to compare this new approach with the conventional approach The average trip lengths almost the same Trip length distributions are also nearly identical – they’re shown in the paper Commercial trip VMT was a little higher The time to run the new distribution model is higher but assignment takes less time – however, on balance, the run time increased overall

Conclusions “New” destination choice method developed Destination choice step takes longer Results comparable to conventional method Easily expanded to other trip types Applying an aggregate model this way is a stepping stone to a discrete tour-based model I believe this is a fairly new technique – I couldn’t find anything similar in a literature search With this method, it definitely takes longer to run trip distribution, compared to the conventional type of model, but I think all discrete methods have that problem If you have a lot of zones, a discrete process may be more efficient for some things and may save running time in other steps This is one of the few examples I’ve seen that compares a conventional aggregate approach to a tour-based discrete approach, using the same data – and the results are encouraging This method may be something that encourages and facilitates the shift to a tour-based approach Questions?