CS 8803 Advanced Internet Application Development, Spring, 2009
Project Final Report
GTNavi – Easy navigating around Georgia Tech
Pingping He, Hyojoon Kim, Sang Min Shim, Kai Wang (in alphabetic order)
Table of Contents
I.
MOTIVATION AND OBJECTIVES ................................................................................................... 2
II.
PROPOSED WORK ......................................................................................................................... 2
1.
Walking Path Direction..................................................................................................................... 2
2.
Mobile Handheld Device .................................................................................................................. 2
3.
Real-time Navigator .......................................................................................................................... 3
4.
Wiki page .......................................................................................................................................... 3
5.
Friend Finder..................................................................................................................................... 3
III.
APPROACH AND METHODS ....................................................................................................... 3
1.
Google Android Phone...................................................................................................................... 3
2.
Google Map API ............................................................................................................................... 4
3.
KML Data ......................................................................................................................................... 4
4.
SQLite Database ............................................................................................................................... 5
5.
Shortest Path Algorithm .................................................................................................................... 5
6.
Direction determination .................................................................................................................... 8
7.
Wiki page .......................................................................................................................................... 8
IV.
ARCHITECTURE .......................................................................................................................... 12
V.
EVALUATION............................................................................................................................... 13
VI.
FEATURES (3 most distinct) ......................................................................................................... 15
1.
Real-time directional service with additional information .............................................................. 15
2.
Wiki page ........................................................................................................................................ 15
3.
Scalable data management and usage of new algorithm ................................................................. 16
VII.
WHAT WE LEARNED .................................................................................................................. 16
VIII.
IX.
FUTURE WORK ........................................................................................................................ 17
REFERENCES ............................................................................................................................... 17
I.
MOTIVATION AND OBJECTIVES
Located in middle of the city of Atlanta, Georgia Tech is packed with buildings and surrounded
by numerous streets and roads. According to the data, there are 225 buildings in total just located
within the Georgia Tech campus. Locating all buildings and figuring out the direction to a
building in not a trivial task. Moreover, Georgia Tech has lots of visitors throughout a year.
Guest lecturers and tourists are only part of them. Although the campus has several map signs
installed around the campus, this is not enough and many visitors and newly admitted students
get lost while finding their way around. Navigation systems with driving directions are not useful,
as mostly they fail to show buildings which are not adjacent to car roads. The project’s objective
is to implement a scalable and effective navigation system with provides real-time directions
with walking paths within the Georgia Tech campus.
II.
PROPOSED WORK
1. Walking Path Direction
As Google Map already has a driving direction service, although it is not effective within
Georgia Tech, our project will provide a directional service using pedestrian paths in Georgia
Tech. It is very likely that students and faculties will be walking around the campus. This is
also the case for visitors and guests to Georgia Tech. Therefore, a walking path direction
service will be a helpful feature.
2. Mobile Handheld Device
The application is planned to be implemented in a mobile handheld device. This is to make
the application more useful and widespread. A user will only need a mobile phone which is
capable of internet access to use the proposed application. The application can be easily
switched and ported to as a web service, which is trivial work after the mobile application is
successfully implemented.
3. Real-time Navigator
The application is planned to provide a real-time navigation service, meaning that it will
provide real-time walking directions to the user. Using the GPS system within the mobile
device, the current location of the user will be updated in real-time and the application will
instruct the user according to his/her current geological location.
4. Wiki page
A wiki page will be setup to provide various users to contribute to the system. As the
application is intended to give additional information when directing users, a wiki page will
help the system to be more effective and useful, using the community’s help.
5. Friend Finder
A Friend Finder service is an additional feature added when working on the project. It
enables friends to find each other around the campus. If a user wants to find shortest path to
his/her friend, the friend only needs to send a SMS message to the user which contains the
geological information of the current location. The application will automatically extract this
information, and provide the shortest path to the friend from the user’s current location.
III.
1.
APPROACH AND METHODS
Google Android Phone
For the mobile handheld device, Google’s Android phone is chosen. This is because the
Android phone has all the functionalities our application requires, including internet access,
GPS system, instant messaging and more. Along with iPhone, we predict the Android phone
will get more and more popular. In addition, developing an application for Android is free
and well documented [2]. Along with the Android development kit, there is an Android
simulator which can be used to run and debug a developed application.
2.
Google Map API
As the project is basically a map service, a well developed map development environment is
needed. As the Android phone is tightly associated with the Google Map API, it is chosen to
do the work. Google Map API is also well documented [3]. The API itself is not
downloadable without registering. Upon requesting, we were able to obtain the code and API
for the map service. Displaying the map, zoom in/out and moving, drawing an overlay
pathway, showing an overlay image all requires the Google Map API.
3.
KML Data
As the project cannot use only the geological points provided by Google Map, additional data
was required. KML data uses a XML format to represent geological points and locations. The
KML data which contains all the pedestrian paths and building information within Georgia
Tech was obtained. Multiple parsers had to be coded to extract desired data from the KML
file for the purpose of filling the database.
<Figure 1. KML file>
4.
SQLite Database
SQLite is a scalable and light database system which is appropriate for implementing within
a device with limited resource. Therefore, this platform is chosen for the project, as the
application has to be implemented in a mobile handheld device where computation power
and memory size is limited. The application creates various tables to store related data to do
the intended work. A parser code is responsible of extracting data from the KML file and
populating the database tables.
5.
Shortest Path Algorithm
In our project, we need to find the quickest way to get from the current point to the
destination point on the map. It can be solved by the graph theory. In graph theory, the
shortest path problem is to find a path between two vertices such that the sum of the weights
of its constituent edges is minimized. In our case, the vertices represent locations and the
edges represent segments of road and are weighted by the time needed to travel that segment.
The most important algorithms for solving this problem are: Dijkstra’s algorithm, A* search
algorithm and Floyd-Warshall algorithm. The following table lists the differences between
these three algorithms.
functionality
description
Dijkstra’s algorithm
A* search algorithm
Floyd-Warshall algorithm
solves the single-pair
solves the single pair
solves the all pairs shortest
shortest path
shortest path
paths
Dijkstra's algorithm
It uses heuristics to try to
The Floyd-Warshall
maintains a set S of
speed up the search. The
algorithm defines
vertices whose final
algorithm traverses paths
shortestPath(i, j, k) in terms
shortest-path weights
from start to goal. For
of the following recursive
from the source s
each node x traversed, it
formula:
have already been
maintains 3 values:
shortestPath(i, j, k) = min(
determined. The
g(x): the actual shortest
shortestPath(i, j, k − 1) ,
algorithm repeatedly
distance traveled from
shortestPath(i, k, k − 1) +
selects the vertex
initial node to current
shortestPath(k, j, k − 1) );
𝑢 ∈ 𝑉 − 𝑆 with the
node
shortestPath(i, j, 0) =
minimum shortest-
h(x): the heuristic
edgeCost(i, j);
path estimate, adds u
distance from current
The algorithm works by first
to S, and relaxes all
node to goal
computing SP(i,j,1) for all
edges leaving u.
f(x): the sum of g(x) and
(i,j) pairs, then using that to
h(x)
find SP(i,j,2) for all (i,j)
pairs, etc. This process
continues until k=n, and we
have found the shortest path
for all (i,j) pairs using any
intermediate vertices.
Time
𝑂(|𝑉|2 + |𝐸|)
complexity
The time complexity of
O(length of the shortest path)
A* depends on the
heuristic. In the worst
case, the number of nodes
expanded is exponential
in the length of the
solution (the shortest
path). But it is
polynomial when the
search space is a tree.
Space usage
O(|V|)
𝑂(|𝑉|𝑖 )
𝑂(|𝑉|2 )
Since our program should recalculate the shortest path in real-time when the user moves, we
choose Floyd as our shortest path finding algorithm. Floyd algorithm is faster than the other
two, but it uses more memories. So we have to struggle to design algorithm and write codes
that use memory efficiently, e.g., storing the edges in the form of node indices, instead of the
node coordinates.
6.
Direction determination
As our application does not use the Google Map direction service to calculate the path, we
have to implement the code which will determine the direction. For instance, the application
has to guide a user to turn right, left, or go straight at the intersection point ahead, along with
the distance left and the degree of turning. A code was implemented especially to fulfill this
feature, using several equations and math notions. As the result, the application is capable of
giving direction in real-time, according to the user’s current position.
7.
Wiki page
 Why do we need it?
Since the wiki conception is getting more and more popular in people’s Internet life, the
ideal of building a wiki page for our project comes up. The wiki conception, generally, is that
the system provides the authority to the users doing the contribution to it. Specifically, in our
project, for the scalability so far there are over 300 buildings and landmarks around the
campus. And the functionality of the system allows at most four different directional-took
(southeast, southwest, northeast and northwest) pictures for each building, which is a huge
task for the developers. Rather than taking all the pictures by ourselves, we decided to build a
platform to let users upload the picture to refine the system on their own.
Except the motivation that mentioned above, there is another issue on Android makes us
setup the wiki page separately instead of integrating it into the system. Ideally we expect to
develop a function that allows users uploading the picture from the cell phone. Unfortunately,
there is a flaw on the Android which is there’s no file browser on G1 and for the security
consideration the upload function in the web browser is also disabled. Based on these two
points, we decided to build a wiki page separately.
 How do we implement it?
We choose PHP as the web development programming language, which provides the
more convenient and efficient approach to implement the upload function. The uploaded
pictures will be stored on the server with a specific file name, based on where the user’s
location is, our navigator system will download and display the related pictures on the map.
The basic function is as followed.
 The user picks one building from the drop-down box. If there are already some
pictures for it, they will be displayed in the related box; if not, the box will be blank.
(figure-2)
 After user finishing the photos picking, the preview will be displayed, and the user
can click the “upload” button to upload them. (figure-3)
 What needs to improve?
So far, there are two main improvements of the wiki page could be done in the future
work. One is for the geological location related pictures uploading. Currently, our wiki page
only allows users uploading the pictures for the specific buildings. What we are going to do
next is to get the geo-points of the user’s location from the cell phone when he triggers the
uploading function. Not only the user can upload the pictures for a new place, but he can
write the description of this new point he just created. This will make our system more
flexible when there are some new landmarks appear in the campus.
The second one is to solve the duplicated uploaded pictures problem. For now, if a user
uploads a picture that the building has already had one, the old one will be covered by the
new one. We will solve this problem to make our system support more than one picture for
one direction of each building, which might give the different looks in different season for
each building and so forth.
<Figure 2>
<Figure 3>
IV.
ARCHITECTURE
The architecture of the application is as below. It is composed with the Map module, GPS device,
and the Navigator module. All modules are combined and managed by the Main module.
< Figure 4. Architecture >
V.
EVALUATION
To measure the scalability and efficiency of the application, various evaluations are conducted.
All following graphs have a same X axis; the number of intersection points in KML data.
7,000,000
6,000,000
5,000,000
4,000,000
DB file size
3,000,000
Array size
2,000,000
1,000,000
0
100
200
300
400
500
600
700
800
900
< Figure 5. Database file size and Array size >
Figure 5 shows the database file size and array size (in bytes) according to the number of
intersection points. Both graphs are in a scale of n2.
500,000
400,000
300,000
#of rows
200,000
100,000
0
100 200 300 400 500 600 700 800 900
< Figure 6. Number of rows in database table >
Figure 6 shows the number of rows in the database table according to the number of intersection
points. The scale is in n2 as well.
120
100
80
60
DB update time
40
20
0
0
100
200
300
400
500
600
700
800
900
< Figure 7. Database update time (in min.) >
Figure 7 shows the database update time (in minutes) according to the number of intersection
points. The scale is in n2.
0:28:48.000
0:21:36.000
0:14:24.000
Algorithm running time
0:07:12.000
0:00:00.000
0
100
200
300
400
500
600
700
800
900
< Figure 8. Algorithm running time (in min.) >
Figure 8 shows the algorithm running time of constructing the database system (in minutes)
according to the number of intersection points. The scale is in n3. The total time spent for
database update is the combined time of figure 7 and 8. As you can see, scalability can be an
issue if the number of intersection points increases, although this update does not occur
frequently, and does not affect the actual usage of navigation feature in real time.
VI.
FEATURES (3 most distinct)
It is hard to pinpoint the 3 most distinct features in the application, as there are many of them.
However, these are the chosen features to be the most outstanding.
1.
Real-time directional service with additional information
A major extension to the previous work is that our system is available to provide real-time
directional service with additional information, e.g. image of buildings. By fetching the
current location of the user by the GPS system, our application provides instructions like turn
right or left, along with the distance and degree of the turn. In addition, images of buildings
which are close to the user will automatically appear on the screen. The user can click on the
image to enlarge it for better recognition. For one building, there are four images associated
with it; northeast, northwest, southeast, southwest view. The image will change automatically
according to which side of the building the user is currently located. For instance, if the user
is on the northwest side of the building, the image for the northwest side of the building will
be displayed. If the user continues to the northeast side, the image will change to the
northeast side view of the building. This will significantly help the user to have a clear idea
where he/she is currently located.
2.
Wiki page
Wiki page provides a way to improve our application by user contribution. This part is
explained in detail in the above. Currently, our wiki page only provides the functionality to
add images of all buildings. However, we believe there is a huge amount of space for
improvement. We consider our simple wiki page as a significant starting point, which
provides the possibility of improvement of the application driven by users. This kind of
interaction between users and application is important, as the application provides the
platform to improve itself by using the knowledge and power of its own users.
3.
Scalable data management and usage of new algorithm
As the application is intended to be used in a mobile device, scalable data management was
forced in design and implementation. Our application is signified by its efficient and scalable
data management. Minimizing the size of database tables, yet not limiting its intended
functionality was a challenge. After hard work and intensive optimization, the application is
able to run on the limited memory size and computation power of a typical mobile device. In
addition, instead of using the non-efficient Dijkstra’s algorithm, our application uses a
powerful yet efficient Floyd-Warshall algorithm [6], [7]. This algorithm enables to produce
the optimal shortest path, yet being scalable.
VII. WHAT WE LEARNED
The motivation and idea for the project has come from the research field of mobile computing
and location aware service. Specifically, the project is highly related to the lecture in week 2,
which was about “Mobile Computing and Location Aware Computing”. Knowledge of mobile
computing techniques and various geological applications inspired the project.
We learned that mobile computing is a challenging field, as the environment itself is limited in
resource. Computational power and memory size is limited in mobile devices. Therefore,
applications have to be especially efficient and scalable. Efficient and performance-aware
programming was required.
As Google’s Android phone was chosen for the implementation environment, we were able to
gain experience in mobile programming, especially with Android SDK v1.1.
VIII. FUTURE WORK
There are several parts in the application where improvement is desirable. There are left as a
future work.
First, a better wiki page can be constructed, to encourage more contribution by the users.
Currently, our wiki page only provides a feature to add images for all buildings. An
improvement to this can be made by, for instance, allowing users to pick intermediate nodes
along the way. Even as our application picks the shortest path from the source to destination
point, there may a better path, when that path is easier to walk through for people. If this is a case,
a user should be able to contribute to the application by notifying this new, better path.
Second, the application still has some room for improved efficiency. When all the pedestrian
pathways and buildings are displayed on the path, our application, GTNavi, tends to slow down,
burdening the mobile system and sometimes making it not responding for a while. Considering
that Georgia Tech campus is relatively a small one when compared to other universities and
college campuses around the U.S, more improvement in scalability and efficiency is desirable.
IX.
REFERENCES
[1] RNOC Project - http://rnoc.gatech.edu/projects/
[2] Google Android - http://www.android.com/#utm_campaign=en&utm_source=en-ha-na-usbk&utm_medium=ha&utm_term=android
[3] Google map API - http://code.google.com/apis/maps/
[4] Android Emulator - http://code.google.com/android/reference/emulator.html
[5] SQLite Database - http://www.sqlite.org/
[6] R. W. Floyd, “Algorithm 97: Shortest path”, C.ACM, 5, 6, pp. 345, 1963.
[7] S. Warshall, “A theorem on Boolean matrices”, J.ACM, 9, 1, pp. 11-12, 1963.