GTNavi – Easy navigating around Georgia Tech
Transcript of GTNavi – Easy navigating around Georgia Tech
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 ................................................................................................... 3
II. PROPOSED WORK ......................................................................................................................... 3
1. Walking Path Direction ..................................................................................................................... 3
2. Mobile Handheld Device .................................................................................................................. 3
3. Real-time Navigator .......................................................................................................................... 3
4. Wiki page .......................................................................................................................................... 3
5. Friend Finder ..................................................................................................................................... 3
III. APPROACH AND METHODS ....................................................................................................... 4
1. Google Android Phone...................................................................................................................... 4
2. Google Map API ............................................................................................................................... 4
3. KML Data ......................................................................................................................................... 4
4. SQLite Database ............................................................................................................................... 5
5. Shortest Path Algorithm .................................................................................................................... 5
6. Direction determination .................................................................................................................... 6
7. Wiki page .......................................................................................................................................... 6
IV. GENERAL USAGE .......................................................................................................................... 9
1. Starting the GTNavi Application ...................................................................................................... 9
2. Showing pedestrian pathways and buildings .................................................................................... 9
3. Getting Directions to Destination ..................................................................................................... 9
4. Image Display ................................................................................................................................. 10
5. Directional Instructions ................................................................................................................... 11
6. Friend Finder ................................................................................................................................... 11
7. Wiki Page ........................................................................................................................................ 12
V. ARCHITECTURE .......................................................................................................................... 13
VI. EVALUATION ............................................................................................................................... 14
VII. FEATURES (3 most distinct) ......................................................................................................... 15
1. Real-time directional service with additional information .............................................................. 15
2. Wiki page ........................................................................................................................................ 16
3. Scalable data management and usage of new algorithm ................................................................. 16
VIII. WHAT WE LEARNED .............................................................................................................. 16
IX. FUTURE WORK ............................................................................................................................ 17
X. 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. APPROACH AND METHODS
1. 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>
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.
Dijkstra’s algorithm A* search algorithm Floyd-Warshall algorithm
functionality solves the single-pair
shortest path
solves the single pair
shortest path
solves the all pairs shortest
paths
description Dijkstra's algorithm
maintains a set S of
vertices whose final
shortest-path weights
from the source s
have already been
determined. The
algorithm repeatedly
selects the vertex
𝑢 ∈ 𝑉 − 𝑆 with the
minimum shortest-
path estimate, adds u
to S, and relaxes all
edges leaving u.
It uses heuristics to try to
speed up the search. The
algorithm traverses paths
from start to goal. For
each node x traversed, it
maintains 3 values:
g(x): the actual shortest
distance traveled from
initial node to current
node
h(x): the heuristic
distance from current
node to goal
f(x): the sum of g(x) and
h(x)
The Floyd-Warshall
algorithm defines
shortestPath(i, j, k) in terms
of the following recursive
formula:
shortestPath i, j, k = min(
shortestPath i, j, k − 1 , shortestPath i, k, k − 1 +shortestPath(k, j, k − 1) );
shortestPath(i, j, 0) =edgeCost(i, j);
The algorithm works by first
computing SP(i,j,1) for all
(i,j) pairs, then using that to
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
complexity 𝑂( 𝑉 2 + |𝐸|) The time complexity of
A* depends on the
heuristic. In the worst
case, the number of nodes
expanded is exponential
in the length of the
O(length of the shortest path)
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. GENERAL USAGE
In this section, the general usage of the application will be presented with relative screenshots
from the Android emulator.
1. Starting the GTNavi Application
At the Android desktop view, select the “GTNavi” icon, to start the application. A Google map
view will show up along with the current location of the user.
2. Showing pedestrian pathways and buildings
Click on the “Menu”, and “Show paths” and “Show buildings” will show the user the pathways
and buildings, respectively.
3. Getting Directions to Destination
First, the destination has to be picked. Click on the “Menu” button and then “Direction”. A list of
buildings is displayed in alphabetical order, and the user can scroll down to a specific building,
or type in alphabet to search for the building name.
After the destination is selected, the walking path to the point will be drawn on the Google map
with a distinct red line.
4. Image Display
Relevant images are displayed if they are uploaded by a user on the wiki page. If the user is close
to a building, images will be displayed according to the user’s view (north-east, north-west,
south-east, south-west).
The user can magnify the size of the image by clicking on it.
5. Directional Instructions
Turn right, or left instructions are given in real time. The instruction will be provided on the top
of the screen, with additional information like degree of turning, distance to the intersection point,
etc.
6. Friend Finder
This is presented with two instances of the Android emulator.
First, Android-5554 will send a request to Android-5556 for the geological location of Android-
5556 by sending a SMS message. If Android-5556 accepts it, it will send back the geological
coordinates to Android-5554.
Then, Android-5554 will display the shortest path direction to Android-5556.
7. Wiki Page
Wiki page usage explanation can be found in the Section II – 7.
V. 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 >
VI. 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.
< 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.
< 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.
-
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
7,000,000
0 100 200 300 400 500 600 700 800 900
DB file size
Array size
-
100,000
200,000
300,000
400,000
500,000
0 100 200 300 400 500 600 700 800 900
#of rows
< 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.
< 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.
VII. 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
0
20
40
60
80
100
120
0 100 200 300 400 500 600 700 800 900
DB update time
0:00:00.000
0:07:12.000
0:14:24.000
0:21:36.000
0:28:48.000
0 100 200 300 400 500 600 700 800 900
Algorithm running time
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.
VIII. 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.
IX. 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.
X. REFERENCES
[1] RNOC Project - http://rnoc.gatech.edu/projects/
[2] Google Android - http://www.android.com/#utm_campaign=en&utm_source=en-ha-na-us-
bk&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.