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.

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. 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. 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. (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. 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. 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. 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. • 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. 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. γ 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. 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. 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