P-TOUR: A PERSONAL NAVIGATION SYSTEMFOR TOURISM

Atsushi Maruyama, Naoki Shibata†, Yoshihiro Murata,Keiichi Yasumoto and Minoru Ito

Grad. Sch. of Info. Sci., Nara Institute of Sci. and Tech.,Ikoma, Nara 630-0192, Japan Phone:+81-743-72-5251, Fax:+81-743-72-5259

E-mail: {atsu-mar,n-sibata,yosihi-m,yasumoto,ito}@is.aist-nara.ac.jp† Dept. of Info. Proc. & Man., Shiga Univ., Hikone, Shiga 522-8522, Japan

ABSTRACTIn this paper, we propose a personal navigation system for tourism called P-Tour. When a touristspecifies multiple destinations with relative importance and restrictions on arrival/staying time,P-Tour computes the nearly best schedule to visit part of those destinations. In addition tothe map-based navigation, P-Tour provides temporal guidance according to the schedule, andautomatically modifies the schedule when detecting the situation that the tourist cannot followthe schedule. We have developed a route search engine as a Java Servlet which can compute asemi-optimal schedule in reasonable time using techniques of genetic algorithms.

INTRODUCTIONDue to recent progress of information technology, portable computing devices (e.g., PDAs,cell phones, etc) with GPS units and communication capability (e.g., wireless LANs, PHS,Bluetooth and wideband CDMA) are becoming popular. In Japan, personal navigation sys-tems (hereafter, called PNS) using these portable devices have become widely available. KDDIprovides a service called EzNaviWalk on its cell phones which navigates a user to a specifieddestination by displaying a route on the corresponding map like car navigation systems.

A lot of researches on realizing personal navigation systems have been proposed so far[1, 2,3, 6, 7]. [1] proposes a system called REAL which detects user’s current context and navigatesthe user in the most suitable way. [2] proposes an indoor navigation system which aims atprovisioning the coherent navigation service to different devices. [3] proposes a system tosupport planning a bicycle tour by showing different routes for the round trip to a destination.These existing researches focus mainly on navigation to a single destination. However, for thesightseeing tour, tourists want to visit multiple destinations (sightseeing spots) efficiently undersome restrictions. For this purpose, the existing navigation systems are not sufficient.

In the navigation systems for tourism, unlike car navigation systems, it will be necessaryto support planning a schedule to travel multiple destinations efficiently under specified restric-tions and to navigate a user according to the decided schedule and the user’s context through aportable device.

In this paper, we propose a personal navigation system for tourism called P-Tour. In general,when planning a travel schedule, there are the following requirements: tourists (1) want to effi-ciently travel multiple destinations as many as possible; (2) want to specify arrival and staying

1

time at each destination considering timeliness (e.g., opening hours of the facility, starting timeof an entertainment and so on); and (3) want to select the best subset of all candidate destina-tions considering various restrictions if there is not enough time to visit all of them. In P-Tour,when a tourist specifies starting location, departure time, returning location, arrival time andmultiple candidate destinations with relative importance degrees and time restrictions on arrivaland staying time, a nearly best schedule can be computed.

P-Tour can efficiently navigate the tourist according to the decided schedule through aportable computing device with GPS. In addition to the popular map-based navigation, P-Tourprovides temporal guidance (e.g., showing remaining time to departure at each destination) forthe tourist to follow the schedule. Moreover, P-Tour can automatically modify the schedulewhen the tourist can not follow the schedule due to some reasons (e.g., delay by traffic jam,intentional change of next destination/staying time, and so on).

When planning a travel schedule using P-Tour, it is likely that user modifies some relativeimportance degree and/or staying time and schedule is re-computed repeatedly. Schedule isalso re-computed during the tour due to context changes. Accordingly, the computation timeshould be reasonably small (e.g., less than 10 seconds). However, the above problem whichcomputes the optimal route including multiple destinations with restrictions is a superclass ofTSP (traveling Salesman Problem) which is known as a NP-hard problem, and thus it takesmuch computation time to obtain an optimal solution. So, we have developed a route searchengine to obtain a semi-optimal solution quickly using techniques of genetic algorithms (GA).The engine has been developed as a Java Servlet and can be used from PCs and portable devicesvia HTTP protocol.

Our experimental results show that our route search engine can compute a reasonable travelschedule in about 5 seconds when 30 candidate destinations are specified, and re-compute an-other schedule after modifying destinations and restrictions in less than 1 second, where thedifference between the obtained solution and the optimal solution is within 2%.

OUTLINE OF P-TOURAs shown in Fig. 1, P-Tour consists of (1) a client module running on a portable computingdevice with GPS and wireless communication capability and (2) a server module running ona PC connected to the Internet. The PC has a database including map data and recommendedcandidate destinations which can be accessed by the server module.

Figure 1: P-Tour

P-Tour provides a function for planning travel schedules and a function for navigating usersaccording to a decided schedule through the client module executed on a portable device.

2

Function for Planning Travel ScheduleThis function allows a user to plan the nearly best travel schedule which includes a subsetof specified candidate destinations and a route to visit the subset of all destinations satisfyingspecified restrictions. As of restrictions, P-Tour treats the total time for the tour, geographicaldistances between any two destinations, user’s moving speed, and timeliness at each destination(e.g., opening hours of the interesting facility, starting time of entertainment).

In order to plan a schedule, P-Tour requires a user to input (1) starting/returning locationsand departure/arrival time of this tour, (2) candidate destinations of the tour, (3) a relative im-portance degree of each destination (specified as an integer value more than 0), (4) a restrictionto arrival time at each destination (e.g., “before 2:00PM”) and (5) a restriction to staying timeat each destination (e.g., “more than one hour”). Here, (4) and (5) are optional. In order tofacilitate the user input, recommended candidate destinations with importance degrees of 1(registered in the database) are automatically added to the input. The user can remove thosedestinations by setting 0 to their importance degrees.

From the above input, P-Tour computes a schedule consisting of (i) a set of destinations andthe route to visit all of them, and (ii) the expected arrival time and the departure time at eachdestination. P-Tour shows the output schedule to the user.

The route is computed so that the user’s satisfaction degree (defined later) is maximizedunder the given restrictions and the moving time between destinations. Here, the moving timebetween two destinations is calculated by dividing the distance of the shortest path (obtainedby A? algorithm) between those destinations by the user’s moving speed. We assume that thedistance and the moving speed between any two destinations are registered in the database.

The user can modify the schedule by adding/removing some destinations and/or modifyingthe importance degree/time restrictions at each destination.

We have designed and implemented a fast route search engine based on the techniques ingenetic algorithms (GA). The details of the engine are explained in the next section.

Function for Navigating User According to ScheduleP-Tour provides the function for navigating the user through a portable device with GPS ac-cording to the decided schedule.

The navigation is provided through a graphical interface with three modes: schedule; mov-ing; and staying. In schedule mode, the entire route with the state of progress and the list ofdestinations to visit with arrival/staying time are displayed on the screen of the portable deviceas shown in Fig. 2(a) and (b). In moving mode, the map around the current location and theroute to the next destination are displayed like car navigation systems (Fig. 2(c)). In stayingmode, as shown in Fig. 2(d), the remaining time at the current location and the optional infor-mation (e.g., on the facility there) are displayed. When the departure time comes, the systemprompts the user and automatically switches to moving mode. Switching between moving andstaying modes is automatically done by monitoring the current location obtained by GPS andthe present time.

Automatic Schedule Modification by Context ChangeDuring the tour, the user may fall into the situation that he/she cannot follow the schedule. Forexample, if the user cannot move to the next destination at the expected speed due to traffic jam

3

(a) (b) (c) (d)

Figure 2: Snapshot of Navigation by P-Tour

or he/she intentionally changes the staying time at a destination, the remaining schedule cannotbe achieved. P-Tour detects such a context change by monitoring the current location and time,and automatically modifies the schedule for the remaining destinations. When the schedule ismodified, the system displays the alert on the screen and the user can grasp the modified sched-ule by switching to schedule mode. If the user does not like the modified schedule, he/she canrecompute the schedule after modifying candidate destinations and/or importance degrees/timerestrictions to some of them.

ROUTE SEARCH ENGINETo search a route under the restrictions explained in previous sections, we decided to use a GA,since it always retains multiple candidate solutions during search. Also, GA can output multiplesolutions at a same time, so that the user can select a desirable route from them.

In order to save the search time, we prepare a database which keeps the shortest paths andthe distances between any two of predefined destinations. If some destinations specified by theuser do not exist in the database, the shortest paths and the distances between these destinationsare calculated using A? algorithm[8].

PROBLEM DEFINITIONThe objective of the route search engine is to find a route with an evaluation value close to thehighest value, where the evaluation value is, in brief, increased by the importance degrees ofdestinations in the route which satisfy given time restrictions.

INSTANCE

The map data is given by a graph G = (V, E). The set of destination data is denoted byD = {d1, d2, ....., dn}.

Each destination data di consists of five components, vi, rti, duri and pre, where

4

vi : a location in the maprti : a time constraint for arrival time (e.g., “before PM2:00”)duri : a time constraint for stay time

(e.g., “more than 30 minutes after arrival” or “30 minutes after PM2:00)pre : D → N , pre(di) means the importance degree of destination di, which can be set

by user.The starting and returning locations are denoted by ps, pg ∈ D. Time restrictions for starting

and returning locations cannot be omitted.

DISTANCE

dist[ds][dg] is the distance between ds and dg registered in the database.

ROUTE(SOLUTION)

The candidate route is denoted as S = 〈d′1, d

′2, ..., d

′k〉, where d′

k ∈ D, 1 ≤ k ≤ |D| and d′k is

the k-th destination.Arrival time at each destination is calculated as follows. We assume that the user moves at a

fixed speed between destinations(defined in the database), and stays some time satisfying duri

at each destination d′i.

Destinations satisfying the time restriction is denoted as S ′ = 〈d′′1, d

′′2, ....., d

′′j 〉, where d′′

j ∈S is the destination which satisfies the time restriction.

EVALUATION FUNCTION

To evaluate each candidate route, the sum of the importance degrees of the destinations whichsatisfy time restrictions included in the list is calculated. If we use this value as the evaluationfunction, devious routes may be produced. So, we have defined evaluation function as follows,

f(S) = αk∑

i=1

pre(d′i) + β

j∑

i=1

pre(d′′i ) − γ

k−1∑

i=1

dist[d′i][d

′i+1]

where α ,β and γ are constant values (weighted coefficients). α is referred to the sum of im-portance degrees of traveled destinations (including destinations satisfying time restriction). β

is referred to importance degrees of destinations satisfying time restriction. γ is referred to thetotal distance. Long route gives low evaluation value if γ value is increased.

ALGORITHMTo make it possible to add or delete destinations in candidate solutions, a candidate solution iscoded as a variable length list of destinations. The search procedure is as follows.

1. Predefined number of candidate solutions are generated randomly. An evaluation valueis calculated and assigned to each candidate solution. The evaluation method is explained later.

2. The elite individual is selected in the group. The elite individual is a candidate solutionwith the best evaluation value.

3. Two candidate solutions are selected using the GA operator called tournament selection.From these two solutions, two new candidate solutions are generated using the GA operatorcalled one-point crossover. The crossover point is chosen randomly, and redundant destinations

5

are deleted. For example, if the original candidate solutions are 〈a, | b, c, y〉 and 〈x, y, | z〉,where crossover points are denoted by ‘|’, new solutions 〈a, z〉 and 〈x, y, b, c, y〉 are producedby one-point crossover. In this case, since 〈x, y, b, c, y〉 contains two occurrences of y, one ofthe occurrences of y is deleted.

4. A GA operator called mutation is applied to the newly generated candidate solutions. Ourmutation operator consists of 2-opt and addition/deletion of a destination. 2-opt is the techniqueto swap the positions of two destinations selected at random in the candidate solutions.

5. An evaluation value is calculated and assigned to each newly generated candidate solu-tion. The newly generated candidate solutions replace all old candidate solutions, except thatthe elite individual is preserved.

6. Local search is applied to the elite individual. One destination which is not included in theroute of the elite individual is randomly selected and inserted into randomly selected positionin the route. After evaluation of the new route, the evaluation value is compared to that of theoriginal route. If evaluation value doesn’t increase, the change is canceled. The process aboveis repeated until predefined number of canceling occurs successively.

7. Steps (2) to (5) are repeated until the expiry of the time limit specified by search time.

IMPLEMENTATIONWe have implemented P-Tour as a client-server application system. Our route search engineexplained in the previous section has been implemented as a Java Servlet which is executed ona server PC connected to the Internet. The client module executed on a portable computingdevice has been implemented as a Java MIDlet for cellular phones.

NAVIGATION FUNCTIONIn order to plan a schedule, a user inputs some information for the tour on a cellular phone, andsends it to the server using HTTP. Then, he/she receives the schedule computed on the server asa HTTP response.

The response contains the following information : (1) A graphical map (in JPEG format)showing the entire route for the schedule (Fig. 2 (a)) and (2) Order of visiting destinations withestimated arrival/staying/departure time (Fig. 2 (b)); The above information is displayed bypushing the corresponding button on the user’s cellular phone.

During the tour, the graphical map around the user’s current location is displayed on thescreen as shown in Fig. 3. The client module measures the current location through the GPSunit on the cellular phone, and sends the current location and a request to update map to theserver module. Then, the server module composes the latest map image (in JPEG format) andsends the image as the response. This update is repeated periodically while the user movesbetween destinations.

USER INTERFACETo plan a schedule with P-Tour, a user may have to input a lot of information. So, the userinterface is important. We have adopted an web-based user interface since most people canlearn the operation via web browsers quickly and intuitively [9]. Also, there is a merit thatordinary PCs can be used when planning a schedule.

6

We have implemented a user interface as shown in Fig. 4, where data items are input usingHTML forms. We have also implemented the specific interface for cellular phones (Fig. 4).

Figure 3: Snapshot of Route Guidance Figure 4: Web Base User Interface

In our interface, each user inputs the tour information in the following two steps: (1) the userinputs candidate destinations by selecting them in a predefined destination list (Fig. 5 (a)(b)).The user can add destinations not in the list by inputing the corresponding latitude/longitude,name, and so on; (2) the user can specify the importance degree and time restrictions to each des-tination as shown in Fig. 5 (b)(c). When the user does not specify the importance degree/timerestrictions to a destination, default values are used for the destination.

From some experiments using this interface on a cellular phone, we confirmed that theinterface can be used comfortably, and data can be input smoothly.

(a) (b) (c)Figure 5: Snapshot of Interface

DETECTION OF CONTEXT CHANGEWe have implemented in the client module a mechanism to detect the situations that the usersteps away from the route in the schedule, the current schedule cannot be achieved due tothe delay to arrive at the next destination or some other reasons. When the client moduledetects such a situation, it alerts to the user by showing a path returning to the original routeor automatically modifies the schedule. The schedule modification is done by sending a re-computation request with the user’s current location and unvisited destinations to the server,receiving the new schedule, and showing it to the user.

Detailed conditions of the alert and the re-computation are as follows.

7

• If the user goes into a wrong route : Let Tstopover denote the time to follow the shortestpath from the user’s current location to the original route considering the user’s speed.

The server can easily calculate and tell Tstopover to the client module when updatingthe navigation map. For example, we can let the client module to alert to the user whenTstopover exceeds 3 minutes, and to recompute the schedule when Tstopover exceeds10 minutes.

• If the user cannot arrive at the next destination until the scheduled arrival time or theuser departed a destination later than scheduled : We assume that staying time of eachdestination includes GUARD TIME minutes of margin. Let Tprdarv denote the pre-dicted arrival time at the next destination, which is calculated by the current time, thedistance between the user’s current location and the next destination, and the user’s mov-ing speed. Tprdarv can easily be calculated by the server and told to the client modulewhen the navigation map is updated. Consequently, we can implement this function asfollows: if Tprdarv is later than the scheduled arrival time at the next destination, theclient module alerts to the user; and if Tprdarv is later than the scheduled arrival timeplus GUARD TIME, the client module requests re-computation of the schedule.

EXPERIMENTAL RESULTS AND EVALUATIONIn order to show the performance of our route search engine, we have carried out some ex-periments for investigating (1) the appropriateness of the computed schedule, (2) time to com-pute/recompute the schedule, and (3) the optimality of the schedule.

In experiments, we have used a typical scenario to travel around the northern part of Naraprefecture in Japan which have 30 recommended candidate destinations. Here, we have setthe starting/returning locations to our university (NAIST) and the starting/returning time to9:00/21:00. Note that it is impossible to visit all destinations in this scenario.

As a database, we have used a digital map (northern part of Nara, 3800 nodes) available onthe market for car navigation systems. The route search engine has been executed on a generalPC with GNU/Linux, Tomcat4.1, Pentium4 2.4GHz and 512MB RAM. As coefficients of theevaluation function in our route search engine, we have used α = 20, β = 200, and γ = 40,which were decided based on our preliminary experiments. We applied GA operations up to100th iteration(generation) since the evaluation values of the computed routes converge to thehighest ones in most cases.

APPROPRIATENESS OF COMPUTED SCHEDULEAt first, we investigated to what extent our route search engine can compute the appropriateschedule depending on the user input.

As of the user input, we used the setting in Table 1. In Table 1, we specified 30 candidatedestinations where 13 destinations {D1,...,D13} have the importance degree “5” and the others{D14....,D30} have “1”. For two of destinations D3 and D7, we also specified time restrictionson arrival time “before 15:00” and “before 19:30”, respectively. Also, staying time at D3 is set“more than 180 minutes”, staying time at D7 is set “more than 60 minutes”.

For the above input, our route search engine computed the route including D1, D2, D3,D7,...,D10, and D12 as shown in Fig.6. Next, when we increased the importance degrees of D4and D13 to 10, the new route including D4 and D13 were output as shown in Fig. 7.

8

destination no. name importance degree arrival time staying timeD1 Toushoudaiji temple 5 – =60minD2 Yakushiji temple 5 – =60minD3 Houryuji temple 5 ≤ 15:00 ≥ 180 minD4 Fujinoki tomb 5 – =90minD5 Heijoukyou 5 – =150minD6 Saidaiji 5 – =30minD7 Gakuenmae Station 5 ≤ 19:30 ≥ 60 minD8 Sarusawaike pond 5 – =60minD9 Manyou arboretum 5 – =45minD10 National museum 5 – =60minD11 Shinyakushiji temple 5 – =60minD12 Shousouin 5 – =30minD13 Daianji temple 5 – =60minD14 Hourinji temple 1 – =60min... ... ... ... ...D30 Hokkeji temple 1 – =30min

Table 1: User Input

Figure 6: Route for Table1 Figure 7: New Route After Modifying Table1

Appropriateness of Evaluation Function

Our route search engine uses the evaluation function to numerize the user’s satisfaction degreeon the computed route. In order to show the appropriateness of the evaluation function, weinvestigated the property of the computed routes by changing the value of γ among 0, 40, and80. Here, as γ value is smaller, the evaluation value of the shorter route becomes large. Thecomputed routes when using the user input in Table 1 are shown in Fig. 8 and in Table 2. Thenumbers in Fig. 8 show the visiting order.

If we set 0 as the γ value, the output route includes D3 and D7 which satisfies time restric-tions. But, the route has many detours when visiting first four destinations(Fig. 8 (a)). This isbecause detours do not affect the evaluation value if γ is set to 0.

If we set 40 as the γ value, the route again includes D3 and D7, but it is a better route(Fig.8 (b)). This is because detours worsen the evaluation value.

When γ = 80, destination D3 which is the farthest from the starting location is not includedin the output route (Fig. 8 (c)). Because the total distance of the route largely affects theevaluation value, only destionations close to the starting point are now included in the route.

According to the above results, we confirmed that the computed route largely changes de-

9

γ no. of destinations total distance arrival time at D3 arrival time at D70 8 55 Km 14:40 19:10

40 8 45 Km 14:50 18:5080 7 23 Km N/A 18:40

Table 2: Property of Route Depending on γ

pending on γ value. In general, when using γ = 40, it is shown that an appropriate route canbe computed. If the gamma value is changeable by the user, he/she may be able to find morepreferable route easily.

(a) γ = 0, (b) γ = 40, (c) γ = 80,

Figure 8: Appropriateness of Routes Depending on γ

TIME TO COMPUTE SCHEDULESince genetic algorithms always have the candidate solutions, solution can be output even whenstopping the search after a specified constant time expires. Here, we measured the computationtime and the quality of solutions by changing the number of generations in our route searchengine. The results are shown in Table 3. We assume that the shortest path and its distancebetween any two candidate destinations are computed in advance and stored in the database.

Table 3 shows that the evaluation value converges at around 50th generation. However,there is not so large improvements from 10th or 20th generations. As a result, we can obtain asufficient route even when limiting the computation time, e.g., less than 5 seconds.

Re-computation of Schedule

In order to find the user’s preferable schedule, the user needs to modify the input and computethe schedule repeatedly until getting the favorite one.

So, we modified the user input in Table 1 by removing one destination D3 in the route ofFig. 6 and by specifying a new time constraint to destination D5. Then we recomputed the newroute using candidate solutions after computing the previous route in Fig 6.

10

As a result, the computation time was less than 1 second. This is because our route searchengine can start computation with candidate solutions with good evaluation values to the old in-put and it took only small number of generations until converging to the semi-optimal solution.

COMPARISON WITH OPTIMAL SOLUTIONWe implemented a program to compute the optimal route by evaluating all possible routes,and investigated the difference between the optimal evaluation value and that computed by oursearch engine. Here, we used the user input that the number of destinations is 12, 13 or 14,γ = 40, and the number of generations is 100. The result is shown in Table 4. Independentlyof the number of destinations, the deviation ratio of the routes computed by our route searchengine was less than 2%. When the number of destinations is 14, it took about 22 hours tocompute the optimal route, while our engine could compute the semi-optimal route less than15.5 second.

num of generations computation time eval value5 2.6 (sec) 2322

10 3.0 (sec) 253120 5.2 (sec) 254250 11.0 (sec) 2582

100 15.5 (sec) 2582

Table 3: Computation Time Depending on Number of Generations

CONCLUSIONIn this paper, we proposed a personal navigation system for tourism called P-Tour. P-Tourprovides a user with functions (1) for planning his/her schedule to efficiently visit multiple des-tinations based on importance degrees and time restrictions, (2) for navigating a user accordingto the planned schedule through a portable device with GPS, and (3) for modifying the scheduleautomatically during the tour if the system notices that the user cannot follow the schedule.

We have designed and implemented a fast route search engine using genetic algorithm. Onexperiments using a digital map on the market, the time for computing a schedule for a typicalscenario is about 5 seconds. The time for re-computation after modifying the user input is lessthan 1 second. We believe that these results are reasonable for practical use.

We have designed P-Tour as a client server system where a server module is implementedas a Java Servlet on a WWW server. So, most Internet users can use the schedule planningfunction of P-Tour through web browsers. Also, the navigation function of P-Tour can be usedby various portable computing devices including cellular phones, PDAs and note PCs whichhave GPS units and communication capability.

In our current implementation of P-Tour, we suppose that users move between destinationsby a single mean of transportation (e.g., by car or by walk). As part of future work, we areplanning to extend our system to handle multiple means of transportation such as train and bus.

11

num. of dest. eval value opt value error comp time (P-Tour) comp time(opt))12 2650 2670 0.8 % 15.9 (sec) 49(min)13 2664 2698 1.3 % 16.3 (sec) 126(min)14 2708 2744 1.3 % 15.0 (sec) 22(hour)

Table 4: Error Ratio from Optimal Evaluation Value

AcknowledgementsWe thank the Navigation System Researchers’ Association for providing the digital road-mapformat.

References[1] Baus, J., Kruger, A., Wahlster, W., “A Resource Adaptive Mobile Navigation System”, Pro-

ceedings of IUI2002: International Conference on Intelligent User Interfaces 2002, ACMPress, New York ;

[2] Butz, A., Baus, J., Kruger, A., Lohse, M., “A Hybrid Indoor Navigation System”, Proceed-ings of IUI2001: International Conference on Intelligent User Interfaces 2001, ACM Press,New York, pp. 25-33;

[3] Ehlers, M., Jung, S., Stroemer, K., “DESIGN AND IMPLEMENTATION OF A GISBASED BICYCLE ROUTING SYSTEM FOR THE WORLD WIDE WEB (WWW)“, In-ternational Symposimum on Geospatial Theory, Processing and Applications (ISPRS2002)

[4] Kanoh, H., Nakamura, N., “Route Guidance with Unspecified Staging Posts using GeneticAlgorithm for Car Navigation Systems”, IEEE Conference on Intelligent TransportationSystems (ITSC 2000), pp. 119–124, 2000.

[5] Zipf, A., and Malaka, R., ”Developing Location Based Services (LBS) for tourism - Theservice providers view”, Information and Communication Technologies in Tourism 2001.Proceedings of ENTER 2001, 8th International Conference. Montreal. Springer ComputerScience. Wien, NewYork. pp. 83–92, 2001.

[6] IST, ”CRUMPET Creation of User-friendly Mobile services Personalised for Tourism”,http://www.ist-crumpet.org/

[7] Malaka, R., and Zipf, A., “DEEP MAP - Challenging IT research in the framework of atourist information system.” ENTER 2000, Barcelona, Spain, pp. 15–27, 2000.

[8] Korf, R., ”Real-Time Heuristic Search”, Artificial Intelligence, Vol. 42, No. 2–3, pp. 189–211, 1990.

[9] Cheverst, K., Davies, N., Mitchell, K., Friday, A. & Efstratiou, ”Developing a Context -Aware Electronic Tourist Guide”, Some Issues and Experiences. Proc CHI 2000. (April2000), pp. 17–24, 2000.

12