1 Tour Tracker

7/29/2019 1 Tour Tracker

1/7

TourTracker: A tour recording and sharing application forAndroid

Julius Bartkus, Alvis Davidavicius, Roland Beta

IT University of CopenhagenRued Langgaards Vej 7, 2300 Copenhagen. Denmark{julb,adav,rolb}@itu.dk

ABSTRACT

Most tour guide applications do not allow their users to cre-ate and submit their own tours, but only provide the possi-bility to choose between the available ones. As the phonesare becoming more powerful and get more abilities to sensethe environment it should be easier to create tours using mo-bile phones than stationary computers. This can add a newexperience for creating guided tours and following the oneswhich were already taken by someone. Those might evencome with pictures shot during the trip. This paper describes

the TourTracker mobile application that enables its users tocreate digital versions of their own tours and share it with thepublic. That is why users of the application can be both con-tributors and consumers of this service. The application isa part of a client-server system, where the client applicationruns on the mobile devices, collects the tour coordinates bycontinually checking the path the user has done. At the endof the tour the user can upload the tour to the server withsome additional information. In the paper we present thedesign, implementation and evaluation of the TourTrackersystem. Our intention was to investigate that the nature ofthis application it is more appealing to the users because thetours were suggested by other tourists.

Author Keywords

Android, Tour Tracker, GPS

1. INTRODUCTION

Tourism and visiting new places has a long tradition in ev-ery culture and with the evolution of technology the waypeople plan their tours has changed too. People have dif-ferent preferences about exploring new areas, cities or na-ture. Some like the security of organized tours and tourguides who can provide information about the specific lo-cation, others prefer being their own guides and planningthe tour themselves. In this report we present a solutionwhich combines the previously mentioned two approaches.

As positioning technologies became mainstream, new ser-vices were introduced, which offered mobile device-guided

Paper submitted for evaluation in the Pervasive Computing Course, Fall2010. The IT University of Copenhagen.

and pre-configured tours, where the presence of real tourguides was no longer necessary. These device-guided toursprovide more freedom to the users, but are still lacking on thesocial part of the experience. Most of the services are one-sided, meaning that users can choose fom predefined tours,but cannot share their own. The success of most social siteslies in allowing the users to share experiences, memories,thoughts, photos, notes, etc. Sharing trips with others can bea new, rewarding experience for contributing to the touristsociety. Choosing a tour from such a service is also more in-

teresting, since the tours are contributions from people whohave completed and posted the tour themselves.

The technology needed for a tour sharing application is notmuch different from mobile tour guide devices. They areboth able to detect the location of the user by using position-ing systems, however, with our solution the recorded pathcan be uploaded to a central server. Therefore the tour canbe made permanently available and public. The applicationpresented is created with robustness in mind, meaning flexi-ble design that allows relying on more ways of determiningthe users location in case one would not be available.

The report starts with introducing the main idea. Section 2

presents the related work and products available for tour andpath tracking purposes. In section 3 we use these examplesto define a number of key design principles, requirementsand evaluation methods for our system. Section 4 presentsthe results of our evaluations and findings. In section 5 wediscuss design decisions, their limitations and possible so-lutions for them. Finally, the report is concluded in section6.

2. RELATED WORK

A survey [5] states that 93% of the tourists in Heidelbergexplore the city by foot on their own, without a guided tour.That also means that they move within a limited area, mostlyin the Old Town and miss all other places of interest whichare further out the town. From this we can also concludethat a guided tour application would solve this problem asit is for free and leaves the same freedom for exploring asbefore, except that the tourists know where to find the sights.

A number of systems have been developed which provide anability to record trips onto external system (server) for laterretrieval of information and replay on the mobile phones. AMobile Tourist Companion [4] is one of them. This appli-cation is a context-aware system for mobile phones using

1


2/7

location-based tracking system GPS. That system focuseson the gathering user specific data such as gender, occupa-tion, interests and afterward fetching relevant informationfrom different sources which could be in the interest field ofthe user. A commercial system called Trip-Journal has a setof features allowing the user easily document travel experi-ences using picture, note taking and route tracking.

Trip-Journal

1

is an example of the systems which is built fora specific case - creating trip journals. Unlike our system,however, Trip-Journal focuses on creating visually attrac-tive memories, journals of trips and sharing it with relatives,friends. There is no possibility for other people to downloadthese as guided tours to follow.

The team working on the Cyberguide mobile context-awaretour guide [1] took a different approach for defining howsuch a system would work and look like. They prototypedthe device for different scenarios, requiring different hard-ware, user interface, and communication technologies. Theguide provided information according to the users locationor what the user is looking at. The different iterations of the

system either worked indoors or outdoors but not both, be-cause of technology limitations. At the time of their experi-ments the available wireless technologies were very limitedso they had to rely on alternative ways of location tracking,such as infrared transmitters. Also, because of low band-width, the creators were forced to store data heavy informa-tions, such as pictures locally. A major difference comparedto our focus is that all information was provided for the userby the tour guide and the user had no possibility of alteringor sharing the perceived information.

The usefulness and popularity of providing information aboutnearby objects was investigated in the GUIDE project [3].They compared two methodologies. The first using the Lan-

caster GUIDE system, which works by identifying the userslocation and asking for specifying the distance of the objectfrom their current location. By the location and distance datathe system can guess what the user sees and provides rele-vant information. The other approach was to take a digitalimage of the object and run it through an image recognitionsoftware and identifying the object that way. They found outthat a significant number of users embraced digital imagerecognition despite it required more effort and had signifi-cant disadvantages compared to the dialog based system. Wefound providing information about nearby locations a highlyattractive feature in tour guide applications and it could beimplemented in future versions of our application.

Mobile applications requiring network connection have to berobust, reliable and have to handle network or even poweroutages naturally. Developers of the ContextPhone Context-Aware mobile platform [6] achieved handling these situa-tions by storing all the outgoing data locally on the deviceuntil it has been successfully uploaded after recovering froman outage. This is a fairly straightforward approach and itcould be very well used for our application. Another inter-

1http://www.trip-journal.com/

(a) Menu (b) Add note

esting concept they mention is the eXtreme Programming2

paradigm: Build the simplest thing that could possibly work.Considering our previous development experience and thispapers ratification we decided to apply this in our design.

Some of the presented related work in the mobile tour guidefield has similar characteristics to our system, e.g. the Trip-Journal application, however the purpose of sharing is differ-ent, it is about sharing memories, not providing guidenanceto others. Other, like the ContextPhone and Mobile TouristCompanion focus more on providing information accordingto the sensed context which is not our focus. The surveyconducted by Freytag shows that there is a need for mobiletour guide systems and other papers e.g. ContextPhone gaveus ideas for the design of the system and possible additionalfeatures for future versions.

3. THE SYSTEM

3.1 Demo of the application

We start presenting the system by going through the mainfeatures of the application and show how they look on thescreen.On the first start of the application the user is shown his lo-cation if GPS is enabled on the phone, otherwise requestedto turn GPS on. In the menu select Record new to start a newtrip. Enter the name of the trip. (Figure 1(a)). The path isdrawn if the user is moving. A label is showing the nameof the trip and selected provider (GPS) used to get locationupdates. In the menu Pause/Stop buttons become active.

For adding notes double tap on the desired location on the

map and enter the note. (Figure 1(b)) The added note isdiplayed with a small blue speech bubble. On double-tappingthe note again we can edit or remove the note. When select-ing Trips from the menu the user is shown a list of locallystored trips with a green Load flag, meaning its ready to beshown on the map. Download Trips will get a list of avail-able tours from the remote database. The remote trips aremarked with red Download note. They can be downloadedby tapping on them. (Figure 1(c) The downloaded trip is

2http://www.extremeprogramming.org/

2


3/7

(c) Local and Remote trips (d) Trip loaded

added to the top of the list and marked with green. Whentapping on a local trip it is loaded to the map with all itsnotes. (Figure 1(d)).

The applications key focus is tracking the geographical lo-cation of the user and keeping a history of visited points.This is done by subscribing to the system location servicesand storing the records in a local database. A path is beingtracked when the user selects the record function and is com-posed of users locations since the user started recording. Anew location is set to differ from the previous one by specificdistance in space and time. When the application receives anew user location, it processes the data and updates the localdatabase. All of the saved points in one recording make upthe path.When recording, the user can add pin-point notes to the mapby double tapping a location on the map and entering sometext. In this case the tap location on the display is convertedfrom screen pixels to the geographical location and is storedin the database along with the text.The recorded path and pin-point notes make a tour that theuser saves locally and can upload to the remote databaseserver.The other way of using the application is downloading thetour from the remote database. The tour is displayed on themap and the user can follow its path and read location rele-vant notes.

The target device of the application is mobile and has a lim-ited amount of energy. Location receiving consumes a lotof battery power, so we took resource efficiency into con-sideration. Tracking is done only when the application is inforeground of the screen in the viewing mode and is alwayson when recording. The system lifecycle API helps achiev-ing the goal and we also use a custom state object to managethe application.Wireless connectivity is yet another valuable resource, whichis recognized, but not addressed fully in the program - inter-net connection is needed in order for the application to dis-play the map images. A tour can be recorded if internet con-nection is unavailable as the GPS coordinates are receivedregardless of the fact if the user has access to a map or not.

As soon as the user gets to a location where internet connec-tion is available the map is drawn and the path can be bettervisualized. The issue of storing images in persistent memoryis further addressed in the subsection 5.1 of the discussionssection.

3.2 Design considerations

Applications on different devices should be developed withdifferent considerations in mind. These are determined bythe factors like power resources, computing power, portabil-ity, connectivity, robustness, etc. Despite the rapid evolu-tion of handheld devices they are still lacking computationalpower, connectivity is uncertain and devices run from a bat-tery. With these constraints in mind we came up with thefollowing design guidelines that we should follow:

KISS3 - only the necessary features are needed to be im-plemented in a lightweight and efficient way

Exception handling - network connection outages shouldbe handled as natural events, the application should con-tinue to work in offline mode

Extensibility - as we rely on different providers of locationdetermination and maps the design should allow for easyimplementation of new providers

3.3 System concept

Apart from the mobile device there are more elements whichhave an important role to make the system work. The appli-cation gets location data from the GPS satellites. The peri-odic location updates are saved on a local database and onthe request of the user it is uploaded to the central database.Tours are also retrieved from the same server. The com-munication is establish with a RESTful manner, specificallyby HTTP POST and HTTP GET queries. The location datasent to the server and the reply is parsed into JSON format.Communication with the GPS satellite is handled internallyby Android OS. We specified in the application how oftento get location updates and the minimal distance from theprevious location to be notified about. These settings arenecessary for the WiFi based providers too. After a trip hasbeen uploaded from one device it is possible for other de-vices to download it. A conceptual diagram of the system isdepicted in figure 1

3.4 System architecture

The architecture of the mobile application follows the threelayered (gui, model, service) approach and follows our first

design consideration, KISS. The complete Class diagram isdepicted in figure 2.

Service layer

In the Service layer two singleton service classes providemethods to connect to either local or remote database. Thelocal is the Android provided SQLite database, which is alightweight, but has all the necessary functionality needed inthis case. The class allows for adding, retrieving, updating

3Keep it Short and Simple

3


4/7

Figure 1. Conceptual diagram

Figure 3. Database scheme

and removing the locally stored trips; adding and retrievingtrips points and note; additional helper methods for main-taining the state of the application. The service class for theremote database has methods for uploading, downloading atrip and getting a list of available trips.

Database architecture

The remote database is based on MySQL and its scheme isdepicted in figure 3. The local database has the same struc-ture as remote database except that it also holds a remote tripid in order to keep track of remotely stored trips.

The design of the database supports extensibility in case moredata needs to be attached to a specific table or field. In orderto avoid inconsistencies and improve database performancethe database model has been normalized i.e. all non-key at-tributes became fully dependent on its primary-key. More-over database structure implements foreign key constraints

what makes the application more reliable in case of failure.

Model layer

The Model layer captures the domain classes of our sys-tem, the asynchronous sending mechanism and other helperclasses. The domain of the system is captured by the classesTrip, Point and CurrentState. NotePoint combined the Pointand Note classes which is needed to add notes to a certaingeographical location on the map. PointType is a simple enu-meration which tells us whether a point is a pinpoint or part

of the path. CurrentState captures the state the application isin and it is an Observable class which is used to notify theObserverclasses when a change occurs in the state. The Lo-cationManagerprovides access to system location servicesto obtain periodic updates of the users location.The Client class provides the static method to send HTTPrequests to the remote server. Requests are sent by the Asyn-chronousSender in a new thread to avoid hanging the appli-cation. When sending the request we provide the request anda class which implements the ResponseListenerinterface forreceiving and handling the response from the server when itis available. The stability of the application in this way isgreatly improved.

JSONServerResponse is a helper class to extract and parsethe response from the server. These are usually downloadedtrips, list of available trips or notification messages if an ac-tion was successful on the server or not.

GUI layer

On the GUI layer we define the applications activities, themap, overlays on the map, menus and other helper classesto provide the user with the necessary feedback. The centralclass is the Map. It is a MapActivity provided by Androidfor managing Activities which display a MapView.

To be able to draw items on the map we need to extend theOverlay with our custom items such as the Path, current lo-cation indicator, pinpoints for notes and other informationto display. These are captured by the DisplayOverlay andPathOverlay. The LocationOverlay and PinOverlay classesextend the ItemizedOverlay class which is similar to the baseOverlay class but contains a list of OverlayItems. PinOver-layitem is an extension of OverlayItem with added PointIdattribute.There are several other Activity classes which represent fea-tures of the application. CreateTripActivity is used for cre-ating a new trip and giving it a name. CreatePinActivity en-

4


5/7

Class Diagram1

GUI

MODEL SERVICE

MapActivity

-currentState

-locationProvider

-srvc_local

-srvc_remote

Map

DisplayOverlay

-geoPoints

PathOverlay

-location

LocationOverlay PinOverlay

OverlayItemizedOverlay

PinOverlayItem

LocationManager

Activity

UploadActivityTripLoadActivityCreateTripActivity CreatePinActivityPinActivity

+getCurrentState()

+setCurrentState()

+addNote()

+addPoint()

+addTrip()+deleteTrips()

+deletePoint()

+getNotes()

+getPoints()

+getTrips()

ServiceLocalSQL

-name

-remoteId

-description

Trip

-latitude

-longitude

Point

+getTrips()

+downloadTrip()

+uploadTrip()

ServiceRemoteSQL

-PATH

-PIN

PointType

NotePointNote

-state

CurrentState

JSONResponseClientAsynchSender

CallbackWrapper

11 1

0..*

1

Figure 2. Class diagram

5


6/7

ables adding note pinpoints to a trip. PinActivity shows pinsof loaded trips. UploadActivity is used for uploading the tripto the remote database. TripLoadActivity handles download-ing remote trips and loading local ones.

3.5 The Source Code is Open

The applications source code is kept open, therefore any-one is able to contribute to the project or use the code for

non-commercial purposes. The source can be downloadedat http://code.google.com/p/tourtracker/ webpage.

4. EVALUATION

The development time of the TourTracker system took ap-proximately 1 month. In this period we started out by cre-ating prototypes of the user interface on paper and a videoof a typical use case scenario. During the development thesystem was continuously tested by us and the user interfacerefined to meet todays standards. At the end of the devel-opment phase we created a plan for evaluating if the appli-cation fulfills its purpose, whether it is easy enough to useand handles contingency well. We had 4 people testing the

application for specifically 90, 60, 30 and 30 minutes pe-riod. Each test person was asked to record a trip and uploadit. The mobile phones used for testing were: HTC Legend,HTC Desire and HTC Desire HD. Testers were presented tothe features of the application, however not to every detailin order to test how intuitive the application is to use. Af-ter the testing each participant was interviewed individuallywith the following structured set of questions:

a) Did you succeed to record a trip?

b) If yes, did you succeed to upload the trip?

c) Did you experience any problems while using the ap-plication?

d) Was is intuitive to use the application?

e) Tell what features you liked the most in the application

f) Do you have any suggestions how to improve the sys-tem?

Here is a summary of answers we received:

a) 4 out of 4 succeeded to record a tour

b) 2 out of 4 managed to upload the tour

c) 1 out of 4 experienced the application close unexpect-edly

d) 4 out of 4 found the application intuitive to use

e) answers were: nice UI; precise navigation; pause/ resume feature; sharing the trip; easy to use

f) 2 out of 4 had suggestions to improve the system, thesewere: showing the speed, distance, time taken to record atrip; customizing color of path shown

The most important observations about the TourTracker sys-tem are summarized in the following paragraphs:

Practical and easy to use; The participants for testing allagreed that the application is easy to use and practical inmany situations besides creating tours. One participant ap-preciated the pause/resume functionality especially and allof them were satisfied the with the way of up/downloading

tours.

Feature suggestions; Two of the test persons suggested toimplement counting the recording time, distance and currentspeed parameters. We think that these features could be partof the next iteration of the application, however recordingtime and speed does not necessarily have an impact on thetour.

Problems encountered; One of the participants encounteredproblems when trying to record a tour. The icon showinghis location kept dissappearing. We suspect the problem oc-cured because of the poor weather conditions (clouds) and sopoor GPS connectivity. Since this factor is out of our con-trol the solution could be in using different location provider(mentioned earlier) relying on a different technology.

Current limitations; Using Google Maps requires an activeinternet connection to redraw the map to the actual location.Most of out testers did not have an active internet connec-tion so in case they went out of the temporarily cached maparea the map was not shown. The solution to this is furtherdiscussed in the next section.

5. DISCUSSIONS

5.1 Caching map images

At the start of the project we have chosen to use AndroidMapView from Google Maps API for the map as the mainpart of user inteface. During the development cycle we havelearned that the MapView does not provide the ability tocache map images. This is stated in the Android Maps APITerms of Sevice (section 8.2) 4. What this means for ourapplication is that it has to always have internet connectionavailable in order to update the images of the map. The ap-plication will run and use in-memory images if they whereloaded when internet connection was available, but not al-lowing to cache images in persistent storage delivers greatrestrictions. Hence, as we want our application to be usedout in the wild, in the future we would investigate usingOpenStreetMap 5, as it does not have the mentioned limita-tions.

5.2 Proccesing path points

When using the application it is noticeable that the recordedpath is crooked and not as smooth as desirable. This is aresult of location providers imperfection in accuracy andprecision. One approach to help solve this issue would beapplying some algorithm on the point sequence that defines

4http://code.google.com/android/add-ons/google-apis/maps-api-signup.html5http://www.openstreetmap.org/

6
http://code.google.com/p/tourtracker/


7/7

the path. The path trajectory could be aligned and smoothedby using i.e. discrete Fourier transform for complex numbersequence [2] by filtering out high frequencies. In general,processing against the points would not only have an impacton the appearance of the path, but would also optimize thedata, because it would reduce the size of point sequence thatdefines the path.

5.3 Extending location providersThe application could be extended to have more locationproviders rather than using only one. While developing wehave tried out GPS, built-in Wi-Fi positioning system and aphone independent SkyHook 6 positioning system. There isan implementation example in the project using the later oneas location provider.The single GPS provider was chosen due to rapid develop-ment needs, but more providers could be added for support-ing location precision and accuracy or - as alternatives toone another. The system provided Wi-Fi location providercan be used directly in the project. To use SkyHook, oneshould extend the LocationProvider class.

5.4 Integrity and assurance

The application provides the ability to exchange trips databetween client and server. However, the communication inmobile environment is very volatile, therefore applicationshould have more focus on data integrity and assurance. Inorder to ensure that the data is exchanged properly withoutany losses or corruption the md5/sha data hashing could beintroduced in particular data exchange phases. In our casewhen a user uploads a trip, server stores trips and returnsmapped remote trip ids to local ones stored on the phone,so that the phone can update its local database and link lo-cal trips to the remote ones. However, in case the server hasstored data successfully but the response is never returned to

the client, the user might try to upload the data again. There-fore to assure the integrity, the server needs a hash of data tocompare with and positively continue previous communica-tion - respond to the client and return needed data.

6. CONCLUSION

The paper has discussed how the users of mobile phones canuse the TourTracker application to create digital versions oftours and share the records with the public. Further, relatedwork broadly reports on the current situation within the tourguides application area and discribes the similarities and dif-ferences between the TourTracker and already existing sys-tems. Moreover, the paper ilustrates in detail how the ap-

plication is built: what is the concept and architecture of thesystem, how location tracking is performed, the communica-tion with external devices is implemented and how the datais stored on the device. In addition to that, the evaluationpresents the results of interviewing people who tested theapplication. Based on these results we conclude that the ap-plication is benefitial to most of the users and brings a newexperience for creating guided tours, sharing as well as usingdownloaded tours from the remote public storage.

6http://www.skyhookwireless.com/

7. REFERENCES

1. H. L. K. P. Abowd, Atkeson. Cyberguide: a mobilecontext-aware tour guide. Graphics, Visualization andUsability Centre, College of Computing, GeorgiaInstitute of Technology, Atlanta, 1997.

2. E. O. Brigham. The fast Fourier transform and itsapplications. Prentice Hall, 1988.

3. M. Cheverst, Davies. Experiences of developing anddeploying a context-aware tourist guide: The guideproject. Distributed Multimedia Research GroupLancaster University, 2000.

4. B. Echtibi, Zemerly. Murshid: A mobile touristcompanion. Khalifa University of Science, Technologyand Research, 2009.

5. Freytag. Stdtetourismus in heidleberg ergebnisberichtzur gstebefragung 2003. Geographisches Institut derUniversitt Heidelberg, 2003.

6. P. T. Raento, Oulasvirta. Contextphone: A prototypingplatform for context-aware mobile applications.

University of Helsinki and Helsinki Institute forInformation, 2005.

7

Documents

1 Tour Tracker