A Web Application for Recommending Personalized Mobile Tourist Routes
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

A Web Application for Recommending Personalized Mobile Tourist Routes

on

  • 630 views

 

Statistics

Views

Total Views
630
Views on SlideShare
586
Embed Views
44

Actions

Likes
1
Downloads
7
Comments
0

2 Embeds 44

http://nguyentantrieu.info 26
http://mc2ads.com 18

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

A Web Application for Recommending Personalized Mobile Tourist Routes Document Transcript

  • 1. www.ietdl.org Published in IET Software Received on 3rd September 2011 Revised on 23rd December 2011 doi: 10.1049/iet-sen.2011.0156 ISSN 1751-8806Web application for recommending personalisedmobile tourist routesD. Gavalas1 M. Kenteris1 C. Konstantopoulos2 G. Pantziou31 Department of Cultural Technology and Communication, University of the Aegean, Mytilene, Greece2 Department of Informatics, University of Piraeus, Piraeus, Greece3 Department of Informatics, Technological Educational Institution of Athens, Athens, GreeceE-mail: dgavalas@aegean.grAbstract: This study deals with the problem of deriving personalised recommendations for daily sightseeing itineraries fortourists visiting any destination. The authors’ approach considers selected places of interest that a traveller would potentiallywish to visit and derives a near-optimal itinerary for each day of visit; the places of potential interest are selected based onstated or implied user preferences. The authors’ method enables the planning of customised daily personalised touristitineraries considering user preferences, time available for visiting sights on a daily basis, opening days of sights and averagevisiting times for these sights. Herein, the authors propose a heuristic solution to this problem addressed to both web andmobile web users. Evaluation and simulation results verify the competence of the authors’ approach against an alternative method.1 Introduction interests, up-to-date information for the sight and information about the visit (e.g. date of arrival and departure,Tourists who visit a destination for one or multiple days are accommodation address etc.), a mobile guide can suggestunlikely to visit every tourist sight; rather, tourists are faced near-optimal and feasible routes that include visits to awith the dilemma of which points of interest (POIs) would series of sights, as well as recommending the order of eachbe more interesting for them to visit. These choices are sight’s visit along the route [7]. Generalised tourist routesnormally based on information gathered by tourists via do not take into consideration the context of the user forinternet, magazines, printed tourist guides etc. After example. the starting or ending point of the user, thedeciding on which sights to visit, tourists have to decide on available time the user affords, the current time, predictedwhich route to take, that is, the order in which to visit each weather conditions while on journey etc. Taking intoPOI, with respect to the visiting time required for each POI, account the parameters of context and location awarenessthe POI’s visiting days/hours and the time available for brings forward a challenge for the design of appropriatesightseeing on a daily basis. tourist routes [8]. Kramer et al. [9] analysed the interests in Tourists encounter many problems following this the profiles of each tourist and concluded that theyprocedure. The information contained in printed guide particularly varied from each other. This conclusionbooks is often outdated (e.g. the opening times of some supports the argumentation for deriving personalised,museums might have changed or some other memorial sites instead of generalised, tourist routes.might be closed because of maintenance works etc.), the Given a list of sights of some tourist destination in which aweather conditions might be prohibitive during one of the user-tourist would potentially be interested in visiting, thevisiting days to visit an important POI etc. [1]. The problem involves deriving the order in which the touristselection of the most important and interesting POIs for should visit the selected POIs, for each day the tourist staysvisiting also requires fusion of information typically at that destination. We term this problem as the ‘touristprovided from separate often non-credible sources. Usually, itinerary design problem’ (TIDP). Interestingly, the TIDPtourists are satisfied if a fairly attractive or feasible route is presents similarities to problems that have arisen in the pastderived, yet, they cannot know of any alternative routes that in the field of operational research; such problems are basedwould potentially be better to follow. Some tourist guides on the mathematical theory of graphs (graph theory) anddo acknowledge such problems and try to propose more comprise variations of the well-known travelling salesmangeneralised tourist routes to a city or an area. Of course, problem (TSP).these routes are designed to satisfy the likes of the majority For instance, the team orienteering problem (TOP)of its readers, but not those with specialised interests, needs appoints an initial and final point as well as N points foror constraints [2]. visiting, where each point is associated with a ‘score’ or Mobile tourist guides may be used as tools to offer solution ‘profit’. Given a particular time margin for each of the Mto these types of problems [3 – 6]. Based on a list of personal team members, the TOP determines M routes (from theIET Softw., pp. 1–10 1doi: 10.1049/iet-sen.2011.0156 & The Institution of Engineering and Technology 2012
  • 2. www.ietdl.orginitial to the end point) via a subset of N points, aiming at considering several user constraints. Google city toursmaximising the overall profit of visited points [10]. The application [21] represents another interesting approachTOP cannot be solved in polynomial time (NP-complete) along the same line suggesting multiple daily itineraries[11], hence heuristics deriving near-optimal solutions are through the familiar Google maps interface. Yet, thethe only realistic way to tackle such problems, especially suggested itineraries are not personalised. Furthermore, citywhen considering online applications. TOP can be thought tours implementations are only provided through a webof as a starting point to model TIDP whereby the M team interface and have not been tested on mobiles; hence, theymembers are reduced to the number of days available for lack location-based and context-aware features [16, 17]. Onthe tourist to stay and the profit of a sight signifies the the other hand, P-Tour and DTG have been implementedpotential interest (or degree of satisfaction) of a particular on mobiles, but can only deal with a small number of POIstourist visiting the POI within a given time span available (i.e. their scalability is questionable).for sightseeing daily (therefore TOP considers the timespent while visiting each POI as well as the time needed totravel from one POI to another). 3 DailyTRIP modelling Nevertheless, TOP does not take into consideration the DailyTRIP modelling involves the definition and thePOIs’ visiting days and hours. Therein, the resemblance of description of the user model, visit model and the sightTIDP with another operational research problem (travelling (POI) model (see Fig. 1) taking into considerationsalesman problem with time windows, TSPTW) [12] comes parameters/constraints like those listed below:forward. TSPTW concerns the minimum cost path for avehicle which visits a set of nodes. Each node must be 1. User model:visited only once and the visit must be carried out inside anallowed time interval (time window). The correlation of † device (e.g. screen resolution, available storage space,time windows with the POIs visiting days/hours is obvious. processing power etc.);However, TSPTW involves planning of only one route (i.e. † language of content, localisation;not M, as many as days available to the tourist to visit † personal ‘demographic’ data (e.g. age, educationalPOIs), while it requires the vehicle to visit the whole set of level);nodes. A generalisation of TOP and TSPTW is referred to † interests (explicit declaration or implicitly collected);as team orienting problem with time windows (TOPTW) † disability (e.g. blind, deaf, kinetic disability);[13] and considers multiple vehicles (i.e. itineraries) that † budget threshold willing to spend on sightseeing.should visit a subset of nodes, each within its allowed timewindow. 2. Visit model: The main contribution of this paper lies in modelling andinvestigating a generalisation of TOPTW through introducing † geographical location of accommodation;a novel heuristic that provides near-optimal solutions to † period of stay (arrival and departure date);TIDP: the daily tourist itinerary planning (DailyTRIP). It is † time constraints (e.g. available time each day to tour,noted that some preliminary ideas of our technique have also number and duration of desirable breaks etc.);been presented in [14]. † means of travel (e.g. walking, driving, bus, metro etc.). The remaining of this article is organised as follows: relatedwork is discussed in Section 2. The modelling, design and 3. Sight (POI) model:implementation of DailyTRIP are presented in Sections 3 –5, respectively. Section 6 compares the approaches taken by † category (e.g. museum, archaeological site, monumentDailyTRIP against a relevant algorithmic solution. Section etc.);7 discusses simulation results whereas Section 8 draws † available multimedia resources (collection of texts,conclusions and grounds for future work. video, audio etc. localised in different languages; † geographical position (coordinates);2 Related work † weight or ‘objective’ importance (e.g. the Acropolis of Athens is thought to be ‘objectively’ more important ofThe issue of personalised tourist itineraries has not been the Coin Museum of Athens, hence the Acropolis islooked at in the electronic and mobile tourism literature, assigned a larger weight);with the exception of the algorithms proposed in [11, 15]. † average duration of visit (e.g. the ArchaeologicalIn Souffriau et al. [15], proposed a heuristic solution for the Museum of Athens typically takes longer to visit thanorienteering problem, that is, they only consider a singletourist itinerary. The algorithm presented in [11] deals withTOPTW and also takes into account the time needed tovisit a sight; hence, it is directly comparable with our work. Other relevant research projects with respect to touristitineraries have been reported in [16, 17]. In [16], a methodfor deriving a single multi-modal tourist itinerary isproposed considering a variety of constraints and followinga genetic algorithm-based approach. However, derived routerecommendations are not personalised as user preferencesabout specific types of sites are not taken into account.P-Tour [18], dynamic tour guide (DTG) [19] and City TripPlanner [20] address these shortcomings; however, theyderive routes day-by-day. The City Trip Planner currentlyoffers the most advanced route planning functionalities Fig. 1 Description of user, visit and sight models in TIDP2 IET Softw., pp. 1– 10& The Institution of Engineering and Technology 2012 doi: 10.1049/iet-sen.2011.0156
  • 3. www.ietdl.org the city’s Coin Museum because of size difference and the between i and j and the means of travel), the profit of the nature of exhibition); arriving node pj and the duration of visit at the arriving node † rating/comments of users; tv( j): Ci,j ¼ a1ti,j 2 a2pj + a2tv( j), where a1 , a2 and a3 are † opening days/hours (time windows), which could be weight coefficients. This formula signifies that having visited provided by the web service of an administrative body or node i, node j will be visited next, if the latter is of relatively the Ministry of Culture; high profit and takes short to arrive and visit. Notably, Ci,j = Cj,i . † whether it is a indoor/outdoor site; Travellers typically plan to visit the area for a set of days, † whether it is a accessible from people with disabilities; D. Users also define a starting and ending time for their † admission price (ticket prices). daily itineraries, Tstart and Tend , which denote what time they prefer to depart from the starting point S and arrive at Notably, the above-stated parameters/constraints are not the end point (destination) E. Hence, a daily time budgetexhaustive. From those parameters the elements listed devoted to visiting sights may be easily calculated:below may be easily derived: T ¼ Tend 2 Tstart . Without loss of generality, we assume that the starting and end points of the |D| daily itineraries† The topological distance (or Manhattan distance) among coincide, that is, S ; E (typically these will coincide withthe POIs and also among the accommodation and the POIs, the user’s accommodation H ).based on their geographical coordinates and the local map. Summarising, the objective of DailyTRIP is to derive |D| |Ii |† The number of routes that must be generated are based itineraries Ii that maximise the overall profit S|D| Sj=1 pj , i=1upon the period of stay of the user at the tourist destination. ensuring that the time needed to complete each itinerary† The anticipated duration of visit of a user at a POI derives does not exceed the user-defined daily time budget T, thatfrom the average duration and the user’s potential interest is,. T(Ii) ≤ T.(concluded by examining the user’s profile).† The ability to visit open air sites in a particular day during 4.2 DailyTRIP algorithm flowthe user’s visit for example. outdoor sites are notrecommended to visit during a rainy day (meteorological 4.2.1 DailyTRIP comprises the following executionforecasts can be retrieved from an Internet web service). phases: Phase 1: Definition of the problem’s model: The first phase first involves the definition of problem’s space, The problem’s definition also includes the ‘profit’ of a POI, that is, the nodes of G, the nodes’ weight wi and thecalculated as a weighted function of the objective and travelling time ti,j that denotes the time needed to travelsubjective importance of each POI (subjectivity refers to the between node pairs (see Fig. 2a); notably, ti,j = tj,i , sinceusers’ individual preferences). Our algorithmic solution the route i j differs from the route j i because ofmaximises the overall profit, that is, it enables the considering one-way roads. Taking into considerationconstruction of personalised routes which include the most personalisation issues (e.g. in a simplified scenario, userimportant (for each tourist) sights under specific constraints preferences upon POIs’ categories), the cost matrix (i.e. the(opening hours, weather conditions, time available for cost values ci,j associated with the two-directional edges) assightseeing). The most crucial constraint in seeking sound well as the nodes’ profit pi and visit duration tv(i) withalgorithmic solutions is the daily time limit T which a respect to a specified user are also computed.tourist wishes to spend on visiting sights; the overall daily Phase 2: Reduction of the problem’s space: The initial setroute duration (i.e. the sum of visiting times plus the overall of sights around the tourist destination is sorted in decreasingtime spent moving from a POI to another which is a order of profit p, where the value of p mainly depends on itsfunction of the topological distance) should be kept below T. category (i.e. whether the POI is museum or an architectural monument) and the user’s preference upon this category. To4 DailyTRIP: a heuristic for deriving near- reduce the computational effort required to reach validoptimal personalised daily tourist itineraries solutions (i.e. to reduce the problem’s space) we discard:4.1 Problem statement † nodes (POIs) with profit pi smaller than a threshold value pmin;The TIDP problem involves a complete graph G ¼ (V, E), † POIs located too far from the origin point H, that is, every|V| ¼ n, where each node i, i ¼ 0, . . . , n 2 1, in V node v for which tH,v . tmax , where tmax is an upper time limitcorresponds to a POI and each edge (i, j) in E corresponds (see Fig. 2b).to the shortest path (in terms of Manhattan distance di,j )linking individual POIs i and j. An alternative approach would be to exclude the relatively Each POI i [ V is associated with a weight wi which low-profit POIs located far from H, that is, exclude every POIdenotes the ‘objective’ importance of the POI and a profit i for which a1∗ pi 2 a2∗ di,H , where a1 and a2 are weightvalue pi , which reflects the importance of that POI for a coefficients and t a threshold value.particular user and depends on their personal preferences. Phase 3: Selection of first daily itinerary nodes: DailyTRIPEach POI i is also associated with a set of days Dc(i) when determines the |D| POIs that will be the first to include in thevisiting is not feasible (e.g. Mondays and during some bank |D| daily itineraries Ii , where i ¼ 1.. |D|. We select the set ofholidays) and the anticipated visit duration of the user at the |D| nodes {Ni}, where i ¼ 1.. |D|, located furthest apart fromPOI tv(i); similar to the profit, tv(i) also depends on the one another, that is, those for which the minimum distanceuser’s personal preferences (for instance, someone from one another is the maximum among any otherinterested in archaeology is expected to take longer to visit permutation of |D| nodes. For instance, in the examplean archaeological museum than others). topology of Fig. 2c, assuming that |D| ¼ 3, we select the The cost of each edge (i, j) ci ,j , namely the cost of visiting j nodes i, j and k that max mini, j,k {di, j , di,k , dj,k }. Then, theafter visiting i, is a weighted function of travelling time from i |D| daily itineraries are initialised, each incorporating one ofto j ti,j (the latter depends on the Manhattan distance di,j those nodes Ii ¼ {Ni}, ∀i ¼ 1..|D|. The philosophy behindIET Softw., pp. 1–10 3doi: 10.1049/iet-sen.2011.0156 & The Institution of Engineering and Technology 2012
  • 4. www.ietdl.orgFig. 2 Execution phases of DailyTRIP4 IET Softw., pp. 1– 10& The Institution of Engineering and Technology 2012 doi: 10.1049/iet-sen.2011.0156
  • 5. www.ietdl.orgthis approach is to achieve a geographical ‘segmentation’ of previous phase, that is,. either increasing the overall profitthe tourist destination in separate zones, as it makes sense, or maintaining the same profit while reducing the itineraryfor example, for a tourist who visits a city for 2 days, to completion time T (I ) (see Fig. 2i). Improved solutions arefocus on POIs located on the northern part of the city on searched for every itinerary by: (a) substituting eachhis/her first day and on POIs located on the southern part itinerary tree node by any node not included in anyon his/her second day. itinerary at the end of the previous phase, and (b) by Phase 4: Construction of itinerary trees: On each of the swapping nodes included on different itineraries. In anyfollowing algorithm’s steps, itineraries Ii are considered case, the new itinerary solutions should satisfy the dailyinterchangeably incorporating a new node N not yet included time budget constraint.in any of the Ii . In particular, for each Ii , the candidate node Phase 6: Traversal of itinerary trees: Notably, the outcomeN with the minimum connection cost Cj,N to any of the of the previous phases is not a set of itineraries, but rather a setnodes j [ Ii joins Ii (through accepting the j N edge), of itinerary trees. Hence, the last phase of DailyTRIP involvesgiven that the daily time budget T condition is not violated the conversion of the |D| trees to multipoint lines Ii throughfor this itinerary (see Fig. 2d). Notably, as the candidate executing a heuristic TSP algorithm [22] upon eachnode N may be connected to any of the Ii nodes (i.e. not itinerary tree (see Fig. 2j).necessarily to the edge nodes of the itinerary), Ii grows as atree structure rather than a multipoint line. The time Ti 5 Implementation details of DailyTRIPcorresponding to the completion of the itinerary Ii iscalculated first by temporarily connecting H with the Ii node DailyTRIP has been developed using JSP/MySQL webnearest to H, then converting the Ii itinerary tree to a technologies and Google Maps as the main user interface.multipoint line (through a post-order tree traversal) and The user first provides some personal demographic data and |Ii |finally calculating T (Ii ) = tH,1 + Sk=1 [(t]v (k) + dk,k+1 ). preferences upon tourist content items, that is, the user mayNamely, Ii ¼ Ii < N, if T (Ii) ≤ T. This is illustrated in Fig. 2e. state preference in visiting museums, archaeological sites, Hence, on each step itineraries Ii grow interchangeably (see monuments etc. Further, the user points the location H ofFigs. 2f and g), typically approaching the start/end point H, his accommodation, the period of visit, the hours availableuntil no further insertion is feasible. Upon completion, each for visit, the means of transport and the radius around theitinerary is connected to the ‘hotel’ node H, that is, the hotel he is willing to move in order to visit a POI. In theedge j N is accepted, where j is the itinerary’s node mobile application case, the user is provided the option tonearest to H (see Fig. 2h). receive recommendations for itineraries that originate at the It is noted that the acceptance of candidate nodes also current location (instead of the hotel in which the user isdepends on the corresponding POIs’ scheduled visiting staying). The user is then shown a list of the initiallydays. In particular, for each joining node i that may not be selected POIs based on his preferences, which he is allowedvisited during the days Dc(i), the ‘excluded’ days of the to modify adding/ removing POIs.itinerary I joined by i is adapted excluding those days: The algorithm filters the POIs left out from the problem’sDc (I) = <|I| Dc (i), signifying that during those days the i=1 space (because of their distance from the user’sitinerary is not feasible either. Apparently, a POI i may join accommodation, their incompatibility with the user’san itinerary I if the intersection of their valid days (i.e. preferences or their intentional removal by the user) andthose when visiting is feasible) is not null and also this populates the travelling time matrix ti,j for the remainingintersection includes at least one of the D days of visit, nodes through first computing the distance matrix entriesnamely if Dv(I ) > Dv(i) > D = f. and considering the average expected velocity v of the Phase 5: Rearrangement of itinerary trees: Phase 5 is selected means of transport. Distances among pairs ofoptional and aims at improving the solutions derived in the nodes are found by means of using the shortest-routeFig. 3 Output of DailyTRIP for two daily itineraries on Google Maps (point ‘A’ denotes the user’s accommodation location, that is, the start/end point of the two itineraries)IET Softw., pp. 1–10 5doi: 10.1049/iet-sen.2011.0156 & The Institution of Engineering and Technology 2012
  • 6. www.ietdl.orgfunctionality of the Google Maps API [23] which refers to of characters representing POIs (see Fig. 3). The mapsManhattan distances and takes into account one-way roads. derived by the web application are then converted to static Our implementation is based on the following assumptions: images using the Google Static Maps API [24] in order to(a) each daily itinerary starts and ends at the same node, display on mobile phone screens. The mobile applicationwhich typically coincides with the user’s accommodation; (see Fig. 4) prompts the user for specifying the period of(b) among all possible routes between a pair of nodes we stay at the destination, determining the start/end location ofonly consider the shortest route in terms of length, although the itineraries (that may be the current location of the user),this might not be shortest in time; (c) the user is assumed to rating content categories and pointing the preferredmove with constant velocity regardless of the traversed transportation mode (either walking or private vehicle).edge or the time of day (admittedly, this is a valid Evidently, the algorithm is straightforward to customise,assumption only for tourists walking around a city); and (d) enabling users to effortlessly prescribe their personalthe POIs are assumed to be open for visiting during the preferences. Certainly, users declaring different preferenceshours available to the tourist for sightseeing. will be recommended different tourist daily routes. The As stated in Section 4, Phase 6 of DailyTRIP involves the derived routes are then displayed upon a static map,conversion of the |D| trees to multipoint lines through a accompanied by a textual description.heuristic TSP algorithm. The latter is based on the Lin – It is noted that mobile users may update their itinerariesKernighan heuristic [22] and was implemented in Java. The at any time, if the deviate from the originally calculatedLin – Kernighan heuristic is considered as one of the most itineraries. Those updates take into account contextualefficient algorithms for deriving near-optimal solutions for parameters, such as the remaining time budget and the sitesthe symmetric TSP. already visited by the user. Currently, we are working on an The output of DailyTRIP is sketched on a Google Maps intelligent mechanism that will trigger automated itineraryinterface, with each itinerary drawn on separate screen and updates when significant deviations from the originalthe order of visiting POIs denoted by the alphabetical order schedules are observed.Fig. 4 Screens of the DailyTRIP mobile web applicationa Accommodations’ selection through a map interfaceb Accommodations’ selection through a set of predefined choicesc Rating of POI categories (0– 100 scale, with step 20)d Selection of preferred transportation modee Visualisation of a daily itineraryf Textual description of a daily itinerary6 IET Softw., pp. 1– 10& The Institution of Engineering and Technology 2012 doi: 10.1049/iet-sen.2011.0156
  • 7. www.ietdl.org6 Qualitative comparison of DailyTRIP † DailyTRIP swaps nodes included on different itinerariesagainst Iterated Local Search (ILS) on its rearrangement step (Phase 5); this often leads to route instances that may accommodate additional nodes, therebyILS [11] is so far the only known TOPTW algorithm increasing the overall collected profit. In contrast, ILS doesexplicitly developed to derive solutions for the TIDP. not consider such restructuring.Hence, ILS serves as a benchmark against which wecompared the results of DailyTRIP. This section comparesthe approaches taken by ILS and DailyTRIP algorithms. 7 Simulation resultsILS comprises two separate steps: Simulation results have been executed on a Java-based1. An insertion step adds, one by one, new visits to a tour; simulation tool, which takes into account most of the TIDPbefore an extra visit is inserted in a tour, it is verified that parameters discussed in Section 4 and includes a visualall visits scheduled after the insertion place still satisfy their interface for displaying the step-by-step output of thetime window (i.e. all visits are completed within POIs’ investigated algorithms. The simulator allows easyopening hours) and the overall daily time budget is not specification of simulation parameters and graphicallyexceeded. Among feasible insertion points, the most illustrates the output of the DailyTRIP and ILS algorithm,appropriate, that is, the one with minimum time overhead while also recording their respective overall itinerary length,(for travelling and visiting) is calculated. Finally, the visit visit order of POIs and respective travel times (for the samethat maximises a ‘profit to time cost’ ratio is inserted into topologies and TIDP parameter values). It also takes intothe route. account a number of constraints, for instance, the attributes2. A shake step is performed to escape local optima: one or a1 , a2 , a3 that determine the weight of travelling time,more visits are removed from each tour and the insertion visiting time and profit of POIs in the calculation of thestep is repeated until no further insertion is feasible. If the cost matrix (see Section 4.1), the number of days to visit,new solution found improves the so far best found, the the minimum/maximum weight to assign to each POI andformer is kept as the new best found solution. The shake the minimum/maximum time to visit a POI (stay time). Theand insert process is repeated up to 150 times, if no assignment of weight and stay time for each POI follows aimproved solution is derived. uniform distribution. The network topology (i.e. POIs’ coordinates) is randomly generated, given the dimensions of the city field, while the start/end point’s position is Overall, ILS represents a fair compromise in terms of speed explicitly set by the user.against deriving routes of reasonable quality. On the other Unless otherwise stated, in all our simulation tests, thehand, DailyTRIP takes a different approach in search of weight of each POI is a random number between 20 andimproved solution, without sacrificing the algorithm’s 100, the time a user can spend at a POI ranges from 5 tocapacity to satisfy real-time application requirements. The 90 min, while daily itineraries start at 09:00 and end atdifferences between the two approaches are summarised in 18:00. In order to denote a high importance with regard tothe following: distance, the distance coefficient has been set to 20% (0, 2), whereas the profit coefficient was set to 80% (0, 8) to† On its first (insertion) step ILS rules out candidate nodes increase the importance of profit in the POIs selectionwith high profit value as long as they are relatively time process. As a result, the visiting time coefficient was set toexpensive to reach (from nodes already included in routes). 0. Since ILS takes into account time windows (i.e. openingThis is also the case even when whole groups of high profit hours) of POIS, and DailyTRIP only considers openingnodes are located within a restricted area of the plane, but days, we have set ILS opening hours from 09:00 to 18:00far from the current route instance. In case the route to allow a direct comparison between the two algorithms.instance gradually grows and converges towards the high- The simulation results presented herein have been averagedprofit nodes, those may be no longer feasible to insert over ten simulation runs (i.e. for ten different network(because of time constraints). On the other hand, DailyTRIP topologies) to ensure statistical validity. Simulation testscreates routes that cover a broader area of the topology have been performed on a single-core P4 2.8 GHz with PC(since initial routes’ nodes are far from the hotel site and 2 GB RAM.from each other), which makes it more likely to approach Fig. 5a illustrates the overall profit for the DailyTRIP inand include a high-profit node. comparison with ILS as the number of POIs increase. For† DailyTRIP explicitly takes into account both travelling and this simulation we assumed 2 days of stay (i.e. twovisiting time into its objective function (i.e. it employs a itineraries). The overall profit of DailyTRIP is shown tomulti-criteria objective). That promotes the side-objective of improve the solutions obtained from ILS, mainly because ofdesigning itineraries with reduced total time cost. In ILS tendency to overlook ‘important’ POIs locatedcontrast, ILS exclusively considers collected profit and relatively far from the constructed routes’ instances (seeregards travelling and visiting times only as constraints in relevant discussion in Section 6). It should be stressed thatthe insertion step. the total itinerary profit of DailyTRIP very much depends† DailyTRIP considers node insertions interchangeably on the value of profit coefficient, that is decreasing theamong constructed itineraries, wheras ILS first finalises profit coefficient results in decreased total profit (it signifieseach itinerary before proceeding to the next one. In several that the profit of POIs to visit becomes less important) andtopology scenarios, this may lead ILS to incorporating vice versa. Both algorithms’ curves increase more mildlynodes to the wrong itinerary, while those nodes could find a when crossing a threshold of around 20 POIs. This isbetter itinerary match (i.e. yield decreased route completion because no more POIs may be accommodated within thetimes) if connected to another itinerary. A side-effect is that two itineraries (typically a maximum of 10 POIs can fitILS itineraries are unbalanced, as ‘important’ POIs are per itinerary). However, larger topologies createabsorbed into the first routes. opportunities to substitute some POIs with others havingIET Softw., pp. 1–10 7doi: 10.1049/iet-sen.2011.0156 & The Institution of Engineering and Technology 2012
  • 8. www.ietdl.orgFig. 5 Comparison of the overall profit and total travel timea Comparison of the overall profit of DailyTRIP against ILS for two itinerariesb Comparison of the total travel time derived from DailyTRIP and ILS for three itinerarieslarger profit values, hence, larger topologies yield incremental daily itineraries, each 9 h long). Although the travellingoverall profit values. time of DailyTRIP is slightly shorter (see Fig. 5b), the Fig. 5b shows the total travel time for 3-day tours (i.e. three opposite is true for the overall itinerary time. This is due toitineraries) as a function of the problem space (i.e. number of the effective DailyTRIP rearrangement phase which allowsPOIs). Clearly, as the number of POIs increase (i.e. itineraries accommodating a larger number of POIs into derivedare prolonged) so does the total travel time, until a 30 POIs itineraries and, therefore increases the total visiting time.threshold is crossed. The DailyTRIP yields slightly Fig. 6b compares the total itineraries length of DailyTRIPimproved results, which is mainly because of the execution and ILS (that is the sum of individual daily itineraryof the TSP algorithm on its last phase ensuring near- lengths). Evidently, the illustrated distance values areoptimality of each daily itinerary in terms of length. proportional to the travelling times of Fig. 5b. It is notedAnother reason is that ILS only considers POIs’ profit as its that on those tests we assume walking transportation mode,only optimisation criterion, whereas DailyTRIP takes a with an average walking speed of 4.5 km/h.multi-objective approach, considering both profit and Fig. 7a portrays the variance among overall daily profitstopological distance (i.e. travelling time). However, the total (i.e. the sum of profits of POIs visited on each day). Hereintravelling time of DailyTRIP very much depends on the we assume four daily itineraries (i.e. staying 4 days at thevalue of distance coefficient, that is decreasing the distance destination). Small variance values denote fairly balancedcoefficient results in increased total itinerary length (it itinerary profit values over the four itineraries whereassignifies that the time spent by the user for travelling is less larger variance values denote that some itineraries are muchimportant) and vice versa. That represents an interesting more ‘profitable’ than others. Notably, DailyTRIP yieldstrade-off among profit and travelling time. smaller variance values in comparison with ILS for small- Fig. 6a compares DailyTRIP against ILS in terms of their scale topologies. This is because DailyTRIP considers therespective overall itinerary time. That sums up the overall four itineraries interchangeably while inserting new nodes,time spent for travelling (i.e. moving from one POI to hence derived itineraries comprise approximately the sameanother) and visiting POIs. As expected, the overall time number of POIs (+ ensuring a balanced overall itinerary 1),yield for both algorithms converges to 1620 min (three profits. On the other hand, ILS first completes an itineraryFig. 6 Comparison of the overall time and total distancea Comparison of the overall time derived from DailyTRIP and ILS algorithms for three itinerariesb Comparison of the total distance for three itineraries8 IET Softw., pp. 1– 10& The Institution of Engineering and Technology 2012 doi: 10.1049/iet-sen.2011.0156
  • 9. www.ietdl.orgFig. 7 Variance and execution timea Variance of the individual itineraries’ overall profit per day for both algorithms (four daily itineraries)b Execution time of DailyTRIP for a varying number of POIs and itinerariesbefore proceeding to the next one, which implies that in times for these sites. The objective of DailyTRIP is toscenarios with few POIs and relatively large number of maximise the overall profit associated with visited POIsitineraries, ILS derives some ‘full’ and some ‘empty’ (where individual profits are calculated as a function of theitineraries (hence, large variance values). In other words, POIs’ ‘objective’ importance and the user’s potentialDailyTRIP distributes visited POIs over all available days interest for the POI) while not violating the daily timeof stay, whereas ILS derives ‘overloaded’ days in the budget for sightseeing. Our algorithm has beenbeginning and relatively ‘relaxed’ days at the end of the implemented and proved suitable for online applicationsstaying time. Notably, as the number of POIs increase, ILS (i.e. real-time design of itineraries), whereas simulationobtains improved distributions of POIs into individual results validated its performance gain over ILS algorithm.itineraries (i.e. its itineraries are gradually ‘filled’ with Our future research will focus on variations of DailyTRIPPOIs) which, in turn, decrease variance values. algorithm that will incorporate additional TIDP problem Last, Fig. 7b illustrates the execution time of DailyTRIP for parameters and constraints, for example, weather conditionsan increasing number of POIs. Despite the time increment as during travel, financial budget (for transport and POIsthe problem space increases, DailyTRIP appears suitable for admission charges) etc. We will also investigate the use ofonline usage in realistic scenarios. In particular, the a combination of transport modalities, for example, walkingalgorithm requires less than 2 s for topologies spanning up and bus service, taking into account various aspects ofto 25 nodes and less than 4.5 s for topologies up to 50 alternative transport services (e.g. walking time to thePOIs, which represents a reasonable number of POIs for a nearest metro station, time-dependent metro servicemedium-to-large-scale city. Clearly, performance also frequencies etc.). Currently, we are working on andepends on the number of derived itineraries: the TSP intelligent mechanism that will trigger automated itineraryalgorithm is executed once per itinerary, while the number updates when significant deviations from the originalof swaps tried between nodes included on different schedules are observed. Methods for fast, automateditineraries increases proportionally. It is noted that we itinerary updates will also be considered, either for mobilecurrently work on speedup techniques to further improve users that have deviated from the suggested itinerary orDailyTRIP performance. That involves the implementation because of sudden weather changes, unexpected publicof a faster technique to identify the initial itinerary nodes transportation schedule changes etc. Last, the mobile(Phase 3) as well as a more efficient TSP algorithm application will incorporate various contextual parameters,(appropriate pre-calculation techniques are also such as time of day, predicted queuing delay, parkinginvestigated); it also involves restrictions on nodes swapped availability at each POI etc.in Phase 5 so that only nodes located in proximity (i.e.those that are more likely to derive improved solutions) areexchanged. 9 Acknowledgment This work was supported by the EU FP7/2007-2013 (DG8 Conclusions and future research INFSO.G4-ICT for Transport) under grant agreement no.This paper introduced DailyTRIP, a heuristic approach for 288094 (project eCOMPASS).deriving personalised recommendations of daily touristitineraries for tourists visiting any tourist destination. The 10 Referencesalgorithm targets both web and mobile users, with the latteroffered location-aware recommendations. DailyTRIP 1 Dunlop, M., Ptasinski, P., Morrison, A., McCallum, S., Risbey, C.,considers selected POIs that a traveller would potentially Stewart, F.: ‘Design and development of Taeneb city guide – fromlike to visit and derives a near-optimal itinerary for the paper maps and guidebooks to electronic guides’. Proc. Int. Conf. on Information and Communication Technologies in Tourismtraveller for each day of visit. Our approach takes into (ENTER’2004), 2004, pp. 58– 64account user preferences, time available for visiting sights 2 Cheverst, K., Davies, N., Mitchell, K., Friday, A., Efstratiou, C.:on a daily basis, opening days of sites and average visiting ‘Developing a context-aware electronic tourist guide: some issues andIET Softw., pp. 1–10 9doi: 10.1049/iet-sen.2011.0156 & The Institution of Engineering and Technology 2012
  • 10. www.ietdl.org experiences’. Proc. SIGCHI Conf. on Human Factors in Computing 14 Kenteris, M., Gavalas, D., Pantziou, G., Konstantopoulos, C.: ‘Near- Systems, 2000, pp. 17– 24 optimal personalized daily itineraries for a mobile tourist guide’. Proc. 3 Cheverst, K., Mitchell, K., Davies, N.: ‘The role of adaptive hypermedia 15th IEEE Symp. on Computers and Communications (ISCC’2010), in a context-aware tourist GUIDE’, Commun. ACM, 2002, 45, (5), 2010, pp. 862– 864 pp. 47–51 15 Souffriau, W., Maervoet, J., Vansteenwegen, P., Vanden Berghe, G., 4 Kenteris, M., Gavalas, D., Economou, D.: ‘An innovative mobile Van Oudheusden, D.: ‘A mobile tourist decision support system for electronic tourist guide application’, Pers. Ubiquit. Comput., 2009, 13, small footprint devices’. Proc. Tenth Int. Workshop on Artificial (2), pp. 103– 118 Neural Networks (IWANN’2009), 2009, pp. 1248– 12 55 5 Kenteris, M., Gavalas, D., Economou, D.: ‘Electronic mobile guides: 16 Abbaspour, R.A., Samadzadegan, F.: ‘Itinerary planning in multi-modal a survey’, Pers. Ubiquit. Comput., 2011, 15, (1), pp. 97–111 urban transportation network’, J. Appl. Sci., 2009, 9, (10), 6 Malaka, R., Zipf, A.: ‘DEEP MAP – challenging it research in the pp. 1898– 1906 framework of a tourist information system’. Proc. Int. Conf. on 17 Garcia, A., Linaza, M.T., Arbelaitz, O., Vansteenwegen, P.: ‘Intelligent Information and Communication Technologies in Tourism routing system for a personalised electronic tourist guide’. Proc. Int. (ENTER’2000), 2000 Conf. on Information and Communication Technologies in Tourism 7 Vansteenwegen, P., Van Oudheusden, D.: ‘The mobile tourist guide: an 2009 (ENTER’2009), 2009, pp. 185–197 or opportunity’, Oper. Res. Insight, 2007, 20, (3), pp. 21–27 18 Maruyama, A., Shibata, N., Murata, Y., Yasumoto, K., Ito, M.: ‘P-tour: 8 Kruger, A., Malaka, R.: ‘Artificial intelligence goes mobile’, Appl. Artif. ¨ a personal navigation system for tourism’. Proc. 11th World Congress on Intell., 2004, 18, pp. 469 –476 ITS, 2004, pp. 18–21 9 Kramer, R., Modsching, M., ten Hagen, K.: ‘A city guide agent creating 19 Hagen, K., Kramer, R., Hermkes, M., Schumann, B., Mueller, P.: and adapting individual sightseeing tours based on field trial results’, ‘Semantic matching and heuristic search for a dynamic tour guide’. Int. J. Comput. Intell. Res., 2006, 2, (2), pp. 191– 206 Proc. Int. Conf. on Information and Communication Technologies in10 Chao, I.-M., Golden, B.L., Wasil, E.A.: ‘The team orienteering Tourism, 2005, pp. 149 –159 problem’, Eur. J. Oper. Res., 1996, 88, (3), pp. 475–489 20 City Trip Planner: http://www.citytripplanner.com/, accessed 3011 Vansteenwegen, P., Souffriau, W., Vanden Berghe, G., Van January 2011 Oudheusden, D.D.: ‘Iterated local search for the team orienteering 21 Google city tours: http://citytours.googlelabs.com/, accessed 30 January problem with time windows’, Comput. Oper. Res., 2009, 36, (12), 2011 pp. 3281– 3290 22 Helsgaun, K.: ‘An effective implementation of the Lin–Kernighan traveling12 Dumas, Y., Desrosiers, J., Gelinas, E., Solomon, M.M.: ‘An optimal salesman Heuristic’, Eur. J. Oper. Res., 2000, 126, (1), pp. 106–130 algorithm for the traveling salesman problem with time windows’, 23 Google Maps. Google Maps API Concepts http://code.google.com/apis/ Oper. Res., 1995, 43, (2), pp. 367– 371 maps/documentation/, accessed 30 January 201113 Vansteenwegen, P.: ‘Planning in tourism and public transportation’. 24 Google Static Maps API http://code.google.com/apis/maps/ PhD thesis, Katholieke Universiteit Leuven, 2008 documentation/staticmaps/, accessed 30 January 201110 IET Softw., pp. 1– 10& The Institution of Engineering and Technology 2012 doi: 10.1049/iet-sen.2011.0156