GTNavi – Easy navigating around Georgia Tech
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

GTNavi – Easy navigating around Georgia Tech

  • 1,113 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,113
On Slideshare
1,112
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 1

https://www.galileo.edu 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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>
  • 5. 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 solves the single pair solves the all pairs shortest shortest path shortest path paths description 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. 2 Time ( + ||) The time complexity of O(length of the shortest path) complexity A* depends on the heuristic. In the worst case, the number of nodes expanded is exponential in the length of the
  • 6. 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.
  • 7.  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>
  • 8. <Figure 3>
  • 9. 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
  • 10. 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.
  • 11. 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.
  • 12. 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.
  • 13. 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 >
  • 14. 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. 7,000,000 6,000,000 5,000,000 4,000,000 DB file size 3,000,000 2,000,000 Array size 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 200,000 #of rows 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.
  • 15. 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. 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
  • 16. 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.
  • 17. 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.