TRANSPORTATION RESEARCH RECORD 1676 Paper No. 99-0912 37

With limited information and computational capability, travelers (espe-cially tourists) often fail to develop an itinerary that best suits theirneeds. A computer software program called Itinerary Planner was devel-oped to help travelers find a suitable itinerary by generating alternativetravel itineraries. Compared to existing trip planners, the Itinerary Plan-ner is unique in three aspects: (a) it considers multimodal itineraries; (b)it is capable of handling multiple constraints, including time windows forarrival and departure times, or mode constraints; and (c) the ItineraryPlanner adopts an interactive programming approach to identify the bestitineraries for the user. Through iterative interaction with the user, theplanner attempts to gauge the preferences the user has with respect toselected travel attributes (e.g., travel time and travel cost) and apply theresultant preference estimates to evaluate all feasible itineraries. A proto-type planner is developed for downtown San Francisco. It is demon-strated that the planner is capable of effectively generating alternativeitineraries for a tour that involves multiple trips and multiple modes,with complex constraints. Although the current prototype contains somelimitations, the planner prototype promises that it can be further devel-oped as a practical tool for itinerary planning. The planner presents a newway to save travel time, to relieve traffic congestion, and to encourage tran-sit use by helping travelers organize their trips in an efficient manner.

Travel constitutes an integral part of our daily lives. Only by travel-ing are we able to engage in a variety of activities distributed inspace. Because the extension of our travel is restricted by the amountof time that is available and the speed at which we can travel, it isimportant that our travel be efficiently organized so that we canmaximize the utility gained from conducting such a sequence of trips.

This goal is often hard to achieve because the problem is complex,with many constraints and conflicting criteria, and a sequence thatwould achieve the goal is often not obvious to the traveler, whosecomputational capability is limited. This has led to the conception ofa traveler information system called the Itinerary Planner, a computersoftware package that assists its user by proposing to him/her effi-cient itineraries for visiting multiple locations with a minimum wasteof time. Given the set of locations the user wishes to visit and the con-straints associated with the visits, the Itinerary Planner developsalternative itineraries for the user. If the user is not satisfied with anyitinerary, the planner adjusts weights that represent user preferencesand generates alternative itineraries. This process will be repeateduntil the user finds a satisfactory itinerary.

Another motivation underlying the development of the ItineraryPlanner is to create an information system that will encourage thetraveler to use public transit in a complex tour in which multiplelocations are visited. This is based on the beliefs that the availabil-ity of information affects the decision to use public transit in impor-tant ways and that people will make complex tours by public transitif they are shown that it is possible and convenient to do so (1).

To achieve the above goal, the planner must possess several fea-tures. First, it must accommodate multiple criteria. Travelers are mostlikely to consider more than one criterion at a time, and those criteria(e.g., travel cost and travel time) often conflict with each other in thesense that they cannot all be improved simultaneously. Second, itmust be multimodal. Tours may be made more efficiently by usingmultiple modes than using a single mode simply because selectingfrom multiple modes implies fewer constraints. Last, because differ-ent travelers have different preferences, and because even the sametraveler may have different preferences under different circumstances,the planner must be able to update weights that represent travelers’preferences intelligently. There is no travel planner in existence thatpossesses all of these three features. The goal of this effort is todevelop a travel planner that possesses these three features.

This paper, which documents the development of an ItineraryPlanner prototype, is organized as follows. The second section pro-vides an outline of the Itinerary Planner problem. In the third sec-tion, available algorithms are reviewed, and an alternative algorithmfor the planner is proposed. The actual development of the ItineraryPlanner is presented in the fourth section; the discussion covers theuser interface and the Planner Executor, as well as its limitations.The conclusion follows in the fifth section.

ITINERARY PLANNER OUTLINE

Two issues were raised during development of the Itinerary Planner.The first issue was what criteria the planner should use to select itin-eraries. A single criterion will not suffice in real-world situations. Inmost cases, travelers seek an itinerary that is balanced with respectto relevant criteria instead of an itinerary in which a single criterionis optimized—for example, the shortest travel time (but possiblywith a large monetary cost) or the lowest monetary cost (but with alarge amount of travel time). It was thus decided that the ItineraryPlanner must consider multiple criteria and trade-offs among themin selecting itineraries.

The second issue concerned constraints that may be associatedwith the visits for which trips are made. These constraints may beimposed by travelers themselves or exist as intrinsic attributes of aparticular visit. An example of the former would be the case in whicha traveler wants to visit several locations in a specific order; an exam-ple of the latter would be a bank that is open between 9 a.m. and 5 p.m. only. It is important to note that different types of constraintsoften co-exist.

A visit to a location might be subject to a class of constraints,called “time of day” constraints. The arrival time at a location mightbe constrained to a certain time window. This can be expressed as(ai, bi), where ai refers to the earliest possible arrival time at the ithlocation, and bi refers to the latest possible arrival time. Similarly,

Multimodal Daily Itinerary PlannerInteractive Programming Approach

CYNTHIA CHEN, RYUICHI KITAMURA, AND JIAYU CHEN

Institute of Transportation Studies, University of California-Davis, Davis,CA 95616.

the departure time from a location might be constrained to a timewindow, which can be expressed as (ci, di), where ci refers to the ear-liest possible departure time, and di refers to the latest possibledeparture time from the ith location. In the prototype development,only earliest arrival time and latest departure time were incorporated.

The duration at a location might be constrained to a time intervalas well, expressed as (dli, dui), where dli refers to the possible min-imum duration, and dui refers to the possible maximum duration at theith location. Duration constraints, along with time of day constraintsand sequencing constraints, determine a set of feasible solutions.

ALGORITHM DEVELOPMENT

In the planner problem, an itinerary for visiting multiple locationsis sought such that it best satisfies the user. Suppose that the user’ssatisfaction can be represented by a preference function, namely:

where

V = level of satisfaction of the user,xi = ith attribute of an itinerary, andβi = relative importance of the ith attribute, called preference

weight.

Thus, the optimal solution that maximizes the above preferencefunction is sought in the planner problem. The problem, however, isnot a simple optimization problem for which one can set the firstderivative equal to zero and calculate the values of decision vari-ables at which the objective function is maximized. Instead, it is acombinatorial problem with unknown preference weights and there-fore has an unknown objective function. The difficulty involved inthe problem is twofold: first, there is no procedure by which thiscombinatorial problem can be analytically solved; and second, thecoefficients of the preference function (i.e., preference weights)need to be identified as part of the solution.

Relation to TSP Problems

The planner problem is very similar to a typical Traveling Sales-man Problem (TSP). A literature review in the area of TSP algorithms(2) indicated that all TSP algorithms, exact or approximate, weredesigned to optimize a single objective. Given a set of locations to visitin a network and a travel time/cost matrix associated with the network,a TSP algorithm attempts to find the optimal visit sequence with aminimum travel time or a minimum cost. A unique optimal solutionusually exists when only one objective is considered. However, thisis not exactly the case with the Itinerary Planner problem, in whichthere exist more than one criterion that often conflict with each other.

Even if there were one single objective to be achieved, the multi-plicity of the constraints that were considered in the planner prob-lem would make direct application of TSP algorithms difficult. Mostof the TSP algorithms reviewed here incorporate only one type ofconstraint: for example, time windows (3,4), or a priori orders ofvisits (5), but not both.

More importantly, as noted at the beginning of this section, val-ues of preference weights are not known. TSP algorithms mostlyignore the possibilities that different people have different prefer-ence weights and that the same individual may have different

V f xi i= ( )β

38 Paper No. 99-0912 TRANSPORTATION RESEARCH RECORD 1676

preference weights under different circumstances. It was thus con-cluded that existing TSP algorithms are not directly applicable to theItinerary Planner problem and that an alternative algorithm must bedeveloped specifically for the Itinerary Planner.

Proposed Algorithm

To identify a best itinerary, it was decided that an exact (as opposedto an approximate) algorithm be used in the Itinerary Planner. Anexact algorithm is needed due to the limited number of visit locationsthat is typically involved in a planner problem; it would be rather rarefor a traveler to visit a large number of locations that would imposecombinatorial problems in the solution process. In the algorithm, allalternative sequences of the set of locations to be visited are gener-ated, and, using the preference function that was defined earlier, thegeneralized cost of each sequence is evaluated for each possible com-bination of travel modes to travel between visit locations. The bestroute is identified between every pair of visit locations for each modeusing Dijkstra’s algorithm. Values of the preference weights must beestablished before Dijkstra’s algorithm can be performed.

In problems involving multiple criteria, many of which are con-flicting with each other, a dominant solution (a solution that is supe-rior to other solutions in all aspects) often does not exist. Instead, aset of nondominant solutions exists. The goal is to find the com-promise solution that best satisfies the user or that maximizes theuser’s preference function. Three types of approaches have beenidentified in the literature to locate the best compromise solutionwhen user preferences are unknown (6). The first is to obtain theuser’s preference function before commencing problem solving;the second is to enumerate all nondominant solutions and presentthem to the traveler; and the third is the interactive approach, whichis to obtain the user’s preference information progressively duringthe problem-solving process.

Among all three approaches, the interactive method has been foundpromising in multiple-objective problems (7–9). The interactivemethod was therefore proposed for the Itinerary Planner. More specif-ically, an interactive, multiple-objective mathematical programming(MOMP) procedure was adopted. Interactive MOMP procedures

. . . attempt to generate a best-compromise solution by progressivearticulation of preferences of a decision maker facing multiple criteriawith complex trade-offs. . . . The goal is to create a computationallyefficient decision aid which puts the information provided to and solicitedfrom the decision maker (DM) in a form that is easy to understand andprovide (10).

Considering that the search for best solutions in each iterationinvolves quite a number of alternative sequences of the visit loca-tions and combinations of travel modes, the authors determined thatthe interaction method to identify the user preferences must besimple and must not require much computational time. A survey ofavailable interaction methods in the literature (6), however, sug-gested that direct application of these methods would require sub-stantial computational time and would place a considerable amountof burden on the user.

Therefore, the authors decided to devise a simple algorithm toupdate the user’s preference weights during problem solving. Usinginitial weights established in a previous study (11), the plannerfirst selects two alternatives with the highest and second-highestpreference function values. Then the planner asks the user to selectthe one he/she prefers more. Next, the planner compares the values

Chen et al. Paper No. 99-0912 39

of each attribute between these two alternatives and doubles theweight if the attribute value of the preferred route is less than thatfor the other route and halves the weight if the attribute value of thepreferred route is greater than that for the other route.

This procedure is repeated with a new set of itineraries selectedwith the new set of weights. This approach is adopted because (a) itdoes not require extensive inputs from the user to establish a pref-erence function, and (b) the preference function is refined inter-actively as the user continues to search for better itineraries; thus,more refined preference valuations will be adopted for those userswho are willing to search extensively for a better itinerary.

PROTOTYPE DEVELOPMENT

This section describes the development of the Itinerary Planner.The assumptions used in the planner are first presented, followedby the description of the user interface. The core of the ItineraryPlanner—the Planner Executor—is then described.

Assumptions

Two major assumptions are introduced to create a working prototypeof the Itinerary Planner. The first assumption is that only one modeis used between two consecutive activity locations. In other words,although the itinerary as a whole is multimodal (which could involveprivate automobile, public transit, taxi, or walking), each trip withinit can be made only by a single mode. Note that a combination ofwalking and public transit is considered as one mode. Thus, a trip thatcomprises three legs of walking-bus-walking is included, while theplanner excludes the combination of automobile and bus.

The second assumption is that all visit locations are hard locationswhose geographical locations are precisely specified (as opposed toa soft location, which refers to a general class of opportunities suchas a bank or a grocery store). This assumption has been introducedto simplify coding and to reduce data requirements. The user is freeto choose any point on the map as an activity location to visit.

User Interface

The user interface includes both user inputs and outputs from theplanner to the user.

User Inputs

User inputs comprise the following:

• Source (starting point of an itinerary),• Attributes of a visit (repeated as necessary),

–Location,–Timing constraints, and–Duration constraints,

• Sink (ending point of an itinerary),• Sequencing constraints, and• Mode preferences.

Source (Starting Point of an Itinerary)

The planner first asks the user to indicate the source of his or heritinerary (in the prototype, the source is assumed to be one of eight

fixed kiosks located in the study area). Then time-of-day constraints(e.g., earliest and latest departure time from the source) associatedwith the source are obtained from the user.

Attributes of a Visit

Next, attributes of a visit are obtained from the user. These attri-butes include location, time of day, and duration. A user can spec-ify a location by either giving an exact street address or clicking onthe map directly. The exact street address is most precise, but theuser may not always know it. Another option is to specify activitylocations by clicking directly on the map on the screen. This optionis feasible only when the user can tell the location on the map. If theuser knows where it is, then clicking on the map or touching thescreen to pinpoint the location might be the easiest and the fastestmethod. Specifying a location by crossroads or landmarks is notavailable in the current Itinerary Planner prototype.

The user is prompted to input the earliest arrival time and the lat-est departure time that are acceptable for each activity. They formthe time-of-day constraints that are associated with the activity.Similarly, the user is prompted to input duration constraints (i.e., theminimum and/or maximum duration that can be allowed for eachactivity). If the user has no constraints associated with an activity,the prompts can be ignored.

Sink (Ending Point of an Itinerary)

Information obtained from the user about the sink is similar to thatobtained for a visit, except that duration constraints are not appli-cable. Time-of-day constraints associated with the sink are the ear-liest possible arrival time and the latest possible arrival time.Again, no input is made if the user has no constraints associatedwith the sink.

Sequencing Constraints

Sequencing constraints refer to the requirement that a set of visitlocations must be visited in a particular order. For each activity loca-tion, the planner asks the user to indicate location(s) that must bevisited before or after that location.

Mode Preferences

Users can specify their mode preferences in the planner prototypeby indicating the modes they prefer not to use or those that are notavailable to them.

Outputs to the user consist of two itineraries selected by the plan-ner. These itineraries are presented on a map. The activity locationsare labeled, and routes connecting them are highlighted on the map.Travel modes are designated on the map by different colors. Theplanner also produces written directions that show (a) the travel modeto use and where to ride the mode, (b) how long to travel by eachmode, (c) public transit route number/name, and (d) the location totransfer to (if applicable).

Planner Executor

Figure 1 illustrates how the Itinerary Planner functions. Step 1 isthe user inputs; the user supplies information on the locations to

40 Paper No. 99-0912 TRANSPORTATION RESEARCH RECORD 1676

repeats operations from Step 2. The operation repeats until the userfinds a satisfactory itinerary.

Dijkstra’s Algorithm

More than one route, in general, exists between two activity loca-tions. Dijkstra’s algorithm is performed to locate the best routebetween two activity locations by mode (for the four modes men-tioned earlier—private automobile, public transit, taxi, and walking).The preference function, by which a “best” route is identified, isin the prototype defined as a weighted sum of seven route attributes:travel cost, taxi/auto travel time, bus travel time, cable-car traveltime, waiting time, walking time, and number of transfers. As notedearlier, the preference weights are applied to these seven attributesto form a preference function value, which may be viewed as a typeof generalized cost.

Generation of All Possible Sequences of Mixed Modes

The search for an optimum itinerary by the planner involves the enu-meration of all possible sequences of visit locations using all possi-ble combinations of travel modes. Sequences are generated withand without the private automobile involved. With an automobileinvolved, the itinerary can be made by a combination of auto, walk-ing, and public transit, but not taxi, primarily to reduce computationalrequirements. Without the automobile involved, the remaining threemodes—taxi, walking, and public transit—are considered.

The planner takes into account the requirement that, when a trav-eler parks a private automobile and uses another mode, the privateauto must be picked up later. For a particular sequence involving Nlocations (including the source and sink), Table 1 shows the num-ber of mode sequences. As shown in the table, the number of modesequences increases rapidly with N. The maximum N that can beincorporated in the current Itinerary Planner prototype is eight or sixactivity locations, excluding the source and sink.

Without a private auto involved, there are 3N−1 mode sequencesfor each sequence of activity locations. Thus, in cases with no autoinvolved, there will be (N − 2)! × 3N−1 sequences to evaluate.

Feasibility Check

The feasibility check performed by the planner is concerned with thetiming and duration constraints, as well as sequence constraints. Tim-ing and duration constraints imply that, for any two consecutive loca-tions in a sequence, the latest possible departure time at the latterlocation must be greater than or equal to the sum of the earliest pos-sible departure time at the former location plus the travel time fromthe former location to the latter location plus the minimum durationat the former location.

visit and constraints associated with each visit. In Step 2, the plannerlocates the nearest nodes to the activity locations selected by theuser, finds the best route between every possible pair of activitylocations (i.e., the route that produces the maximum-preferencefunction value), and stores the results in a temporary database. InSteps 3 through 5, the planner enumerates all possible sequences,computes travel time for each visit, and checks the feasibility ofevery sequence against the time-of-day, duration, and sequenceconstraints. In Step 6, the planner evaluates the generalized costof every feasible sequence and selects two itineraries with lowestand second-lowest generalized costs. The user is then promptedto indicate if he/she is satisfied with one of the itineraries. If theuser is not satisfied with either itinerary, he/she is then asked toindicate which of the two is more preferred. The planner thenupdates the preference weights based on the user response and

FIGURE 1 Flowchart of Planner Executor.

TABLE 1 Number of Mode Sequences with Auto Involveda

Calculation of Preference Function Values

The next step is to calculate the generalized cost, or the value ofthe preference function, for each feasible sequence, and select theitineraries with the highest and second-highest values. These twoitineraries are then presented to the user. As noted earlier, theuser is then asked whether he or she is satisfied with either itinerary.If not, the planner will update the preference weights and go throughanother iteration. When the user is satisfied, the planner will terminateits operation.

Example

Suppose that the user indicates to the planner the set of locationsto visit and constraints associated with each visit, as shown inTable 2. In addition, suppose the user also indicates that the work-place must be visited before the grocery store, which must be vis-ited before the movie theater. The user did not impose any modeconstraints. (For values assumed for travel speed by mode, transitwaiting time, parking cost, and other trip attributes, contact theauthors.)

The planner produced two itineraries as output. The sequence ofvisits is the same for both itineraries:

Union Square → workplace → lunch place → grocery store →movie theater → home

Chen et al. Paper No. 99-0912 41

Other output attributes for both itineraries are shown in Tables 3and 4, respectively.

Suppose that, given the initial two itineraries, the user indi-cated that he/she preferred the second itinerary because the sec-ond choice had lower in-vehicle travel time, waiting time, andwalking time, as well as a smaller number of transfers, althoughit had a higher cost compared to the first choice. The plannerthen took the inputs, updated the weights, and produced anotherset of two itineraries. The two revised itineraries again have anidentical sequence of visits. Their output attributes are shown inTables 5 and 6.

The planner updated the preference weights in a manner that wasconsistent with our expectation. The feedback from the user after thefirst iteration (the user preferred the second itinerary with a highercost but less travel time) indicated that the initial weight on traveltime was too low, and the initial weight on travel cost was too high.For the second iteration, the planner increased the weight on traveltime and lowered the weight on travel cost. The itineraries producedat the second iteration reflect this adjustment.

Limitations

The current prototype was developed for downtown San Francisco.Its database for the streets in downtown and its peripheral areasincludes more than 3,000 street links and 10 bus lines coded ondifferent streets in the area. The planner prototype is computation-

TABLE 3 Itinerary Attributes of Itinerary 1 (1st Iteration)

TABLE 2 User Inputs (Example)

TABLE 4 Itinerary Attributes of Itinerary 2 (1st Iteration)

ally practical on a network of this size. For the above example, on a266-MHz Pentium II PC, it took about 1 s for the Planner Executorto locate the two itineraries and took about 5 s for the user interfaceto display the two itineraries. With six activity locations (the maxi-mum number of activity locations allowed in the current prototype),it took about 7 s for the Planner Executor to locate the two bestitineraries. The display time does not increase with the number ofactivity locations.

The planner is limited in several aspects that are mostly relatedto the algorithm development. Regarding the algorithm for prefer-ence weight updating adopted in the planner, the interactive MOMPprocedure may not converge to true values in the end. Convergenceto true values requires that the user be consistent throughout theproblem-solving process (6). This can be considered a seriousdrawback of interactive MOMP procedures (12). Inconsistenciesthat may be exhibited by the user during decision making can bereduced by presenting him/her with easy and simple questions (6).The question about convergence, however, is not fully investigatedin this study and certainly deserves future research. Another limi-tation is that the current planner prototype cannot incorporate softlocations. This limitation is primarily due to the lack of databasesto accommodate soft locations.

CONCLUSIONS

The Itinerary Planner is one of the first travel planners that incor-porates multiple destinations, multiple criteria and constraints, andmultiple modes of travel. [For a review of existing trip planners priorto the development of the Itinerary Planner, see the Kitamura andChen report (13).] It is also one of the first travel planners that bringsthe user into the decision-making process and updates the user pref-erence weights interactively. The planner prototype was developedfor a relatively small test area of downtown San Francisco. Con-sequently, its usability remains to be tested in larger areas. In

42 Paper No. 99-0912 TRANSPORTATION RESEARCH RECORD 1676

addition, there are still several limitations associated with the cur-rent prototype; these limitations certainly call for future research.Nevertheless, the planner presents a new way to save travel time,relieve traffic congestion, and encourage transit use by helpingtravelers organize their trips in an efficient manner.

ACKNOWLEDGMENTS

This work was completed under a grant from the California PATH(Partners for Advanced Transit and Highways). The authors greatlyappreciate such support. This work also benefited from the help ofKen Kurani at the University of California-Davis.

REFERENCES

1. Abdel-Aty, M., R. Kitamura, and P. Jovanis. Investigating Effect ofAdvanced Traveler Information on Commuter Tendency to Use Transit.In Transportation Research Record 1550, TRB, National ResearchCouncil, Washington, D.C., 1996, pp. 65–72.

2. Laporte, G. Recent Algorithmic Developments for the Traveling Sales-man Problem and the Vehicle Routing Problem.Université de Montreal,Centre de Recherche sur les Transports, Montreal, Quebec, Canada,1993.

3. Gendreau, M., A. Hertz, G. Laporte, and M. Stan. A Generalized Inser-tion Heuristics for the Traveling Salesman Problem with Time Win-dows.Université de Montreal, Centre de Recherche sur les Transports,Montreal, Quebec, Canada, 1995.

4. Solomon, M., and J. Desrosiers. Time-Window-Constrained Routingand Scheduling Problems. Transportation Science,Vol. 22, No.1, 1988,pp. 1–13.

5. Gendreau, M., G. Laporte, and J. Potvin. Heuristics for the ClusteredTraveling Salesman Problem.Université de Montreal, Centre deRecherche sur les Transports, Montreal, Quebec, Canada, 1994.

6. Shin, W., and A. Ravindran. Interactive Multiple Objective Optimiza-tion: Survey 1—Continuous Case. Computers & Operations Research,Vol. 18, No. 1, 1991, pp. 97–114.

TABLE 6 Itinerary Attributes of Itinerary 2 (2nd Iteration)

TABLE 5 Itinerary Attributes of Itinerary 1 (2nd Iteration)

7. Evans, G. An Overview of Techniques Solving Multi-Objective Math-ematical Programs. Management Science,Vol. 30, No. 11, 1984, pp. 1268–1282.

8. Klein, G., H. Moskowitz, and A. Ravindran. Comparative Evaluationof Prior versus Progressive Articulation of Preference in BicriterionOptimization. Naval Research Logistics Quarterly,Vol. 33, 1986, pp. 309–323.

9. Korhonen, P., H. Moskowitz, J. Wallenius, and S. Zionts. An Inter-active Approach to Multiple-Criteria Optimization with Multiple Deci-sion Makers. Naval Research Logistics Quarterly,Vol. 33, 1986, pp. 589–602.

10. Aksoy, Y., T. Butler, and E. Minor. Comparative Studies in InteractiveMultiple-Objective Mathematical Programming. European Journal ofOperational Research,Vol. 89, No. 2, 1996, pp. 408–422.

Chen et al. Paper No. 99-0912 43

11. Train, K. A Post-BART Model of Mode Choice: Some SpecificationTests.University of California, Institute of Transportation Studies,Berkeley, 1976.

12. French, S. Interactive Multiple-Objective Programming: Its Aims, Appli-cations, and Demands. Journal of the Operational Research Society,Vol.35, No. 9, 1984, pp. 827–834.

13. Kitamura, R., and C. Chen. Multimodal Daily Activity Travel Plan-ner. Final report. Institute of Transportation Studies, University ofCalifornia-Davis, 1998.

Publication of this paper sponsored by Committee on Traveler Behaviorand Values.