Published on

In this paper, we propose a personal navigation system for tourism called P-Tour. When a tourist specifies 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 to the map-based navigation, P-Tour provides temporal guidance according to the schedule, and automatically modifies the schedule when detecting the situation that the tourist cannot follow the schedule. We have developed a route search engine as a Java Servlet which can compute a semi-optimal schedule in reasonable time using techniques of genetic algorithms.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. P-TOUR: A PERSONAL NAVIGATION SYSTEM FOR 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 ABSTRACT In this paper, we propose a personal navigation system for tourism called P-Tour. When a tourist specifies 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 to the map-based navigation, P-Tour provides temporal guidance according to the schedule, and automatically modifies the schedule when detecting the situation that the tourist cannot follow the schedule. We have developed a route search engine as a Java Servlet which can compute a semi-optimal schedule in reasonable time using techniques of genetic algorithms. INTRODUCTION Due 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. KDDI provides a service called EzNaviWalk on its cell phones which navigates a user to a specified destination 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 navigates the user in the most suitable way. [2] proposes an indoor navigation system which aims at provisioning the coherent navigation service to different devices. [3] proposes a system to support 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 the sightseeing tour, tourists want to visit multiple destinations (sightseeing spots) efficiently under some restrictions. For this purpose, the existing navigation systems are not sufficient. In the navigation systems for tourism, unlike car navigation systems, it will be necessary to 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 a portable 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
  2. 2. time at each destination considering timeliness (e.g., opening hours of the facility, starting time of 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 and multiple candidate destinations with relative importance degrees and time restrictions on arrival and staying time, a nearly best schedule can be computed. P-Tour can efficiently navigate the tourist according to the decided schedule through a portable computing device with GPS. In addition to the popular map-based navigation, P-Tour provides temporal guidance (e.g., showing remaining time to departure at each destination) for the tourist to follow the schedule. Moreover, P-Tour can automatically modify the schedule when 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 relative importance degree and/or staying time and schedule is re-computed repeatedly. Schedule is also re-computed during the tour due to context changes. Accordingly, the computation time should be reasonably small (e.g., less than 10 seconds). However, the above problem which computes the optimal route including multiple destinations with restrictions is a superclass of TSP (traveling Salesman Problem) which is known as a NP-hard problem, and thus it takes much computation time to obtain an optimal solution. So, we have developed a route search engine 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 devices via HTTP protocol. Our experimental results show that our route search engine can compute a reasonable travel schedule 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 the difference between the obtained solution and the optimal solution is within 2%. OUTLINE OF P-TOUR As shown in Fig. 1, P-Tour consists of (1) a client module running on a portable computing device with GPS and wireless communication capability and (2) a server module running on a PC connected to the Internet. The PC has a database including map data and recommended candidate 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 users according to a decided schedule through the client module executed on a portable device. 2
  3. 3. Function for Planning Travel Schedule This function allows a user to plan the nearly best travel schedule which includes a subset of specified candidate destinations and a route to visit the subset of all destinations satisfying specified restrictions. As of restrictions, P-Tour treats the total time for the tour, geographical distances 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 locations and 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 restriction to arrival time at each destination (e.g., “before 2:00PM”) and (5) a restriction to staying time at each destination (e.g., “more than one hour”). Here, (4) and (5) are optional. In order to facilitate 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 those destinations by setting 0 to their importance degrees. From the above input, P-Tour computes a schedule consisting of (i) a set of destinations and the route to visit all of them, and (ii) the expected arrival time and the departure time at each destination. P-Tour shows the output schedule to the user. The route is computed so that the user’s satisfaction degree (defined later) is maximized under the given restrictions and the moving time between destinations. Here, the moving time between two destinations is calculated by dividing the distance of the shortest path (obtained by A algorithm) between those destinations by the user’s moving speed. We assume that the distance 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 modifying the importance degree/time restrictions at each destination. We have designed and implemented a fast route search engine based on the techniques in genetic algorithms (GA). The details of the engine are explained in the next section. Function for Navigating User According to Schedule P-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 of destinations to visit with arrival/staying time are displayed on the screen of the portable device as shown in Fig. 2(a) and (b). In moving mode, the map around the current location and the route to the next destination are displayed like car navigation systems (Fig. 2(c)). In staying mode, 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 system prompts the user and automatically switches to moving mode. Switching between moving and staying modes is automatically done by monitoring the current location obtained by GPS and the present time. Automatic Schedule Modification by Context Change During the tour, the user may fall into the situation that he/she cannot follow the schedule. For example, if the user cannot move to the next destination at the expected speed due to traffic jam 3
  4. 4. (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 cannot be 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 is modified, 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 can recompute the schedule after modifying candidate destinations and/or importance degrees/time restrictions to some of them. ROUTE SEARCH ENGINE To 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 multiple solutions 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 and the distances between any two of predefined destinations. If some destinations specified by the user do not exist in the database, the shortest paths and the distances between these destinations are calculated using A algorithm[8]. PROBLEM DEFINITION The objective of the route search engine is to find a route with an evaluation value close to the highest value, where the evaluation value is, in brief, increased by the importance degrees of destinations 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 by D = {d1 , d2 , ....., dn }. Each destination data di consists of five components, vi , rti , duri and pre, where 4
  5. 5. vi : a location in the map rti : 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 = d1 , d2 , ..., dk , where dk ∈ D, 1 ≤ k ≤ |D| and dk 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 dur i at each destination di . Destinations satisfying the time restriction is denoted as S = d1 , d2 , ....., dj , where dj ∈ 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 which satisfy time restrictions included in the list is calculated. If we use this value as the evaluation function, devious routes may be produced. So, we have defined evaluation function as follows, k j k−1 f (S) = α pre(di ) + β pre(di ) − γ dist[di ][di+1 ] i=1 i=1 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 the total distance. Long route gives low evaluation value if γ value is increased. ALGORITHM To make it possible to add or delete destinations in candidate solutions, a candidate solution is coded as a variable length list of destinations. The search procedure is as follows. 1. Predefined number of candidate solutions are generated randomly. An evaluation value is 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 solution with 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 operator called one-point crossover. The crossover point is chosen randomly, and redundant destinations 5
  6. 6. 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 produced by one-point crossover. In this case, since x, y, b, c, y contains two occurrences of y, one of the occurrences of y is deleted. 4. A GA operator called mutation is applied to the newly generated candidate solutions. Our mutation operator consists of 2-opt and addition/deletion of a destination. 2-opt is the technique to 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 that the elite individual is preserved. 6. Local search is applied to the elite individual. One destination which is not included in the route of the elite individual is randomly selected and inserted into randomly selected position in the route. After evaluation of the new route, the evaluation value is compared to that of the original route. If evaluation value doesn’t increase, the change is canceled. The process above is 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. IMPLEMENTATION We have implemented P-Tour as a client-server application system. Our route search engine explained in the previous section has been implemented as a Java Servlet which is executed on a server PC connected to the Internet. The client module executed on a portable computing device has been implemented as a Java MIDlet for cellular phones. NAVIGATION FUNCTION In order to plan a schedule, a user inputs some information for the tour on a cellular phone, and sends it to the server using HTTP. Then, he/she receives the schedule computed on the server as a 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 with estimated arrival/staying/departure time (Fig. 2 (b)); The above information is displayed by pushing the corresponding button on the user’s cellular phone. During the tour, the graphical map around the user’s current location is displayed on the screen as shown in Fig. 3. The client module measures the current location through the GPS unit on the cellular phone, and sends the current location and a request to update map to the server module. Then, the server module composes the latest map image (in JPEG format) and sends the image as the response. This update is repeated periodically while the user moves between destinations. USER INTERFACE To plan a schedule with P-Tour, a user may have to input a lot of information. So, the user interface is important. We have adopted an web-based user interface since most people can learn the operation via web browsers quickly and intuitively [9]. Also, there is a merit that ordinary PCs can be used when planning a schedule. 6
  7. 7. We have implemented a user interface as shown in Fig. 4, where data items are input using HTML 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 user inputs 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/time restrictions to a destination, default values are used for the destination. From some experiments using this interface on a cellular phone, we confirmed that the interface can be used comfortably, and data can be input smoothly. (a) (b) (c) Figure 5: Snapshot of Interface DETECTION OF CONTEXT CHANGE We have implemented in the client module a mechanism to detect the situations that the user steps away from the route in the schedule, the current schedule cannot be achieved due to the delay to arrive at the next destination or some other reasons. When the client module detects such a situation, it alerts to the user by showing a path returning to the original route or 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
  8. 8. • If the user goes into a wrong route : Let T stopover denote the time to follow the shortest path from the user’s current location to the original route considering the user’s speed. The server can easily calculate and tell T stopover to the client module when updating the navigation map. For example, we can let the client module to alert to the user when T stopover exceeds 3 minutes, and to recompute the schedule when T stopover exceeds 10 minutes. • If the user cannot arrive at the next destination until the scheduled arrival time or the user departed a destination later than scheduled : We assume that staying time of each destination includes GU ARD T IM E minutes of margin. Let T prdarv denote the pre- dicted arrival time at the next destination, which is calculated by the current time, the distance between the user’s current location and the next destination, and the user’s mov- ing speed. T prdarv can easily be calculated by the server and told to the client module when the navigation map is updated. Consequently, we can implement this function as follows: if T prdarv is later than the scheduled arrival time at the next destination, the client module alerts to the user; and if T prdarv is later than the scheduled arrival time plus GU ARD T IM E, the client module requests re-computation of the schedule. EXPERIMENTAL RESULTS AND EVALUATION In 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 Nara prefecture in Japan which have 30 recommended candidate destinations. Here, we have set the starting/returning locations to our university (NAIST) and the starting/returning time to 9: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 on the market for car navigation systems. The route search engine has been executed on a general PC with GNU/Linux, Tomcat4.1, Pentium4 2.4GHz and 512MB RAM. As coefficients of the evaluation 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 to 100th iteration(generation) since the evaluation values of the computed routes converge to the highest ones in most cases. APPROPRIATENESS OF COMPUTED SCHEDULE At first, we investigated to what extent our route search engine can compute the appropriate schedule depending on the user input. As of the user input, we used the setting in Table 1. In Table 1, we specified 30 candidate destinations 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 restrictions on 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 D4 and D13 to 10, the new route including D4 and D13 were output as shown in Fig. 7. 8
  9. 9. destination no. name importance degree arrival time staying time D1 Toushoudaiji temple 5 – =60min D2 Yakushiji temple 5 – =60min D3 Houryuji temple 5 ≤ 15:00 ≥ 180 min D4 Fujinoki tomb 5 – =90min D5 Heijoukyou 5 – =150min D6 Saidaiji 5 – =30min D7 Gakuenmae Station 5 ≤ 19:30 ≥ 60 min D8 Sarusawaike pond 5 – =60min D9 Manyou arboretum 5 – =45min D10 National museum 5 – =60min D11 Shinyakushiji temple 5 – =60min D12 Shousouin 5 – =30min D13 Daianji temple 5 – =60min D14 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 degree on the computed route. In order to show the appropriateness of the evaluation function, we investigated the property of the computed routes by changing the value of γ among 0, 40, and 80. Here, as γ value is smaller, the evaluation value of the shorter route becomes large. The computed routes when using the user input in Table 1 are shown in Fig. 8 and in Table 2. The numbers 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 is because 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 included in the output route (Fig. 8 (c)). Because the total distance of the route largely affects the evaluation 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
  10. 10. γ no. of destinations total distance arrival time at D3 arrival time at D7 0 8 55 Km 14:40 19:10 40 8 45 Km 14:50 18:50 80 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 can be computed. If the gamma value is changeable by the user, he/she may be able to find more preferable route easily. (a) γ = 0, (b) γ = 40, (c) γ = 80, Figure 8: Appropriateness of Routes Depending on γ TIME TO COMPUTE SCHEDULE Since genetic algorithms always have the candidate solutions, solution can be output even when stopping the search after a specified constant time expires. Here, we measured the computation time and the quality of solutions by changing the number of generations in our route search engine. The results are shown in Table 3. We assume that the shortest path and its distance between 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 a sufficient 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 compute the schedule repeatedly until getting the favorite one. So, we modified the user input in Table 1 by removing one destination D3 in the route of Fig. 6 and by specifying a new time constraint to destination D5. Then we recomputed the new route using candidate solutions after computing the previous route in Fig 6. 10
  11. 11. As a result, the computation time was less than 1 second. This is because our route search engine 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 SOLUTION We 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 our search 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. Independently of the number of destinations, the deviation ratio of the routes computed by our route search engine was less than 2%. When the number of destinations is 14, it took about 22 hours to compute the optimal route, while our engine could compute the semi-optimal route less than 15.5 second. num of generations computation time eval value 5 2.6 (sec) 2322 10 3.0 (sec) 2531 20 5.2 (sec) 2542 50 11.0 (sec) 2582 100 15.5 (sec) 2582 Table 3: Computation Time Depending on Number of Generations CONCLUSION In this paper, we proposed a personal navigation system for tourism called P-Tour. P-Tour provides 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 according to the planned schedule through a portable device with GPS, and (3) for modifying the schedule automatically 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. On experiments using a digital map on the market, the time for computing a schedule for a typical scenario is about 5 seconds. The time for re-computation after modifying the user input is less than 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 implemented as a Java Servlet on a WWW server. So, most Internet users can use the schedule planning function of P-Tour through web browsers. Also, the navigation function of P-Tour can be used by various portable computing devices including cellular phones, PDAs and note PCs which have GPS units and communication capability. In our current implementation of P-Tour, we suppose that users move between destinations by a single mean of transportation (e.g., by car or by walk). As part of future work, we are planning to extend our system to handle multiple means of transportation such as train and bus. 11
  12. 12. 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 Acknowledgements We thank the Navigation System Researchers’ Association for providing the digital road-map format. References [1] Baus, J., Kr¨ ger, A., Wahlster, W., “A Resource Adaptive Mobile Navigation System”, Pro- u ceedings of IUI2002: International Conference on Intelligent User Interfaces 2002, ACM Press, New York ; [2] Butz, A., Baus, J., Kr¨ ger, A., Lohse, M., “A Hybrid Indoor Navigation System”, Proceed- u 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 GIS BASED 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 Genetic Algorithm for Car Navigation Systems”, IEEE Conference on Intelligent Transportation Systems (ITSC 2000), pp. 119–124, 2000. [5] Zipf, A., and Malaka, R., ”Developing Location Based Services (LBS) for tourism - The service providers view”, Information and Communication Technologies in Tourism 2001. Proceedings of ENTER 2001, 8th International Conference. Montreal. Springer Computer Science. 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 a tourist 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. (April 2000), pp. 17–24, 2000. 12