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.