i’m bored! where is everybody? - martijn pannevis · “there is no such thing as a virtual...

University of Amsterdam

Master ThesisBusiness Information Systems

I’m bored! Where is Everybody?Location Based Systems for Mobile Phones

Martijn [email protected]

August, [email protected]: Dr. Maarten Marx

mailto:[email protected]


A thesis submitted in partial fulfillment of the requirements for thedegree of Master of Science in Business Information Systems

Printed by lulu.comCopyright c© 2007 by Martijn PannevisOnline Resources: http://www.martijnpannevis.nl/lbs/ISBN-13: 978-90-5776-167-6

Cover Image “. . . or another. . . ”copyright c© 2006 by Frederic Poirot[86]Cover background image from Google Maps [36]

iii


Abstract: Context Aware Location Based Systems (LBS), thatchange their workings based on location, have been a promise on thehorizon for many years. While several research projects have devel-oped working systems, they were all geared towards specialized hard-ware, limited areas and focused on their own data sources. This thesisdescribes the implementation of a Context Aware Location and Timebased system on a normal modern mobile phone, with a minimum ofrequirements and without an area restriction. The system can showrelevant information about the current environment the user is in andplaces to go, based on public sources on the Internet. This work de-scribes the trends that lead to LBS, locating techniques, data sourcesand implementation issues with location based systems in general, andmore specifically the Nulaz system.

Preface

“I may not have gone where I intended to go,but I think I have ended up where I needed to be.”

– Douglas Adams

With five topics (2D barcodes, home servers, subsidy models, smartpower meters and LBS) crossing my path, finishing my final

thesis hasn’t always been a smooth ride.Much has passed, considered, and put aside. I have read through

dozens and dozens of articles on several subjects, in week-long sessionsin the library, Routerseiland, KPN, my own home, and our cabin inEgmond. In the end I did found a great subject that really grasped me,and could dig into. I have both loved and hated LATEX, the typsettingsoftware I used. I have made new friends, started new hobbies, andbeen involved in three startups, taking too much of my time. But I havelearned and grown of the experience, and met some really interestingpeople along the way.

Many thanks to the nice and intelligent people who have made thisthesis possible. It has been a great pleasure to learn from you. First andforemost I would like to thank my supervisor, Maarten Marx, whoseenthusiasm kept me working, and made me realize that science can beboth fun and interesting. I would also like to thank the people at KPN,where I had a great time and learning experience. My parents, whohave always supported me, both emotionally and financially :). Wendyand Andrea and the students in my thesis study group, for their tipsand support, and my brother Niels for proofreading.

Last but certainly not least, I have always enjoyed the support ofmy closest friends. They were always there to have a coffee (or a beer),and a good talk about study or other, even more important things inlife. It has certainly been a great experience!

Martijn Pannevis,August 2007.

Contents

Preface v

1 Introduction 51.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Location Based Systems . . . . . . . . . . . . . . . . . . 61.3 Previous research . . . . . . . . . . . . . . . . . . . . . . 61.4 Research goal . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1 Outline . . . . . . . . . . . . . . . . . . . . . . . 8

2 Trends 92.1 The Web as a Platform . . . . . . . . . . . . . . . . . . 92.2 Maps and Mashups . . . . . . . . . . . . . . . . . . . . . 112.3 Cell Phones . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Locating Techniques . . . . . . . . . . . . . . . . . . . . 132.5 Social Trends . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Predicting the Future . . . . . . . . . . . . . . . . . . . 15

3 Nulaz 173.1 System overview . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Local Pictures . . . . . . . . . . . . . . . . . . . 193.1.2 Google Maps . . . . . . . . . . . . . . . . . . . . 193.1.3 Wikipedia . . . . . . . . . . . . . . . . . . . . . . 193.1.4 Restaurants . . . . . . . . . . . . . . . . . . . . . 203.1.5 Parking . . . . . . . . . . . . . . . . . . . . . . . 203.1.6 Movies . . . . . . . . . . . . . . . . . . . . . . . . 203.1.7 Cultural events . . . . . . . . . . . . . . . . . . . 203.1.8 Friends . . . . . . . . . . . . . . . . . . . . . . . 223.1.9 Tracks . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . 223.3 Specifications . . . . . . . . . . . . . . . . . . . . . . . . 24

1

2 CONTENTS

3.4 Conceptual Framework . . . . . . . . . . . . . . . . . . . 253.5 System Architecture . . . . . . . . . . . . . . . . . . . . 26

3.5.1 HTTP communication . . . . . . . . . . . . . . . 273.6 The name “Nulaz” . . . . . . . . . . . . . . . . . . . . . 293.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Mobile and Context Aware computing 314.1 Context Aware Computing . . . . . . . . . . . . . . . . 314.2 Mobile devices . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Limited Input & Output . . . . . . . . . . . . . . 334.3 Displaying Location . . . . . . . . . . . . . . . . . . . . 344.4 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . 354.5 The Internet is Non-geographic . . . . . . . . . . . . . . 364.6 Context in Nulaz . . . . . . . . . . . . . . . . . . . . . . 36

5 Locating the User 375.1 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Locating Requirements and Technologies . . . . . . . . . 385.3 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Cellular Network based location . . . . . . . . . . . . . . 41

5.4.1 Network based . . . . . . . . . . . . . . . . . . . 425.4.2 Handset based . . . . . . . . . . . . . . . . . . . 42

5.5 WiFi based . . . . . . . . . . . . . . . . . . . . . . . . . 445.6 Tag based . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6.1 RFID . . . . . . . . . . . . . . . . . . . . . . . . 455.6.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . 465.6.3 2D barcodes . . . . . . . . . . . . . . . . . . . . . 46

5.7 Manual Entry . . . . . . . . . . . . . . . . . . . . . . . . 485.8 Sampling Frequency . . . . . . . . . . . . . . . . . . . . 495.9 Locating in Nulaz . . . . . . . . . . . . . . . . . . . . . . 49

6 Location Based Data 516.1 Web service API’s . . . . . . . . . . . . . . . . . . . . . 516.2 Data mining . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3.1 KML . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.2 GeoRSS . . . . . . . . . . . . . . . . . . . . . . . 54

6.4 Points and Places . . . . . . . . . . . . . . . . . . . . . . 546.5 Geocoding . . . . . . . . . . . . . . . . . . . . . . . . . . 556.6 Matching . . . . . . . . . . . . . . . . . . . . . . . . . . 556.7 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

CONTENTS 3

6.8 Nulaz Data . . . . . . . . . . . . . . . . . . . . . . . . . 576.8.1 Flickr: API . . . . . . . . . . . . . . . . . . . . . 576.8.2 Google Maps: Own converter . . . . . . . . . . . 576.8.3 Wikipedia: SQL import . . . . . . . . . . . . . . 606.8.4 Restaurants: Ripping . . . . . . . . . . . . . . . 606.8.5 Parking data: Live parsing . . . . . . . . . . . . 606.8.6 Movies: RSS feed . . . . . . . . . . . . . . . . . . 616.8.7 Cultural events: XML files . . . . . . . . . . . . 616.8.8 Own data: SQL database . . . . . . . . . . . . . 62

6.9 Data Conclusion . . . . . . . . . . . . . . . . . . . . . . 62

7 Conclusion and future work 657.1 The Next Nulaz . . . . . . . . . . . . . . . . . . . . . . . 657.2 Further Research . . . . . . . . . . . . . . . . . . . . . . 66

Terms 69

References 71

4 CONTENTS

Chapter 1

Introduction

“There is no such thing as a virtual beer.”– Robert Cailliau

1.1 Motivation

I’m in the city, alone, and I’m bored. I want to know where my friendsare, and where we can go to have fun. Most planning tools expect

you to plan ahead. Former generations did this more often. Before mo-bile communications and the Internet became so widespread, you hadto plan ahead and make appointments, as there were few possibilitiesto plan events on the spot because of lacking communications. Manytools support this type of planning: If you want to go to a movie intwo days, it’s not that hard to find out what’s playing where.

The current reality however is that young people want to be en-tertained HERE and NOW. They don’t plan their lives. Instead theywant to know their current options for meeting people and going out.For many years, future Location Based Systems (LBS) have promisedto solve this problem in some distant future. While several workingsystems have been build in research centers, there are almost no real-world working systems “out in the wild”. It has even been noticed thatbuilding working LBS is no easier now than it was a decade ago [18].The timescale for these systems has always been sliding, and it hasalways been a promise on the horizon. Technologies have advancedenough to build a working prototype of such a system, which can beused by users in the field and is accessible on standard mobile phones.

5

6 Chapter 1. Introduction

1.2 Location Based Systems

“Location aware services or systems are defined as context-aware services that utilise the location of the user to adaptthe service accordingly [58].”

Location aware or location based systems are a subset of context awarecomputing systems [58]. Such systems use different forms of contextin their applications, to aid their users. While systems for fixed pc’scan also use context and even location, for example to select the closestprinter, for handheld systems with more mobility and limited outputusing context is a key technology [84, 23].

1.3 Previous research

There has been previous research in context aware and location basedsystems. Examples are: Cyberguide [2], Guide [19], and Gulliver’s Ge-nie [80], which all developed a working location aware guide. Place labdid much research in location based systems [64], but mainly focusedon localizing techniques [18, 61, 64]. Their systems however have sev-eral disadvantages for a general usage: They all limit their scope to asmall area. Some only include several buildings, or a city, but nonework country- or worldwide. Other systems for indoor locating func-tion in an even smaller area: Only one building or a couple of rooms(for example The Bat [47] and the Active Badge system [116], generallyseen as the first location based system). Another disadvantage of thesesystems is that they all use specific hardware platforms. Often spe-cially build devices, or particular combinations of hardware. All use aclosed system for their data: They mainly used their own data sourcesas input.

ContextPhone [90], which targets smartphones, came closest to ourtarget of building something for the general audience. Unfortunately,their system, while phone based, only works on smartphones with spe-cific software (Symbian Series 60), and is focused on its own datasources.

1.4. Research goal 7

1.4 Research goal

This thesis will proof that, with the advances in computing power,software, web standards, and connectivity options in mobile phones,limits such as mentioned above aren’t necessary anymore. It will showthat it is possible to build a system that works on most modern phones,not limited to a small number of devices or a restricted area. It willuse public available datasources from the Internet, and not be limitedto a small amount of internal information.

The main research goal is thus “How can we build a working locationand time based mobile system for the general audience?” In answeringthe research goal we have several questions:

• What trends are there that will lead to a rise in LBS?• What other research has been done in mobile and context aware

computing?• How do we evaluate mobile location based systems?• How can such a location based system work, and which compo-

nents are needed?• Which technologies can we use to locate a user?• Which data sources are available, and how can they be used in

LBS?

1.5 Overview

For this thesis a system has been build to realize the functionalitydescribed above. An integrated system that can show interesting factsabout your current location, your surroundings, and the people closestto you. A tool that shows what’s important, Here and Now. As thissystem has to be location based, it makes most sense to be a portablesystem. Since its target is the general audience, the most ubiquitousplatform in the western world is used: The mobile phone. As mobilephones have several interface issues, as shown in Section 4.2, a web-based interface has also been developed. This can be used on desktopPC’s, and certain data can also be viewed in Google Earth, a virtualglobe application.

This system will combine data from different sources. These in-clude: The user’s current location, the time of day, and data sourceson things in the vicinity of the user, such as events, historic informa-tion, and so on. This work describes the trends that lead to LBS, thetechniques necessary for building them, and the problems encounteredwhen working with location based data.

8 Chapter 1. Introduction

A system like this can be used for end-user queries like:

• Where are my friends?• What movies are playing near my current location?• What is a good place to have dinner around here?• What sights are there to see near me?• What is the history of this building?• What experiences have other people had at this location?

Our system is called Nulaz.

1.5.1 Outline

After this introduction, Chapter 2, will give a short introduction ofthe different Trends which will lead to the rise of LBS. In Chapter 3,Nulaz, the outline of the system will be described. The next chapter,4, will describe issues with Mobile and Context Aware comput-ing. In Chapter 5, Locating the User, the (dis)advantages of severaltechniques of locating people are described. Location Based Data,Chapter 6, will describe the problems with matching the location toother data sources. The thesis will end with Conclusion and futurework in Chapter 7, where the results and future of the Nulaz systemwill be discussed.

Extra resources for this thesis, such as a downloadable list of ref-erences, and parts of the source code can be found at http://www.martijnpannevis.nl/lbs/.

http://www.martijnpannevis.nl/lbs/

http://www.martijnpannevis.nl/lbs/

Chapter 2

Trends

“Where a calculator on the ENIAC is equipped with 18,000 vacuumtubes and weighs 30 tons, computers in the future may have only

1,000 vacuum tubes and weigh only 1.5 tons.”– Popular Mechanics, March 1949

There are several developments that will lead to a rise in locationbased services in the following years. These are technological,

such as the growth of webservices (section 2.1) and mapping solutions(section 2.2), and the combination of both. The increasing distributionof cellphones and their computing power (section 2.3) and the rise oflocating techniques (section 2.4) also has a big influence. Social trends,such as the growth of social networks (section 2.5) will help furtheracceptance. Generally there is a link between technological and socialtrends, as new technology enables new social behavior [41].

2.1 The Web as a Platform

For the first years of it existence, the web added value by linking fromone page to the other. Users could be send to other places, to findmore information on a subject. The last few years we have seen an-other trend: sites exchange data and aggregate it for their users. Newstandards have evolved for exchanging data between sites. RSS, whichstands for Really Simple Syndication [11], is the most popular. It isan XML based format that in a structured way describes updates towebsites and the data that has changed. Originally it was invented byowners of weblogs, to distribute their updates. Today it is used formany sites that have regular updates, such as news sites, podcasts andcomment feeds. This enabled websites to exchange data, and combinedata from different sources into Mashups [54]. When the data exchange

9

10 Chapter 2. Trends

Figure 2.1: Top 10 Web API’s[89]

is more complex than the listing of latest posts, an RSS feed does notsuffice.

To solve this, some sites offer an API, and Application ProgrammingInterface. An API is an interface with a set of standards defined by it’sdesigner, to communicate between pieces of software. This enables amore complex interaction between pieces of software. Where RSS justshows all the results, an API can have constructs for searching, limiting,and formatting the data. An example of such a complete API is theFlickr API [27]. Some API’s use RSS as one of their output formats.Some sites also offer their own widgets: A small piece of software thatcan be installed on other websites, to show information from one siteon another.

Another trend is the rise of user generated content. The first web-sites were mainly one way. They had an author (or group of authors),and the public could read the site. If they wanted to respond, an emailto the maintainer was usually the only possibility. Today much contenton websites is written by the users of the sites itself: They have theopportunity to comment on stories, and submit suggestions for newones. Other sites enable their users to vote on subjects. And somesites are completely written by the users: The administrators just offerthe framework. The largest of these is the well known encyclopediaWikipedia [6] which has almost 8 million articles written by its users.

The trends mentioned above are often combined. Many modernsites include content from other sites, and distribute their own user-generated content in the form of comment feeds, widgets that can beincluded in other sites, and so on. Another trend is the rise of webbased mapping solutions, as discussed in the next section.

2.2. Maps and Mashups 11

2.2 Maps and Mashups

When Google launched Google Maps in the beginning of 2005 [35],as one of the first AJAX map applications [103], it was received as farsuperior to then existing browser-based online mapping services. Thesewere far more server based, and thus had longer response times. Manyusers started hacking the interface to integrate these maps into theirown websites to show geographical information. Google responded byopening up their maps interface to the public [36], making it mucheasier for developers to integrate these mapping tools into their ownwebsites. This lead to a much greater demand, and many websitesstarted incorporating these maps. Two other big Internet companies,Yahoo and Microsoft, since then also released similar map API’s.

This rise in online mapping led to thousands of mashups which in-cluded geographical data, ranging from mapping crime [51] and unsafecities [87] to the nearest place to get beer [72] and the live tracking oftrains [63].

Besides it’s web-based maps, Google bought Keyhole [37], the ownerof a virtual globe application, and gave away the standard edition oftheir software for free. This has been a major push forward for the GIS(Geographic Information System) industry [16]. Its launch enabledmany new applications since the Keyhole software, relabeled as GoogleEarth, can also be used as interface for many geographical datasets [16].Within two years, Google Earth has seen more than 200 million down-loads [38]. And many websites include ways to link items to a place,such as Flickr that enables users to geotag their pictures [112].

Google was also the first to release a free geocoder[36], to translateaddresses to geographical coordinates. Yahoo followed by also openingup their mapping API [123] and geocoding tools. Today Google mapsis the most used tool in combinations of websites, so-called mashups,featuring in half of them as seen in Figure 2.1 on page 10. Thereare currently over 30.000 websites that, in some form, incorporate theGoogle maps [103, 89].

With the rising exchange of data between websites, a new categoryof sites arose: The mashup. As Goodman and Moed say:

“A mashup is an information system that combines two ormore separate data streams to create original content [34].”


2.3 Cell Phones

Cellphones, when introduced, only catered to a small market: onlybusinesspeople could afford the expensive and bulky devices to keepin touch. But with the miniaturisation of electronics, phones becamesmaller and cheaper. And, following Moore’s law which predicts thatcomputer power doubles every two years [74], todays phones are morepowerful computers than the desktop PC’s of the early 1990’s [55]. Mo-bile phones became one of the largest technological succes stories of the20th century. They are cheap, reliable, and form the most ubiquitouscomputing platform [80, 90]. Today, most people in the western worldcarry a cell phone, and in some western countries cell phone penetra-tion per user is even above 100%, which means there are more phonesthan users [3, 21].

Figure 2.2: Phones per capita in the western world [21].

While voice transport is still the main application of these devices,most modern handsets have more functionalities: they can act as mu-sic player, take pictures or even video, be used as a calendar, and soon. Phones also include data services, and most people use these in the

2.4. Locating Techniques 13

form of SMS (Short Message Service) [21]. While SMS is limited to textmessages of 160 characters (encoded in 140 bytes [113]), it has becomeextremely popular for chatting and non-intrusive communication. Itforms a very large market, and there are more SMS users than Inter-net users worldwide [3]. There are many SMS informational services,such as the weather, stock information, and ringtones. But they areoften expensive with data rates up to several hundreds of euros perMB1. Together they provide 70 billion in annual revenue to networkproviders [3].

Almost all modern phones can also be used as an Internet terminal,connecting with the Internet through the network of the provider. Forthis they include a (limited) web browser. While the western world hasnot yet seen a large uptake of mobile webservices, in some countriessuch as China and Japan, mobile browsing is more common than usingthe web on desktop PC’s [3], and it is expected that western countrieswill follow this trend. New phones offer more Internet functions [79].Most cellphones can also run small programs, called Midlets (See alsoSection 4.4 on page 34). But because of their constrains, there hasn’tbeen much research in using phones for these applications.

2.4 Locating Techniques

The last couple of years many new localizing techniques have been de-veloped. Where, only two decades ago, it was nearly impossible todetermine an exact location without specialized earth-surveying equip-ment, today GPS devices that can show your exact location cost undera hundred euros. As the prices and size of GPS chips go down, theyare integrated in more devices. There are some digital camera’s thatinclude a GPS, and the first phones with GPS are coming to the mar-ket [79, 50]. Also without a GPS, many users geotags their pictures, byplacing them on maps [112]. Many expect that locating will be a stan-dard feature in future phones [14, 55], as GPS chipset prizes go down,soon expecting to reach a $2 price point [48]. And there are othertechniques being developed to localize a user, mostly based on variouswireless signals. See chapter 5 for an overview. These technologiesenable the rise of Location Based Services.

1A regular SMS message costs between 1 and 25 cents, and can contain 160 lettersin 140 bytes, with 7 bits encoding [113] (1 MB/160Bytes)*15 ct/message=e937,5).Premium SMS can cost even more, up to several euro per message.


2.5 Social Trends

Figure 2.3: Number of Hyves users over time.

Together with technical trends, we have seen social trends happen-ing on the Internet. Where network based chat has been nothing new,and even existed before the World Wide Web was invented [93], therising Internet penetration has been an enabler for new social appli-cations [33]. In some age groups, specifically young people, instantmessaging has become one of the dominant ways of communicating:85% of college students consider the internet to be an easy way ofcommunicating with friends [56]. SMS is used by many teenager tocoordinate activities [40].

Sending short messages has also been a big hit away from the Inter-net: SMS has been one of the (unexpected) big hits in the last coupleof years [95, 3]. For many users, their handhelds primarily have a so-cial function [109], making them ideal platfoms for mobile social media.These new social structures have also been formalized in a new trend:social networking sites. These started in the United States, as a novelway to keep in touch with friends, and show information about currentactivities, pictures and networks of friends. Currently, some of themhave millions of users, covering large parts of certain demographics.See for example the growth of Hyves, a Dutch social networking site inFigure 2.3. It has grown from zero to 2 million users in a little over ayear2.

2The Internet Archive keeps 323 old daily front-pages of Hyves[7], where theypublish their current number of users. By downloading and parsing this data, thegraph here was constructed.

2.6. Predicting the Future 15

These new tools lead to a generation that is always in touch witheach other. Whether through traditional calling, instant messaging,SMS, email, weblogs, social networking sites or VoIP( Internet tele-phony) solutions, young people are more connected with each otherthan previous generations have ever been. Some of the new tools showa way of revealing little location information, but this is currently lim-ited to descriptions such as “at home” or “studying at the library”. Inthe near future, more of these tools will include automatic mechanismsto detect and reveal, location to friends. Location can also be used todetermine status of a user: When the system detects that a user is athis workplace, a “do not disturb” sign could be shown to his friends.Research in privacy issues on locating people shows that participantsare willing to reveal their location to their friends, family and to a lesserextent co-workers [60].

2.6 Predicting the Future

The trends described in this chapter lead to the opportunity for Lo-cation Based Systems: One one hand, the technological trends enabletheir existence. The social trends, on the other hand, show a grow-ing acceptance of these technologies, and one can expect that LocationBased Systems will have a fast acceptance in younger age groups. Butas there are not many working location based systems in the wild, wedecided to follow the advice of Alan Kay:

“The best way to predict the future is to invent it”

As mobile phones are the most common technology item[3] in oursociety, and include technologies that can be used to determine theirposition, they are the most ubiquitous computing platform, and anexcellent candidate for LBS [14]. The next chapter will show that it ispossible to build a working Location Based System for mobile phones.

Chapter 3

Nulaz

“The first 90% of the code accounts for the first 90% of thedevelopment time. The remaining 10% of the code accounts for the

other 90% of the development time.”– Tom Cargill

This section will describe our system, which is called Nulaz. It willdescribe the interface and user view in Section 3.1. Section 3.2

will describe the design goals which result in it’s specifications in Sec-tion 3.3. The systems’s conceptual framework is explained in Sec-tion 3.4, and it’s architecture in 3.5.

Nulaz can be used to show local relevant information. It works witha small (J2ME) program on a mobile phone, that connects to a GPSdevice. It receives it’s current location’s coordinates from the GPS, andtransmits them (over GPRS or other data carriers and the Internet)together with a user ID to a central webserver, that stores them in adatabase. This process is repeated every few seconds. The data flowcan be seen in Figure 3.1 on page 18.

The software can also open a browser on the phone, in order todisplay relevant local information. The same webserver is then calledwith the ID and location of the user, and a mobile interface is shown.This mobile interface combines several datasources to show informationabout the area the user is in. Screenshots of this interface can be seenin Figure 3.2 on page 21. The webserver also has a webinterface fornormal browsers, to enable interfacing with the system from a PC,and certain data can also be viewed in Google Earth, a virtual globeapplication.

17

18 Chapter 3. Nulaz

Figure 3.1: Overview of the Nulaz system

3.1 System overview

This section will show the user features of Nulaz. In Section 6.8 on page57 the technical implementation of these features will be explained.

The user runs a small program on his phone. This program retrievesit’s current location, and transmits this to the webserver to store them,for the generating of tracks. The user can also start a mobile browserto show information relevant to his current location. This shows:

• Local pictures• A map or aerial picture of the surroundings• Highlights from Wikipedia• Restaurants in the surroundings• Parking places in the area• Movie theaters and their upcoming movies• Cultural events• Friends in the area

Each of these will be explained in the following sections. All sources inNulaz are sorted on distance from the current location of the user, toshow only the most relevant items for that place. This user interfacetechnique is called proximate selection [101]. While most of the featureswork world-wide, the parking, restaurants and movie/cultural listingshave been limited to Amsterdam, as it was beyond the scope of thisthesis to find good and accurate worldwide sources for these.

3.1. System overview 19

3.1.1 Local Pictures

The local pictures screen shows pictures that other people have taken inthe surrounding area of the current location of the user. While browsingpictures of other people in general can be interesting, knowing that thepictures have been taken in the current vicinity of the user ads an extradimension to them. It gives an impression of the experiences otherpeople had in that area, together with the place they were taken, asseen on Figure 3.2(e). While the pictures are currently quite dispersedover the area, this is expected to improve with the growth of geocodedpictures.

3.1.2 Google Maps

Many cities have maps that show where you are, for tourists and otherpeople who don’t know the area. This shows the need for maps withinformation. A simple map of the area the user is in can be one of themost useful features of any location based system. The Nulaz maps,while quite a hassle to develop (see Section 6.8.2 on page 57), cangive a good overview of the current location, and can be useful infinding places. Examples are shown in Figure 3.2(a) and 3.2(b) onpage 21, which show the same location. The satellite or areal pictureis mainly for fun, and has a high “James Bond” factor. But it can beuseful, as some areas such as parks are less planned out in the maps,but can be recognized in the photos. The maps can also be used inconjunction with other features, to show where items (such as movietheaters, restaurants, etc) are located.

3.1.3 Wikipedia

Wikipedia [6] contains much information about places. But findinginformation about a place can be a hassle for three reasons. To searchin the general Wikipedia site, one has to know what to search for. Ifyou are standing in front of a big church or other landmark, you canprobably find it in Wikipedia, if you know it’s name. But this namecan be hard to find. And even when you know the name, entering it ona mobile keybord can be quite a hassle. The third problem is that thisway of searching doesn’t show that nice museum just around the cornerif you don’t search for it’s name. The local Wikipedia pages in Nulazsolve this, by showing Wikipedia links based on your current location,as shown in Figure 3.2(c) on page 21. This eliminates the need to knownames of items, or the need to enter them. Since they are sorted ondistance, it will also show items that are in the area but you didn’t know

20 Chapter 3. Nulaz

about. It shows a small picture of the item (if available), together withthe links to the Wikipedia pages, and their distance and direction fromthe current location. The links link to a mobile version of Wikipedia,provided by Wapedia.mobi.

3.1.4 Restaurants

When you want to get something to eat, it’s nice to have an overviewof the restaurants in the area. Nulaz can show this, together with arating of the restaurant. An example is shown on Figure 3.2(h).

3.1.5 Parking

Finding a place to park can be difficult in Amsterdam and other cities.There are several big parking garages, but they are often full. Togive more information on their states, the municipality of Amsterdamhas made data about it’s parking garages and the chance of gettinga free place available on the Internet. But this website is build fornormal PC’s, which means it’s difficult to access when on the road:you usually are not behind PC when your looking for a parking spot.To solve this, parking data is included in Nulaz, sorted on distancefrom the current location of the user. As the city provides clear mapswith the locations of the garages, these are also included. See Figure3.2(f) for a screenshot of this listing.

3.1.6 Movies

Going to the movies can be a fun activity. But movie calenders give ageneral overview, and show many movies that have shown in the past,start in a few days, or are far away. In Nulaz an overview of movietheaters is included, based on the current location of the user and timeof day. It shows the closest movie theaters, their location, and the firstmovies they will be playing, as can be seen in Figure 3.2(g).

3.1.7 Cultural events

The Dutch Uitbureau keeps a database of cultural events in Amster-dam. It shows things like theater shows, open galleries, and otherevents. Nulaz includes this database, and shows an abstract of the in-formation for each event, ordered by distance from the current location.An example is shown in Figure 3.2(d) on page 21.

3.1. System overview 21

(a) Mobile Map (b) Satellite view (c) Wikipedia items (d) Cultural events

(e) Flickr Pictures (f) Parking places (g) Movies (h) Restaurants

Figure 3.2: Screenshots of the mobile webinterface

22 Chapter 3. Nulaz

3.1.8 Friends

One of the main purposes when building Nulaz was to build a systemthat shows where your friends are. In the mobile interface, it showsthe up-to-date distance and direction to your friends. But because thesystem currently doesn’t have that many users, these social featuresaren’t that useful yet. For a next version expansion in this direction isplanned.

3.1.9 Tracks

The only function that is not included in the mobile interface, butsolely is in the webinterface, are tracks. Tracks show the paths of thetrips the user has made. The reasons they are not included in themobile interface are that they are the only component of Nulaz thatdoesn’t show local information: They are a nice extra build out ofdata that is being collected by the system, rather than local relevantinformation. Also they contain a lot of data, which is hard to show ona mobile interface, and heavily rely on the Google maps and GoogleEarth interfaces for the displaying of their data. While for Nulaz partof the maps API was ported to a mobile interface, showing tracks isnot yet possible. Screenshots of the webbased and Google Earth trackinterfaces can be seen at Figure 6.4 on page 63.

3.2 Design Principles

While building the system, there were several design principles:

• Work on as many phones as possible, which lead to J2ME, GPS& Bluetooth.

• Easy installation by users• Be Internet based• Feasible within my resources (time and budget wise)

To start with the last requirement: Every project has a deadline and abudget. Since the development process was a one-men show, the timeand budget constrains were considerable. This meant that not every-where the theoretical optimal choice could be made. Where cornershave been cut, the choices made will be explained.

As the purpose of this thesis is to proof Location Based Systemsare feasible with currently available technologies, Nulaz had to be ableto run on as many phones possible. It had to not only support spe-cific handsets, with high-end requirements such as a GPS, but most

3.3. Specifications 23

phones currently on the market. On the other hand does a locationbased system imply the need for a locating technique, and in our caseconnectivity to work with live and changing sources, and a platformto build on. Nulaz uses GPS as its main locating technique. The de-sign choices for this are explained in Section 5.9 on page 49. As thereare very few phones with an integrated GPS, it had to link an exter-nal GPS to a phone. While there are specific GPS models for certainphones, most modern handsets can be linked to a external GPS devicevia Bluetooth. This is a relatively non-expensive solution (e70), thatcan offer locating services to most users.

A system that can be used by many users in the field is still notthat usefull if the instalation is a big hassle. Therefore Nulaz can bedistributed by SMS. Users can receive a download link on their phone,which they can click to install the program. For this, and the use ofthe program, they need an working Internet connection on their phone.Most providers offer unlimited Internet access for e10/month, or a pay-per-use package of a few euro per megabyte tranferred. The data usagedepends on the frequency of the updates (which can be chosen in thesettings), and how much information is requested by the user. An hourof typical usage, with a location update each 30 seconds, will result inabout 50 KiloBytes of transferred data, which will cost about 10 centswith a pay-per-usage tarrif of e2 per megabyte.

Since Nulaz had to be a live, always up-to-date system, it has towork with a central server, and a way for the handsets to connect to this.While there are other options for this (GSM datacalls, for example),an Internet based system made most sense, both from a technical anda development effort standpoint.

The goal to develop for a large audience greatly limited the platformoptions, as the system had to support not only so-called smart-phones,but ordinary ’non-smart’ phones as well. See Section 4.4 on page 34for more on the different platforms. This led to the most supporteddevelopment platform: J2ME.

As I had much experience with building webbased systems, I decidedto build the server-side with PHP and MySQL. A system like Nulazcould also be build in other webprogramming languages, such as ActiveServer Pages, JavaServer Pages or Python. And other databases can beused as storage backend, such as Microsoft SQL Server, PostgreSQL,SQLite or another database server.

24 Chapter 3. Nulaz

Figure 3.3: Bluetooth GPS device

3.3 Specifications

The design principles led to the following minimal specifications forthe current implementation, which works with a Bluetooth GPS suchas shown in Figure 3.3 on page 24. The phone running the softwarehas to support:

• J2ME• Bluetooth (and the Bluetooth [88] API in J2ME)• Internet connectivity (GSM/GPRS/EDGE/UMTS/WiFi/etc)• Mobile webbrowser with XHTML support.

Special care was taken to support the lowest end mobile web-browsers. For example, the mobile interface was build without the useof Cookies or Javascript, since not all mobile browsers support these.These specs can be met by all but the very lowest-end phones on themarket today.

The extra PC webinterface uses cookies for session management,and javascript for the maps interface, but these are common in all mod-ern desktop browsers. The Google Earth views require Google Earth, orother compatible software that can display KML. Nasa’s virtual globeapplication, worldwind, is working on a KML importer [107].

3.4. Conceptual Framework 25

3.4 Conceptual Framework

Nulaz uses the conceptual framework of Baldauf [9]. This frameworkconsists of five layers, in which data starts at the lowest layer, and flowsto the higher layers. In Nulaz this model is distributed between thephone and the server. The data starts at the phone and is preprocessedthere before being send to the server. The server builds a resultset,based on the data the phone send. The result is send back to thephone, to be displayed. This application is shown in Figure 3.4 onpage 25.

Figure 3.4: Conceptual layered framework and its application in Nulaz.

Many parts of the system use a similar approach on a smaller scale.The GPS device, for example, has the same layers. It uses sensors (it’sradio), retrieves it’s raw data, does quite a bit of (pre)processing (bothfiltering and calculating) to generate the coordinates, and has a storageand management layer where it offers the results as NMEA 0183 1 data

1NMEA 0183 is serial ascii format for broadcasting GPS and other data, orig-inally designed for usage by navigational systems on boats. Today it’s the mostused output format by GPS devices.

26 Chapter 3. Nulaz

to it’s (serial Bluetooth) interface.

3.5 System Architecture

Figure 3.5: Overview of the Nulaz architecture, with it parts.

Nulaz consists of several parts, that communicate with each other,as shown in Figure 3.5. It is split between a relative thin client, anda server. The client retrieves and passes it’s location to the server.When the user wants to see local information, the client requests thisinformation from the server. The server determines the relevant infor-mation for the location of the user, and sends it back to the client, thatdisplays it to the user.

Splitting the system between a relatively thin client, and a serverto do part of the processing and filtering, has certain advantages. The

3.5. System Architecture 27

client only needs to display the processed results, and doesn’t need todo the extensive filtering and searching in the large databases. Thisenables the system to run on devices with less storage and processingpower than would otherwise be needed, as the server does most ofthe ’heavy lifting’ [49]. It also enables the use as a live system, withupdated resources that can show current up-to-date information.

The current Nulaz client is based on GPSTrack[85], an open sourceJ2ME GPS tracking program. The original software could connectto a Bluetooth GPS, retrieve coordinates, and later, after the trackwas finished, save the track to a file, or email it. To this program livetracking has been added: Each interval (dependent on time elapsed anddistance traveled), the program sends its current location’s coordinates,speed, heading, and the ID of the user2 to the Nulaz webserver, using aHTTP GET request. The server saves these in a database. This enablesthe forming of tracks, on the server. With each start of the programstatistics about the user, such as his phone platform and GPS type, aresend to the server. The program also has an option to open a mobilebrowser on the phone of the user. This starts a mobile webinterfacewhich it passes the mobile user-id and coordinates, if available. Thismobile interface, shown in Figure 3.2, shows local information to theuser. If no coordinates are sent in the request, it first asks for thecurrent location of the user. It then shows options for the current area.The decision to work with a mobile webbrowser was made to ease thedevelopment process for this version. For a next version an integratedclient is planned, that shows all data within the program itself.

3.5.1 HTTP communication

All communication between handsets and servers, and all 3 interfaces,use the HTTP protocol [43]. For the web interface this makes sense,since it’s the protocol of all websites. And for Google Earth, it’s theonly protocol supported by the program. For the mobile client all op-tions were open, and HTTP was chosen. This has several advantages:HTTP is the only protocol that has to be supported by J2ME phonesand is best supported by GSM networks [82, 42]. Other protocols arepossible in MIDP2, but are optional, and aren’t necessary supported bythe phone manufacturers or providers (and some providers block non-

2For the mobile version, username/password pairs were not a good option, asthese are a hassle to enter, and take to much data to transfer with every request.There is a need to protect the sensitive data of the user from identity theft. Tosolve this Nulaz uses a special mobile login: a combination of userID and a shorthash, unique for each user.

28 Chapter 3. Nulaz

HTTP request). HTTP thus has the highest chance of getting through.Also a standard implementation is available in J2ME, leading to lessimplementation issues. And because HTTP is used for websites, a ordi-nary webserver can be used for serving the data, omitting the need forthe development of a onw special server, thus easing the developmentprocess.

Of course, the medal is two sided, and HTTP for server communi-cations also has it’s disadvantages: The overhead of HTTP requests isquite large for the small pieces of data we are transmitting with each lo-cation update. While special care was taken to make the request URLsas short as possible, the HTTP headers cause a lot of overhead. ANulaz HTTP request, as seen in Figure 3.6, typically consists of about210 bytes, and a response code with 450 bytes of headers, of which onlyabout 25 bytes are actual payload.

GET /p/?a=2440343&o=229010&u=1-41a&s=12.3&h=123 GET /m/HTTP/1.1Host: nulaz.nlUser-Agent: SonyEricssonW810i/R4CE Java/SEMC-Java/2.0Profile/MIDP-2.0 Configuration/CLDC-1.1 UNTRUSTED/1.0Connection: Close

Figure 3.6: Example of a Nulaz HTTP Request.

Another disadvantage of HTTP is that it’s stateless: each changewill need a new connection build up, and certain credentials need to besend with every update to identify the user. This leads to quite a largeoverhead for the many small update packets Nulaz sends.

A third disadvantage is that only the client can make requests forinformation. This means the client must request new data regularly, ifit wants to show updated information. There is no way to push newdata from the server to the client without a request.

The argument of development time and support by phones andnetworks outweighted these disadvantages, and so the communicationswith the mobile clients is also done over HTTP. For a next version, acustomization of the HTTP headers is planned, to make the transferssmaller. Eventually Nulaz will support socket communications insteadof HTTP connections, but this will also imply the need to developan own server. And as not all networks and phones support socketcommunications, it will most likely always need HTTP as a fall-backmethod.

3.6. The name “Nulaz” 29

3.6 The name “Nulaz”

The name Nulaz means nothing. It is no abbreviation of some kind.When building this system, I wanted it to have a Web 2.0’ish name, anda large number of modern sites have names that make no sense. Alsoit had to be short (as people had to enter it on their phone), and the.com and .nl needed to be available. This severely limited the options,as almost all 4 letter .com’s, and most 5 letter names, are alreadytaken. From a list of still available 5 letter .com names [24], Nulaz waschosen, as I liked the sound of it and thought it to be appealing to thetarget audience. The .nl was also registered, as well as the commonmisspelling with an S instead of a Z. The difference between NulaZand NulaS can be hard to hear.

3.7 Conclusion

This chapter has shown the inner and outer functioning of the Nulazsystem. The current version of Nulaz implements most of the designgoals, while working on a large number of phones. It shows that aworking system can be build, and shows lots of relevant contextualinformation. But there still is a large to do list. A nice start would bea better mobile client, which includes more functionality in the clientitself, instead of using a mobile browser. Using a browser has mainlybeen done to shorten the development time. Also the social featuresof Nulaz are underdeveloped, as not much testing with large usegroupshas been done yet. For a full overview of wishes in relation to a nextversion, see Section 7.1: “The Next Nulaz”.

30 Chapter 3. Nulaz

Chapter 4

Mobile and ContextAware computing

“The whole point of context-aware computing is to serve you. If we’resuccessful, you won’t even know you’re using technology at all.”

– Mark Smith - Hewlett Packard

When Mark Wieser wrote down his vision on the future of com-puting in 1991 [117], he saw a future where computers would be

everywhere in the environment, but so blended in that no-one wouldnotice. They would be truly ubiquitous. His devices, that would nolonger be called computers, communicated with the environment andeach other, to serve the needs of their users. He noticed that for thesedevices to be able to help their users, they need to know where theyare, and thus be aware of their context. This led to the developmentof context aware systems.

While Nulaz is one of the first working Location Based Systems forthe general audience, research in Context aware and mobile comput-ing has been ongoing for the last decade. This chapter will give anoverview of this research and the limits and opportunities for workingwith mobile devices.

4.1 Context Aware Computing

The most common definition of context is by Dey and Abowd [23]:

“Context: Any information that can be used to characterizethe situation of an entity, where an entity can be a person,place, or physical or computational object”

31

32 Chapter 4. Mobile and Context Aware computing

Context-aware can then be defined as: “the use of context to pro-vide task-relevant information and/or services to the user” [23]. Theterm “Context aware computing” was first mentioned by Schilit andTheimer [101, 84] in 1994, but the Olivetti Active Badge system [116],developed in 1992, is generally seen as the first Context Aware sys-tem [101, 81]. Using context in automated systems is not an easy task:when people communicate with each other, they use implicit contextualinformation to enhance or steer their conversations [23]. But contextmeans something else to people than to devices [25].

People are very good at determining context: When calling some-one, we automatically make a mental image of the situation the otherperson is in, and adjust the conversation accordingly. An expensivelong distance phone call to an important person, will be totally dif-ferent in wording and expression than a friendly call between acquain-tances [23]. Unfortunately computers don’t automatically have thesesocial guidelines, and need to be programmed to understand context.Even then, they only detect a small set of cues, and a real context canbe difficult do determine from sensor input [25]. From sensors it’s hardto infer that a dark, loud place means that the user is at a theater, anddoesn’t want to be disturbed. While humans might understand this,it will be extremely difficult to program rules like this in software [25].When tried, the rules used are often too easy, leading to irritation ineven simple examples: Microsoft Clippy, who was supposed to help Of-fice users with what they were doing, was hated by its users, becauseit didn’t generally comprehend enough of its context [55]. And evenscreensavers, that determine context by detecting motion, are notoriousfor switching on during presentations [25].

Context consists of location, identity, activity and time [23, 17].This creates many different variables that a context aware system cantry to detect. These include location, heart-rate, temperature, light,level of moisture, orientation, acceleration, emotional state, and so on.Of these, location is most used in context aware systems as, howeverhard to determine, other types of context are even harder to determineautomatically [58]. This has lead to the rise of location aware comput-ing [80], and location is the most used type of context [55, 81, 80].

While context aware systems can also be build for fixed terminals,the use of context is more important for portable devices, as theircontext changes more than that of fixed PC’s [23]. But location is notthe only type of context being used. There is also research being donein using accelerometer data [91], motion and pressure sensors [118], andother types.

4.2. Mobile devices 33

4.2 Mobile devices

When the first man landed on the moon in 1969, his spaceship, theApollo 11, was guided by a computer that run at 2 Mhz, had a to-tal of 38 Kb of memory, and weighted 32 kilograms [13]. Today, everycellphone or portable music player has more processing power and stor-age, in less than 1% of the weight. This trend follows the predictionby Gordon Moore, in 1965, that computers double in power every twoyears [74]. His prediction has been remarkably correct, and computerpower has seen a phenomenal growth. Today handheld devices such asPDA’s, phones and even music players contain more processing powerthan computers did two decades ago [55]. These technological advancesbring the vision of ubiquitous computing to reality [80], and enable peo-ple to access information anywhere [17].

It is however not easy to switch a system from a PC to a moreportable device. Mobile devices have several particular characteristics,compared with desktop terminals, that affect user interaction and us-ability. They have smaller screens, less bandwidth, higher latencies,and less processing power [10, 76]. PC’s and handhelds use differentoperating systems. This means they can’t run the same software, but ithas to be ported to the specific operating system. Furthermore, whilehandhelds have become more powerful, so have PC’s, and modern PCsoftware is often still too resource-hungry for smaller devices. Evenif software is modified to run on handhelds, there are still obstacles.Because handhelds have to be portable, they have smaller screens, andusually lack a full keyboard. This means that less information can beshown, and input is more problematic than on a PC, causing enteringtext to be a laborious task [55, 22].

4.2.1 Limited Input & Output

One problem in using mobile computing devices is that data input ona phone is still cumbersome: full keyboard is hardly ever included, soall text input has to be done with the numeric keys. Also results canonly be shown on a small screen [124, 22]. This limits the amount ofdata that can be shown at a time, and makes navigation more problem-atic. Using automatically determined context can act as another wayof inputting data, and can be used in showing relevant information [58].


4.3 Displaying Location

There are several ways of displaying a location to a user. A location willgenerally consist of two values: it’s description, and it’s geographicalcoordinates. These can be shown directly to the user, but since notmany people are familiar with earth coordinate systems, this won’tmake sense to most users [64]. However, if the current location of theuser is known to the system, this can partly be solved by showing thetarget location relative to the current location. The most basic formwill consist of a vector and a distance. Even more user friendly canbe a map of the current and target location, or directions how to getthere [76]. These three forms have increasing usefulness to the user, butalso require increasing data to be transfered, and increasing processingpower on both server and handset.

A fourth form, which can combine a high usefulness with low band-width in certain situations, is reverse geocoding: The transformationfrom coordinates to the description of a place, such as street address.If the user is known with the target location, an address, descriptionor name of the place can be enough to bring him there. But if theuser is unknown with the location, an address or description will meannothing to him [50].

Displaying maps on phones also has it’s drawbacks. As noted before,mobile devices have limited processing power as well as small displays,and as such require special attention in showing various data to theusers. As the amount of data that can be shown at the same timeis much more limited than in typical computer interfaces, a stricterselection of data to be shown has to be made. In PC based setups,it’s easy to display a map with locations. This isn’t always the bestsolution for mobile based systems, as maps can be difficult do decipheron a small display, and require a lot of network traffic to transfer, whichcan be slow and expensive. Furthermore the typical PC interface (withdrag and drop controlls, and faster connections for updates) makesit easier to navigate a virtual map than will be possible on a mobilephone. The best system will most likely consist of a combination ofthese systems: a target vector with an address, which is linked to amap or a description of the target. This has also been done in Nulaz.

4.4 Platforms

There are several operating systems for mobile phones, and the marketis much more segmented than operating systems for desktop comput-

4.4. Platforms 35

ers [84], where the majority of users uses one of two main operatingsystems. For mobile phones, every manufacturer has their own op-erating system, and often even use different systems for different de-vices. Most of these operating systems are closed, and unlike PC sys-tems, allow little configuration or running of own software. Higher endphones, so called smartphones, do allow the installation of own soft-ware. Unfortunately, they form only a small part of the market, andare still segmented between different vendors. The main programmingplatforms for mobile applications are Symbian, Windows mobile andJ2ME/midlets, with Linux models on the horizon.

Fortunately, there is a programming standard that is included inmost modern phones. It’s J2ME, which stands for Java 2 Mobile Edi-tion. All except the lowest end phones include a small Java virtual ma-chine, and can run J2ME programs, called Midlets. Midlets are quitelimited in processing power, interface options and invasiveness becausethey are run in a protected environment, called a sandbox [62].

J2ME isn’t as much a standard as one expects with the word ’stan-dard’. While there is documentation and a standard implementation,most manufacturers use their own virtual machine, which often intro-duce small differences in implementation. This leads to a tedious devel-opment cycle, where each program has to be tested on many differentmodels by different vendors. Also J2ME isn’t one universal standard,but a set of API’s, and vendors can choose which API’s they want toinclude in their virtual machines. This leads to many different specifi-cations.

Despite the disadvantages of J2ME and Midlets, they form the onlystandard with enough market penetration to build a program for thegeneral audience on. Midlets can run on almost all new phones, fromcheap budget models to high-end smartphones.

4.4.1 Bluetooth

Bluetooth is a short-distance radio technique, intended as a cable re-placement for short distances (typically 10m, and no more than 100m),targeted at mobile devices [46]. The first Bluetooth products appearedon the market in 1999. Today it has evolved to one of the biggestwireless standards for the connecting of peripherals. Most phones andother handheld devices support the standard for the connection of head-sets, car-kits, speakers, and the transfer of files between devices. Blue-tooth also has it’s disadvantages. While it’s designed to use very littlepower [46], it still uses enough to significantly lower the standby timesof phones, and in this it doesn’t comply with it’s own design goals.


Unfortunately, there are some security issues with Bluetooth, and re-searchers [67] advice to leave it off unless necessary. Most phones thatsupport Bluetooth have it disabled as default to save battery and lowerprivacy issues. Nulaz uses Bluetooth to connect the phone to an exter-nal GPS device, as it is the only working way to connect a device tomany different handsets.

4.5 The Internet is Non-geographic

The current design of the Internet does not link a location to informa-tion [57]. Current Internet search engines hardly make any distinctionin geographical distance. This is great while looking for scientific arti-cles, for example, as they aren’t bounded to a specific place. But whenlooking for a movie to visit, people are not interested in movie-theaterson another continent, country or even city: they want to know themovies in their area, which they can visit. This has happened to me:When searching for a bar, I ended up on the website of a place withthe same name, but located in Boston, at 5500 km from me, hardlythe bar around the corner! Especially for mobile devices search basedon location is preferred above general websearch [12]. Proximity basedsearch enables the discovery of things that are in the vicinity of theuser, yet are unknown to him, and offers more relevant results thangeneral web search for local searches, while in need of less cumbersomeinput [58].

4.6 Context in Nulaz

While there has been research in context aware systems, working withcontext is still hard [84], and requires a lot of development. Nulaz,being built as a context aware system, mainly uses location as context.Almost all information that flows through the system has a locationcomponent. Some parts of Nulaz also use time as context: The parkingdata looks at the current time to predict free places, the movie andcultural events listings only show events that haven’t started yet, whilstthe local pictures only shows pictures that have been taken recently.In a future version further filtering based on user preferences will beincluded. It should thereby not only include the users own location,but also that of his friends, in suggesting places to go together. Alsoother types of context such as local weather can be used in advisingusers.

Chapter 5

Locating the User

“We are all in the gutter, but some of us are looking at the stars.”– Oscar Wilde

When sailors in previous centuries wanted to know where they were,they used the stars to navigate. A sextant revealed their current loca-tion after some tedious manual calculations. The most common modernlocating technique, GPS, uses the same basics. It looks however with aradio receiver at modern man-made stars, and the necessary complexcalculations are automated in hard- and software. The complexity ofthese techniques shows that locating users in the wild is a non-trivialtask. In a discussion on Context Aware computing, Pete Steggles men-tions that “Really accurate location is 99% of the battle” [23]. Thischapter will describe the issues and techniques for locating users. Itstarts with the requirements, and will than describe the advantagesand disadvantages of the different techniques, which will lead to thechosen locating technology for our system.

5.1 Accuracy

The accuracy needed for location based systems depends on the specificusage of the system. While some systems can suffice with an accuracyof several kilometers, others will need a sub-meter resolution, for ex-ample for locating borders of property. For our intended application,finding people and places, an accuracy of several (tens of) meters isworkable [18]. If a user is directed to withing a few meters of a place,the exact target can usually be seen in the environment.

37

38 Chapter 5. Locating the User

5.2 Locating Requirements and Technolo-gies

There are several ways to determine the position of a user for use ina location based system, each with its advantages and disadvantages.The chosen technology will depend on the needed characteristics of theservice. Variables between different technologies include:

• Accuracy: countries to centimeters

• Price

• Availability

• Size of the area that needs to be covered

• Coverage investment

• Type of coverage (indoor, outdoor).

• Power consumption

• Physical size

The ideal solution would be accurate in a sub-meter range, cheap,work everywhere worldwide, both indoor and outdoor, in any environ-ment, without further investment in the environment, need almost nopower and be indefinitely small.

Unfortunately, such a technology does not exist yet [17], and forthe determining of user locations, we are left with several currentlyavailable technologies. The (dis)advantages of each will be discussedhere. There are many location-determining technologies possible, usingultrasound [47], infrared [2, 101], electromagnetic field strength [64],specific radio solutions [68, 52], or combinations of these. Usually theyare geared to specially designed terminals and need modifications tothe environment that can’t be made on a large scale [18]. As Nulaz hasto be a system for mobile phone users, this evaluation will be limitedto systems that can be coupled to a mobile handset: either includedin the handset, or linked to handsets. It will not discuss possibilitiesthat could be theoretically technically possible but are unlikely to bebuild, such as a network of ultrasound transmitters and an ultrasoundreceiver in the handset.

A requirement for many location based systems is that they workfor a large number of users, during a large part of their time. It’sbelieved that in the near future, many systems expect 100% locationcoverage, like we expect our cell phone to always work [64].

5.2. Locating Requirements and Technologies 39

GPS Cellularprovider

Cellularhandset

WiFi Tag-based

ManualEntry

Accuracy 5-10m 50m-30km

2.5-200m 13-40m Meters 10m-10km

Coverage Worldwide Mostcountries

Mostcountries

Urbanenviron-ments

Very local Depends

Indoor/outdoorcoverage

MainlyOutdoor

Both Both Both Both Both

Hardware GPSchip

Phone Phone Wifireception

Tagreader

Phone

Coverageinvestmenta

None Done byprovider

Mappingcoverage

Mappingcoverage

Taggingplaces

Geocoderb

Dis-advantages

Coverage,extrahard-wareneeded

Providerowned,expen-sive toaccess

Not pos-sible incurrentphonesoftware

Wificoverageneeded,Exten-sivemapping

Worksonly invicinity oftags, ac-tive userinputneeded

In-convenient,user inputneeded,not every-where

aFor builder of Location Based SystembAvailable for free, nowadays

Table 5.1: Overview of locating technologies

This thesis is geared to location determination for mobile devices,and as such won’t discuss the location of users on fixed PC terminals1.For Nulaz a technology was required that was as accessible to the useras possible (in terms of price, size, and availability), while accurateenough. This section will discuss the following technologies:

• GPS• Cellular network based (both network and handset based)• WiFi• Tag based systems (RFID/2D barcode/Bluetooth)• Manual entry

The several technologies each have their own characteristics, shownin Table 5.1. As all of these technologies are still emerging (with GPSbeing the oldest), there is no single standard to interface with a loca-tion determining system: each system has it’s own way of outputting

1For fixed PC’s there is another technique for determining location: there aretools that map PC IP addresses to coordinates. Unfortunately, they are quiteimprecise, working at city level at best. The Nulaz webinterface uses manual entry


a location, and even systems that use the same technology don’t nec-essarily deliver their data in the same way. This means that the de-velopers of LBS have to spend much time building specific interfacesfor each technology, often far-reaching into the used technology. Thismakes switching a system from one technology to another cumbersomeor even impossible [64].

5.3 GPS

GPS, which stands for Global Positioning System, is the oldest com-puterized locating technique and in widespread use, as it’s the onlytechnique with a worldwide (outdoor) coverage. Being invented by theAmerican military, it has made the transition to the civilian market,and today is being used in almost every navigation device for any meansof transportation. From flying and sailing to car-races and ski tours:all commonly use GPS to determine their location [49]. It is also usedas a basis for other location based systems. War-driving, for the locat-ing of WiFi networks, uses GPS as grounded truth [61, 64], and othermapping systems heavily rely on it. GPS works by a constellation of atleast 24 satellites 2, each orbiting the earth every 12 hours, at a heightof 20200 km [44]. These satellites broadcast their own location, anda very precise time signal. The reception of at least 3 of these signalsenables the receiver to calculate the time of travel of the signals, andfrom this his own location.

The first receivers where bulky and expensive devices. But, as com-puters got faster and smaller over the years, so did GPS receivers. Bynow one can buy a GPS receiver which easily fits into the palm of ahand for under a hundred euros . As the chips these devices use getcheaper, they are also being introduced in other devices than standaloneGPS receivers [50], and the first cell phones with GPS are entering themarket [79]. There are many external GPS dongles [64], and externalGPS devices can be linked to cell phones through Bluetooth. GPS hasa mean accuracy of between 8 and 10 meters, which can be improvedwith other techniques such as Differential GPS and WAAS [96].

Unfortunately, GPS also has disadvantages: the main ones arepower consumption and indoor coverage. While GPS devices have be-come much smaller and less power consuming, they still are a big drainon the small batteries in cell phones, using more power than currentcellphones themselves. And while GPS devices can work continuously,

2Currently there are 29, with the extra 5 providing extra coverage, and actingas hot-spares [44].

5.4. Cellular Network based location 41

the time from startup to a first location fix can be several minutes [75].The weak indoor and city coverage is the biggest disadvantage of

GPS. The faint GPS signals from satellites often can’t be received in-doors, or even outdoors due to urban canyons. High buildings in mod-ern cities, block the “view” of the sky [14, 50, 61]. Some tests showdown to only 4.5% coverage for GPS in a typical working day for auser [64, 18]. To solve this, GPS can be combined with other locatingsystems, such as WiFi or cellphone based systems [14]. And newer GPSchipsets have better receivers, offering improved indoor coverage. Wedid a small test with a modern GPS with SiRF III chipset, as shownin Figure 3.3 on page 24. In three days of testing, a coverage of 25.1%of the time was measured. Europe is working on it’s own GPS sys-tem, Galileo that will offer better indoor coverage as well as betteraccuracy [14].

5.4 Cellular Network based location

Figure 5.1: Reuse of frequencies in cellular networks

Cellular networks have as an advantage that they provide ubiqui-tous coverage in the developed world, as well as provide a stable en-vironment, while using an already existing networking-ecosystem [83].Modern cellular networks are build in cells, that vary in size from tensof meters to tens of kilometers. Where, in the first (analogue) mo-bile networks, a frequency was reserved for each user in the network,modern networks reuse frequencies in non-adjacent cells, as shown inFigure 5.1. The cells with the same numbers use the same frequencies,without overlapping or bordering cells with the same frequency. Thesecells can be used in two ways to determine the location of the user: By


locating the handset in the network, or on the handset itself. The nextsections will explain these two methods.

5.4.1 Network based

To get the right phone ringing with an incoming call (and for othernetwork functions), the network keeps track of the cell the user is in.This gives a global position of the user. But, as cell sizes vary, thislocation can be off by tens of meters, up to kilometers. Accuracy canbe increased by determining the location of the user within the cell bymeasuring the time difference between the phone broadcasts and theirarrival to one (or more) cell-towers. This will typically result in anprecision up to several hundred meters in urban area’s, and is unlikelyto exceed 50m in the most perfect conditions [75]. In rural area’s, wherecells can be up to 35 km (or 70 km for extended cells [114]) in radius,the position will be even less accurate. For many applications, this isnot accurate enough.

Another problem with this approach is that the network providerscontrol this data. There are countries where it’s possible to gain com-mercial access to it, but in many countries, such as the Netherlands,this currently isn’t supported by the network providers. And nowherethis information is freely available to the users (which is strange, as it’stheir location!), but it’s common to charge around e1 per location up-date. This imposes a seriouslimit on the growth of these services [64].A big advantage of this technique is that the user doesn’t need newhardware for it: as it’s a part of the network design, it’s supported byevery handset. It also takes no extra power, as the phone doesn’t needto change what it’s doing, and basically allready is being used to trackphones for accounting purposes.

5.4.2 Handset based

The second way of determining the location of the user is doing thison the handset, instead of in the network. As cellular networks arebuild out of different overlapping cells, a user can typically receive dif-ferent cells at the same time, which can give a unique fingerprint fora location. However, normal handsets only reveal the current Cell-ID to the software, resulting in poor accuracy [64]. This limitationis an artificial one, imposed by the phone manufacturers and serviceproviders [50, 115], to maintain the provider monopoly on locationbased services. Special modifications to the handset seem to give bet-ter results, and gives an accuracy up to 2.5 meters indoor [83] and

5.4. Cellular Network based location 43

Figure 5.2: Locating a user with Cell-ID’s [31].

some 75-200m outdoor, depending on the technique used (fingerprint-ing or centroid algoritms) [115]. Centroid algorithms use a mathe-matical model of signal attenuation, while fingerprinting use actualmeasurements. Fingerprinting is more accurate, but requires exten-sive mapping. Unfortunately using these techniques requires softwaremodifications to the handset beyond the reach of just installing an ap-plication3. Accuracy would be more than sufficient for many LBS suchas localized search. It has the extra advantage that no other hardwarewould theoretically be needed, if this technique would be supportedby the software on the handsets. A disadvantage of this type of lo-cation determination is that it needs an extensive data collection tomap received cell-ids to locations [115], and this data can be subjectto change, although research is being done to do this by the everydayusage of users of the system [66].

3The tests in the previously mentioned article [83] were mostly done on a low-level GSM modem, which allowed access to the GSM data that isn’t available tothe software on a normal handset.


5.5 WiFi based

A new development is locating using WiFi networks. WiFi, while orig-inally intended for computer users, is increasingly being integrated intohigh-end handsets, as a means of faster (and cheaper) Internet access,at home or in the office. Some phones also include the ability to makeVoIP phone calls using a WiFi connection [79]. As WiFi networks be-come more ubiquitous, in urban areas one can often receive several net-works at once. Seattle, for example has a WiFi access point density of1200/km2 [64]. As WiFi has a limited transmit power of 100mW [26],it’s reach is limited to a couple of hundred meters in typical urbanconditions [65]. Each network device has a unique MAC address, thatcan be received, even if the network is secured [65, 50]. Therefore thereception of networks in a certain place can be used to uniquely identifya place. If this place, and it’s received networks is indexed, this can beused to determine the location of the user.

An advantage of this technique is that it only requires a WiFi re-ceiver in the handset to determine a location, which is starting to beincluded in more higher-end handsets. Another advantage is that thistechnique works best in urban environments, where satellite based solu-tions are weakest [64]. Accuracy in urban neighborhoods is around 13-20 meters, dropping down to 40m in less populated areas [18], enoughfor most LBS applications. Disadvantages are that it only works ifenough WiFi base stations are in range: at least one is needed to de-termine a location at all. This makes this technique unsuited for usein more rural environments, where there are large areas without WiFireception. Combining WiFi with other techniques such as GPS hasbeen proposed to solve this [14].

Also, the reception of WiFi signals alone isn’t enough, since WiFinetworks themselves don’t include geographical reference. The locationof the networks needs to be known before a combination of MAC ad-dresses can be translated to a location. There are groups working on adatabase for this translation, such as wiggle.net.

These databases of WiFi networks are generally built by wardriving(or war-walking) an area. Wardriving is the process of driving aroundwith a WiFi receiver and a GPS, recording the reception of networks indifferent places [18]. This leads to an estimate of the beacon location,which can be used to locate the receiver. However the estimation ofthe beacon introduces an error in the locating [64], and the usage ofGPS ads a small further error [18].

Also, since WiFi locating is based on uncontrolled infrastructure,the mapping of beacons will change over time, as users replace their

5.6. Tag based 45

hardware. This will lead to the need to re-scan areas once in a while.In one case, a student campus, 50% of the beacons changed in a coupleof months, as students switched to and from the area [18]. Kim, Field-ing et al. 2006 show that war-drive based location collections are lessaccurate in showing users location, than useing real access point loca-tions. They proof that an accurate map of access points can increasethe accuracy of WiFi-based location techniques up to 70% [61] .

5.6 Tag based

Several proposed systems [1, 105, 94] work by placing tags on knownlocations. These tags can be anything, as long as they are unique totheir location, and can interact with the handset. This interaction canbe sourced on either the tag, or on the handset, although mostly thetags are dumb and the handset does the processing. All tag-based tech-niques have as disadvantage that they only work on tagged locations, inthe vicinity of a tag. They can be used as solution for certain applica-tions, where the locations can be tagged, but can’t form a solution fora general location based system, as they don’t provide ubiquitous cov-erage. This section will describe systems that work with RFID, Blue-tooth, and 2D barcodes, as these all can interact with mobile phones.

5.6.1 RFID

RFID is a technique for Radio Frequency IDentification; a sort of wire-less barcode that can be read over small distances. RFID currentlyhas as disadvantage that there are no (commercially available) phoneswhich include an RFID scanner. Only in Japan, where 15 millionphones include a scanner for Near Field Communications (NFC) [100],an extended form of near field radio communication, this technique hasseen an uptake, although not for use in LBS. Telecom providers expectthis technology to be included in other countries as well, but mainly forother short range communication features such as wireless payments,access control and boarding passes [100]. When phones include RFIDscanners, places can be tagged with an RFID tag. The presence of sucha tag then indicates that the user is at a certain place, which can beused by the LBS.


5.6.2 Bluetooth

Bluetooth based solutions have been tested, and are being used forlimited types of setups, mainly based around advertising on a certainlocation [1, 77]. Their advantage is that they use the Bluetooth technol-ogy for short-distance communications that is included in most modernhandsets, and thus require no extra hardware. A disadvantage of Blue-tooth is that, although most phones include this functionality, manyusers have their Bluetooth disabled for privacy, battery saving or secu-rity [67] reasons. See also Section 4.4.1 on 35. If Bluetooth is enabled,it can also work the other way around than most other systems: Theenvironment can detect the user and react to its presence [1], sincephones can transmit Bluetooth signals.

5.6.3 2D barcodes

Figure 5.3: Example 2D barcode/Semapedia tag [105].

A third, tag based, solution is the use of 2D barcodes to identify alocation. 2D barcodes are images with text encoded in them, similarto 1D barcodes on supermarkt products. An example can be seen in

5.6. Tag based 47

Figure 5.3. Because these barcodes encode information in 2 dimensions(instead of 1, as the EAN barcodes in the supermarkt do), they cancontain more data. Also they are specifically designed for decoding withcamera’s [94], which are found in many phones. This can be used tolink an ID to a place, by tagging the location with a unique barcode, asfor example done in the Cybercode [94] paper. These barcodes then canbe scanned with the camera included in most modern phones, and withsoftware running on the handset, be decoded to a unique ID referringto the current location [98, 94, 105].

The advantage is that these tags can be easily produced with normalprinters, and thus cheaply attached to a location. Some work has beendone to produce visually appealing tags, to lessen the visual clutter of2D symbols [22].

A weakness of this technology is that the user actively has to recog-nize and scan the tag: it is not possible to detect the location withoutthe intervention of the user. It also needs special software on the phoneof the user to decode the barcode to an ID which can refer to a location.This software is currently widespread in Japan [30] where 30 millionphones include this functionality, but is not common in other countries.

Another problem with this technique is that, although many phonesinclude camera functionality, these often don’t have a sufficient macrofunction, needed to take pictures of a small tag, which means that thescanning is still an error-prone process. Another disadvantage is thatthere are several competing standards: QR-code4, datamatrix5, sema-code6 and shotcode7. These are all owned and promoted by differentcommercial organizations, and there is no compatibility between thedifferent types, resulting in a scattered market and no real uptake out-side Japan. A evaluation of 2D barcodes goes beyond the scope of thisthesis, but Rohs [97] gives an overview of different visual markers. De-spite it’s disadvantages, Semapedia [105] has started a project to placeSemacodes [104], a type of 2D barcodes, on physical objects to linkthem to their pages on Wikipedia.

4http://www.qrcode.com/5http://www.acuitycimatrix.com/DM%20Basics.html6http://semacode.org/7http://www.shotcode.com/


5.7 Manual Entry

Figure 5.4: Telephone Keypad

When in a known environment, it’s possible to have the user enterit’s location into the handset. The advantage of this technique is that itrequires no extra hardware on the users part, and as long as the handsetcan show an interface, either webbased or in an application, the usercan update its position to the system. As users will seldomly know thecoordinates they are at, they will enter their location in the form ofan address or description that has to be translated into a geographicalcoordinate for most applications. Disadvantages of this approach areambiguity and misspellings in user input, hassle to the users, geocod-ing errors [92] (See also Section 6.5 on page 55) and non-known loca-tions. Adresses are vague place descriptions. One location can haveseveral descriptions, and one description can have several meanings;street names, or other location identifiers, aren’t unique globally. Ac-cording to Ratcliffe [92], there are forty occurrences of ”Smith street”in just the Sydney area.

Another disadvantage is that it’s a hassle to input a location as textstring (like ”Dam 1, Amsterdam”), into a mobile handset [15]. Thiswill lead to less location updates than in an automatic system, as userswon’t be constantly updating their location, but only when they seea need to interact with the system (for instance, to perform a localsearch).

A third disadvantage of this technique is that the current locationis often unknown to the user itself: if he is in known surroundings hewill often be able to enter his location in the form of an address, butlocalized services are often most useful in unknown territory, where theuser might not know his own location.

5.8. Sampling Frequency 49

5.8 Sampling Frequency

While the different techniques have a different accuracy when theyacquire a location, they also have a different sample rate. An automatic,ubiquitous system such as GPS or WiFi can update itself every second,whilst a system that requires manual intervention will have a muchlower update frequency. As most users of mobile systems will be mobile,a system with a lower update frequency will have a lower accuracy overtime, even if the accuracy of each point, when taken, is higher [75].Thus a higher sampling frequency leads to a better accuracy over time.

5.9 Locating in Nulaz

All locating techniques have their own advantages and disadvantages.Unfortunately there is no ever working technique. Choosing the rightlocating technique will depend on the demands on the system, in termsof coverage area, investment, technical demands, etc. For Nulaz mosttechniques mentioned here were not a real option: Cellular networksolutions have too low accuracy, require extensive mapping, and areexpensive to build in a large area, or require provider support. Itis expected that such options will become available in the future [80].WiFi locating, whilst showing much potential, does not yet have enoughmarket penetration to be a solution for the general market. Tag basedsolutions are a hassle to the user, as they often require manual inter-vention from the user in scanning the tags. Moreover placing tags onmany locations is a laborious task.

For these reasons, Nulaz mainly works with GPS. Despite its disad-vantages, GPS needs almost no investment, works immediately, and hasa high accuracy, both geographic and over time, as frequent updatesare no problem. Also the output of a GPS consists of direct coordi-nates, where other systems (such as WiFi) need an extensive databaseto match their output to a location. For this small-scale project such adatabase wasn’t feasible. Thereby both hard- and software were readilyavailable for my chosen platform: some of the technologies shown herearen’t possible (yet) on mobile phones. Also manual entry is includedas an option in Nulaz. Despite its disadvantages it does allow an easyfallback for users without another location technique, and can be a niceway to get familiar with the system without the need to install specialhard- or software.

For a future version both WiFi localization, and a tag-based Blue-tooth solution for specific places, will be tested as locating techniques


in the system. A cellular based solution would be ideal, as no otherhardware is needed. Unfortunately, these systems currently provide toolittle accuracy and support both in hard- and software.

The next chapter will focus on the other side of the equation: Show-ing relevant data on the current context.

Chapter 6

Location Based Data

“Romeo oh Romeo, where are thou, Romeo?”– William Shakespeare

To match location based data to the location of a user, there aretwo sides of an equation that need to be matched. The location

of the user has to be known, as well as the geo-reference of the data,and both need to be in a comparable format, usually a coordinatesystem. This poses two difficulties: One needs to obtain a list of geo-referenced locations, and the position of the user, both with enoughaccuracy. After discussing locating techniques, this chapter will discussthe gathering and exchange of location based data.

There is a trend to show coordinates with relevant webpages, andnew formats are arising for the exchange of location based data, such asKML and GeoRSS. A LBS will not only have to deal with the locatingof the user, but also with importing (or linking to) this geo-based data,and will have to make a match between the two datasets. This sectionwill describe some sources of location based data, their formats and thematching between datasources.

6.1 Web service API’s

The web is becoming more of a platform where different websites shareinformation, and mashups use the data of different websites to offeran unique combination [34]. These websites offer their data in an Ap-plication Programming Interface, API. An API is an interface, witha set of standards, defined by it’s designer, to communicate betweenpieces of software. There are some web service API’s that offer geo-referenced data, such as Flickr who offers coordinates with some oftheir pictures [27], and Wikipedia, who offers a SQL download of theirgeo-referenced articles [120]. Unfortunately, these API’s don’t share a

51

52 Chapter 6. Location Based Data

common format, for input nor output. Their input usually exists of aspecific URL format, and their output in a form considered useful bythem (and that can be anything: we have seen Json, PHP-serialized,KML, (Geo)RSS, SQL, CSV and custom XML formats). This meansthat integrating these sources into a website will always have to be donespecially for that project, instead of making general remote API calls.Hopefully, with the growth of geo-based formats and the maturing ofthese API’s, a standard for querying these systems in both input andoutput, will emerge.

6.2 Data mining

API’s are always a preferred way of exchanging data between websites.They offer an official, stable interface, and documented input and out-put methods. Their results are usually structured, and in a formatthats easy to parse on the retrieving end. Offering an API also impliesthat its provider allows the data to be used in other projects, althoughthey often have licensing restrictions, such as the exclusion of commer-cial projects. But if a website doesn’t offer an official API, it is oftenstill possible to retrieve its data for use in other projects. This can bea bit of a gray area, and the legal status can be uncertain and has beenthe reason for several lawsuits between companies such as Kranten.comvs newspapers [73]. Because the web is build out of HTML pages thatare downloaded by a webbrowser, these pages can also be downloadedby other mechanisms, sometimes faking to be a webbrowser. As theHTTP standard [43] which forms the basis of all webbased commu-nication is well known, it’s quite trivial to build a tool to downloadwebpages, and many such tools exist. The retrieved pages then can bereverse engineered, and parsed for important parts of data that can bestored or otherwise used by the retrieving system.

6.3 Formats

With the rise of geobased information systems, and the rise of dataexchange on the Internet, new standards for geographical based dataexchange are arising. Where there have been previous formats toexchange GPS waypoints and routes, such as GPX [29] or simplyCSV [106], they didn’t provide enough context to be used in most In-ternet applications. This led to the growth of new geospatial exchangedatatypes.

6.3. Formats 53

The geographic industry developed GML as a standard, capable ofhandling any geo-related situation. This made its specifications verycomplex: The description of the standard is over 600 pages, and itsusage was too complicated for simple applications. The format wasthus not widely supported or used. This led to the rise of easier, lesscomplex formats [108].

At the same time webbuilders who didn’t know the GIS standardsextended their platforms to include geo-references, based on their ownformats and standards. This led to websites with their own scheme foradding coordinates to pages or other datasources [108]. For instance,for systems that allow tagging of content, the following types of tagsshow a geotagged item [122]:

* geo:lat=latitude e.g. geo:lat=51.4989* geo:lon=longitude e.g. geo:lon=-0.1786

This is not a formal standard, but more a popular convention, followedby many users [45]. These tags led to new export formats. The twomost popular are KML [39] and GeoRSS [32], each with their owntarget usage.

6.3.1 KML

With the rise in popularity of Google Earth [38, 103], its data format,KML [39], is being published on a growing number of websites whichinclude geographical data. KML, which originally stood for KeyholeMarkup Language, is an XML based language. As other XML files, it’smanually editable with a text-editor, or can be generated by software.KML is focused on geographic visualization: it enhances the (virtual)earth. It can be used to link to specific places, and add placemarks, 3Dmodels and other descriptions to them. It can also include descriptionson how to display these places, such as camera placement and angle.Google is in the process of submitting KML to the Open GeospatialConsortium (OGC) standards process[20], making it an open standardthat anyone can freely use. But as the format is well documented [39],it can already be used by other systems. Google has started to crawlall public available KML files, to create a geospatial aware search en-gine [102].


6.3.2 GeoRSS

The last few years there has been a big rise in RSS feeds. RSS, whichstands for Really Simple Syndication is becomming the defacto stan-dard for exchanging data between websites. It is mainly used to dis-tribute updates, for example from newssites or weblogs. One of itsadvantages is that it is has defined fields for titles, urls, dates and soon, making it easy to parse [53]. GeoRSS is a simple extension to thisformat, that ads a format for embedding coordinates in these feeds,describing the spatial reference of the items in it [53]. An example isshown in Figure 6.1 that shows part of an GeoRSS feed, which bothincludes an sqare area for the whole feed (the <georss:box>), and anitem with its point location (<georss:point>) The format is being rec-ognized as a standard by multiple big players on the Internet [70, 71].It can be used in mapping solutions by “the big three”1. As with KML,it is also in the process of becoming a official OGC standard [53]. Therise of GeoRSS feeds and KML files, will facilitate a world wide geo-graphic search. This will enable users to, for example, show all newsitems within 10 km of his home, regardless of their source[53].

<rss version="2.0" xmlns:georss="http://www.georss.org/georss">

<channel>

<title>GeoRSS-Simple Example</title>

<description>Example GeoRSS-Simple Feed</description>

<georss:box>38.373576,-122.854022,38.423121,-122.804327</georss:box>

<item>

<title>GeoRSS-Simple Point</title>

<description>A point describes a single location</description>

<guid>urn:uuid:d496f4e3-7fd8-4169-ac6208e36dffa7f0</guid>

<link>http://georss.org/example/simple/point</link>

<author>georss supporter</author>

<pubDate>Wed Jun 20 13:18:59 -0400 2007</pubDate>

<georss:point>38.373576 -122.854022</georss:point>

</item>

Figure 6.1: Example GeoRSS source [32].

6.4 Points and Places

I once tried to find out where Prague was located, according to myGPS device. This led me to a distant and abandoned field, far fromthe city center. At this specific point, according to my GPS, the city

1Google[111], Microsoft[110] and Yahoo[69].

6.5. Geocoding 55

was located. This shows a problem in working with coordinate systems:Coordinates are often used to represent points which have no dimen-sions, where as real world objects always have a dimension. Somesystems work with areas, but this leaves other problems with edgesand accuracy [84]. These issues can lead to problems with larger ob-jects: What should the coordinates be for a large shopping mall oreven bigger areas such as a city? Coordinates have as advantage thatthey can be pointed to, but most places take up more space than thecurrent point they refer to.

6.5 Geocoding

For a lot of locations databases of places exist in the form of yel-low pages, phone directories, or other lists of places to go. They do,however, seldomly include direct geographical coordinates that can bematched to the coordinates of the user. Addresses, while sometimesmeaningful (See Section 4.3) to humans, can’t be directly compared tocoordinates. A translation from addresses to a point in coordinates doesenable this comparison. This process is known as geocoding [92, 50].But as Ratcliffe [92] pointed out, this data can be inaccurate, and inhis trials had a mean error of 47 meters, and some rare cases wereoff by over a kilometer. This decreases the usefulness and accuracy ofreferencing people to geocoded locations.

Geocoding applications used to be expensive tools, which limitedtheir use. But the growth of web-based mapping solutions has ledto many free geocoding solutions from mapping providers such asGoogle [36] and Yahoo [123], lowering the barriers to entry in the LBSmarket. Until more systems include their own locations, geocoding willhave to be used, but it’s results aren’t always what they should be.

6.6 Matching

When both the location of the user and the interesting features in hisenvironment are known, matching those is a relatively easy task, butcan be quite computational expensive. For instance, a search within acertain radius from a location on a large database implies the compu-tational expensive calculation of a distance from all known points inthe database to the location.

To lighten this load, many geo-based searches don’t use a point anda radius, but a bounding box model. This bounding box consist ofadding and substracting a small amount from the target coordinates,


and finding all points that fall within this box. Calculating whetherpoints should be included then involves the simple checking of twoequations, instead of complex calculations for each point. It has thestrange consequence that the maximum search distance depends on therelative placements of the items, as the maximum search size is is

√2

times the minimal. Some systems then use the slower radius basedsearch to further filter these results.

All resulting distances are euclidan distances, which in the realworld can only be used as an estimation of the real over the road,distance which will always be larger. This can be a good estimationin most cases, but can also lead to unexpected results. A target thatis only a few meters away can be unreachable if the two points areseperated by a long river. A perfect system would use a routing systemto determine the real-world distances, but for now this is too slow tocompute for large datasets, and the data needed is not available for alltypes of transport.

6.7 Content

Geocoding does imply that the address of the location is known be-forehand, which doesn’t hold true for many databases that include in-teresting geographical features. Websites, such as Wikipedia describemany places but don’t always include geographical references with thoseentries. For example, the English Wikipedia, that at the time of writ-ing has 1,670,409 articles, has only 142.000 articles, or 8,5 %, witha geographical reference [119, 121]. Not all pages will eventually havecoordinates, as items such as math explanations don’t have a geograph-ical reference. There are automated systems to add places to webpagesbased on their contents and names used in the text, but they don’tachieve a high accuracy [4], due to common words being detected asplace names, and place names being non-unique worldwide. And whilepictures can be interesting parts of a LBS there are currently hardlyany cameras that include a georeference, so pictures have to be eithermanually geocoded, or linked to other geo-sources. For now much geo-indexed content will have to be manually linked to a location.

6.8. Nulaz Data 57

6.8 Nulaz Data

Nulaz uses a geometric model for it’s location based data as it deter-mines and shows items based on their coordinates, as opposed to asymbolic model [17]. The system consists of several datasources, thatare parsed based on their origin. While not explicitly designed thatway, every datasource in Nulaz currently has it’s own unique way ofgetting its data into the system, as there was no general way availableto use all the data sources. This section will discuss each source andwhat was necessary to use it in Nulaz.

6.8.1 Flickr: API

Flickr offers an API [27] to search the five hundred million pictures intheir system [8]2. When a request for local pictures is made on one ofNulaz’s interfaces, the server builds a bounding box around the currentlocation of the user, and requests pictures that recently have been takenin the area from the Flickr server. The Flickr server responds with aresult-set. These results are then sorted on distance from the currentlocation and shown to the user. The Flickr pictures in Nulaz are thusa live feed.

6.8.2 Google Maps: Own converter

Google offers an extensive API [36] to include its maps in webpages.This API consists of Javascript, which can be included in the page, thatgenerates the code for showing and modifying the maps. The mapsconsist of many images, slicing the world in pieces of 256*256 pixels.See Figure 6.2 for an example. The API offers two kinds of maps: onewith a map view, and one with satellite or aerial photographs. Thecoverage of each tile depends on the zoom level, and varies from wholecontinents to sub-street-level. In the lowest zoom, the whole world fitsin one tile, and each consequent zoom doubles the number of tiles inboth directions. So each zoom level n has 2n ∗ 2n tiles available. Thismeans that at the (current) highest zoom level 17 the world consists of22∗17 = 17.179.869.184 tiles 3.

The amount of zoom available varies for different parts of the world,but in the Netherlands, generally all 17 zoom levels are available. Each

2Of these 500 million, currently 22 million have geotags [28], but this number isgrowing fast.

3However not the whole world is available in all zoom levels, for sea there aregenerally not many zoom levels, and different counties have varying levels of cover-age.


Figure 6.2: Google Map Tiles. The shown map part actually consistsof parts of the four tiles around it [99].

image has a unique URL, based on it’s location and zoom level. TheJavascript generates these URL’s for each of the tiles, and changesthe shown images as the user changes their view. Unfortunately, mostmobile webbrowsers don’t support Javascript, and therefore can’t runthese maps. To get a working map for the mobile webbrowser, a server-side version of (part of) the API had to be build, that returned plainHTML and images which phones would support.

This was one of the most complex parts of Nulaz to build. It consistsof a script that retrieves the location of the user from his session. Ifthe map requested contains two points (for targeting a location), thealgorithm zooms out until both fit in the same map. It then uses areverse-engineered algorithm to generate the URL of the corresponding

6.8. Nulaz Data 59

proprietary Google map tile. This tile is placed at the center of a 3*3

Figure 6.3: A sample grid of 9 tiles with cutout for phone size, beforeit is send to the user.

grid. Depending on the place of the user on the central tile and thescreen size of the user, up to 8 tiles around it are also retrieved andplaced in the grid. The location of the user is also added, on top ofthe images, as a small cross. A part of this grid, centered around thelocation of the user and based on his screensize is than cut-out. Theresult is rendered as a new image and send to the user. If the userrequests a satellite view, another algorithm transforms the variablemap URL in another URL, for the satellite tiles. Figure 6.3 on page59 shows the grid with four received tiles, and a cutout part for aphone screen (of 176*220 pixels). The black parts are tiles that are notretrieved, because they are not necessary for the end result. The white


grid lines have been added here for clarity, and are not shown in thelive version.

6.8.3 Wikipedia: SQL import

The Wikipedia links in Nulaz only include the pages on Wikipedia thathave a geograpical reference, currently 142.000 [121]. These pages aremade available as an SQL dump by Wikipedia [121]. This SQL dumphas been imported into the Nulaz databaseserver. When a user requestslocal Wikipedia links, the nearest points are queried from the database,sorted by distance, and returned to the user. The advantage of thisSQL dump is that the search can be done locally, with a low latency,as opposed to live searches that add request and response times.

The disadvantage of this method is that it doesn’t use the mostrecent data, but instead an aging dump of the database, that needs tobe updated every few weeks or months. As Wikipedia doesn’t offer aofficial API, there is no way of interfacing directly with their systems,for geographic searches. Also tried a live search system from Placeo-pedia [78] has been tested, but this worked too slow, and showed lessresults than the current dataset.

6.8.4 Restaurants: Ripping

The restaurant section was done by harvesting a well-known Dutchrestaurant review site. By exploiting a bug in their search algorithm, alist of all restaurants in Amsterdam could be build, consisting of fiftypages of results. These fifty pages were downloaded with a Firefox plu-gin and merged to one large file. This file was then parsed with regularexpressions, to find the name, address and score for each restaurant.These were added to the local database. Since this database lackedcoordinates, they were added by querying each address in the databaseagainst the Google Geocoder [36]. When requested, the server sortsthe restaurants on distance from the current user location, and returnsthe closest fifteen results.

6.8.5 Parking data: Live parsing

The municipality of Amsterdam offers information on the availabilityof parking places in a few large car-parks on their website [5]. This datacan be of use to the Nulaz users, but unfortunately there is no officialinterface except for the webinterface. It was not possible to export

6.8. Nulaz Data 61

this data just once as it’s ever changing with current events, and to beuseful, it needs to be recent. Thus, a live system had to be build.

When a user requests parking information from Nulaz, the list ofparkings is first sorted on distance from his current location. The web-page of the closest match for the current time of day is then downloadedto the Nulaz server, and parsed for the current availability of parkingplaces. This information is then shown to the user, together with thelist of other parking areas. Unfortunately this process is quite slow,mainly because the response time from the bereikbaar.amsterdam.nlwebsite is almost two seconds4. This currently eliminates the possibilityfor directly showing availability for all parkings in the area, as queryingfor this information would impose a too long waiting time for the user.In a future version, a parallel version of the parsing script might beable to solve this. For now, the user can select another garage (whichwill be farther away), to get availability information on.

6.8.6 Movies: RSS feed

The movie section in Nulaz is based on a RSS feed of movies in Ams-terdam. This feed is retrieved and parsed every night, and each movie,its theater, and start time are added to the database. The databasealso has a static list of movie theaters, and their locations. When auser requests movie information for his current location, a list of movietheaters is queried from the database and sorted on distance. Moviesthat haven’t yet started are shown with their theater. The theaters inthe listing are clickable, to be shown in a map. Unfortunately, none ofthe theatres offer online information on the availability of their tickets.

6.8.7 Cultural events: XML files

For the data for the Cultural events, the Dutch Uitbureau supplied anXML export of (parts of) their database. This was the only datasourcewhere the supplier participated in this project, which eased the integra-tion. Otherwise another page ripping tool had to be build. The XMLfiles were transformed into SQL with an XSLT transformation [59].The resulting SQL file was then imported into the Nulaz Database, butlacked geocodes. These were added by creating a script that queried theGoogle geocoder [36] with the address of each venue. When requested,

4In our testing, the mean time per request for the bereikbaar.amsterdam.nl sitewas 1954ms. Response times varied between 1343ms and 5187ms. The median was1578ms. This was measured with Apache Benchmark, requesting a page showingcurrent parking information 100 times.


the locations are sorted on distance from the current location of theuser, merged with the upcoming events at that location, and shown tothe user.

6.8.8 Own data: SQL database

The own data the system generates, such as user places, tracks andpoints, are all saved to the local database. This database is queriedwhen the user wants to see his data. An interesting case is the gener-ation of tracks: While these are shown to the user on the webinterfaceas seen in Figure 6.4 on page 63, the concept of a track doesn’t existin the database. There only is a table of points a user visited, togetherwith a timestamp when the user was there. A track thus needs to com-bine points that are linked in space and time. When a user requests histrack listing, his recent points are queried from the database, and thenparsed and split into tracks based on the time difference between thepoints. When there is more than five minutes between points, a newtrack is made. The same parsing of the points also calculates the time,distance, and average speed for the track. This results in a set of timeperiods. When clicked, the points between these these timestamps areretrieved, linked together, and shown in a map. A track thus is thecollection of points for a user between two points, its start and finish,defined as timestamps.

6.9 Data Conclusion

As the geospatial web evolves, and standards for geographic data ex-change gain traction, it hopefully becomes easier to integrate severaldatasourcesthan it has been for Nulaz. While the rise of web-serviceAPI’s is a great development, the design of a specific solution for eachdatasource is far from ideal. Hopefully, in a not too distant future, therewill be standards in APIs for querying remote systems in both inputand output. In these format wars, GeoRSS and KML show a promis-ing future as output formats. But even if they are in widespread use,these formats only solve half of the equation: for a inter-operable web,there should also be a common standard to interface with the API’s ofdifferent websites, instead of each site inventing it’s own standard.

6.9. Data Conclusion 63

(a) Track listings in the webinterface.

(b) An example track, number 25 in the previous listing.

(c) The same track, seen in 3D in Google Earth.

Figure 6.4: Example Track listing

Chapter 7

Conclusion and futurework

“Any sufficiently advanced technologyis indistinguishable from magic.”

– Arthur C. Clarke

This work has shown that with current technologies it is possible tobuild a working location based system for mobile phones. Such a

system can work in a wide area on many devices. And it can use sourcespublicly available on the Internet to show relevant local information.While many techniques used are still in early development, they aresufficiently developed to work with. Locating people, however, is stillproblematic, and working with location as context still requires a lotof development [84]. Data sources, while usable, still require a lot ofcustom hacking to integrate into projects. In both fields, new standardswill hopefully emerge and gain traction.

7.1 The Next Nulaz

While the current version of Nulaz works, and shows much nice infor-mation, there are still many ideas for a next version. Some of thesevisible, some of them more in the back-end. Parts of the code areunstructured, ad-hoc solutions for the problems ran into while build-ing this first version. For a next version parts of the structure willbe changed to build a more comprehensive and modular system. Forexample, the mobile and web versions have many similar parts of code.The internals will change to a more layered approach: A back-end thatgenerates the data, and several viewers to show the data to the currentinterface.

65

66 Chapter 7. Conclusion and future work

On the client side a more complete client would be a good develop-ment. In the current implementation, most of the location based datais shown in a mobile webinterface. This data can be integrated into theclient, allowing easier updates, better caching for faster response times,and a specialized user interface. For example, in the webclient, updatesbased on movement of the user are not possible. In a specialized clientthis problem could be overcome. Work in this direction has alreadystarted.

For the locating testing and developing a tag-based Bluetooth so-lution is planned. Not to replace the GPS, but as an extra feature.This is aimed at coverage in places where GPS might not be available,and to target a user group without GPS devices. When WiFi phonesbecome more common, WiFi locating could also be a welcome extrafeature. This will lead to a more modular system.

A next version will also have more social functions, with locationbased messages between users, and alerts when friends are in the area.It will furthermore allow people to leave virtual notes on real-life places,open for the public or only specific groups. This will introduce a formof “virtual grafiti”; notes that are attached to a place and can be viewedby users of the system when in that place, but don’t exist in the realworld. New real-world games can arise from these notes.

Where the current version shows almost only external data, a nextversion will also generate its own data besides tracks: Nulaz can bea way to make location based notes, pictures, movies, comments, orother content. With these social features, smarter filtering will have tobe build. Where current queries are mostly based on the location ofthe user, in the future this could include the location of friends, othertypes of context such as the local weather, and other preferences, insuggesting places to go together. A future version will also be a moreopen system, allowing free flows of data to and from the system. Forthis purpose, a next version will offer an API, so users can use Nulaz asa part of their mashups, and integrate their data in their own or publicsystems.

7.2 Further Research

While this thesis has shown that Location Based Systems can be buildwith todays technology, there is still much interesting research to do.We are only just entering an era with ubiquitous computing system,and with these new powers come great responsibilities for the buildersof these systems. Never before in history has technology enabled us to

7.2. Further Research 67

track the daily lives of so many people. While I think (and hope) thesetechnologies bring more good than evil, they do raise new privacy issues.This thesis has had more focus on the technical aspects of showing andrevealing location. But a system that not only works, but also will beused, privacy and the management of it will play an crucial role.

Also in the technology field there is still much work to be done.While new locating techniques have been invented, most of them arestill in the prototype phase, and need a lot of work and research tobecome useful. Even the working techniques, such as GPS have theirdrawbacks in terms of coverage and power requirements. Some tech-niques need easier access and better businessmodels to become viablesolutions. We plan a further research on caracteristics of modern GPSreceivers in daily life. We are also developping a new way to tag placeswith semi-passive Bluetooth tags, to facilitate indoor locating for mo-bile devices.

On the software level there are many limits, differences and quirksthat make systems like J2ME not really live up to the word “Standard”.If these were to disappear, the mobile phone would be a much moreattractive environment to build on. While I have build a fully workingprototype, the user interface and interaction are not much more devel-oped than a mock-up, and need serious work to become a real product.This work has allready started. An interesting road still lies ahead!

68 Chapter 7. Conclusion and future work

Terms

“Everything should be made as simple as possible, but not simpler.”– Albert Einstein

3G Third Generation in mobile technology. 3G systems allow fasterdata speeds than previous generations. UMTS is a 3G technology.

AJAX Asynchronous JavaScript and XML: A technique for interac-tive updating of parts of a website, without reloading the wholepage, leading to a more responsive user experience.

API Application Programming Interface: Interface of a program, to beaccessible to another program. This can be on the same system,or over a network like the Internet.

Bluetooth Standard for short-range (10-100m) wireless communica-tion, included in many phones and computers. Mainly used forpheripials such as headsets, mouses and GPS devices.

EDGE Enhanced Data rates for Gsm Evolution. Extension to GPRSthat allows faster data transfers, up to 236.8 kbit/s. Also called2.75G (opposed to 3G, UMTS).

GPRS General Packet Radio Service: Packet based data networktechnique for GSM networks. Faster and cheaper than GSM datacalls. Allows data speeds up to 60 kbit/s.

GPS Global Positioning System. Satellite based system for worldwidelocating.

GSM Global System for Mobile communication: The largest world-wide standard for cell phones. Also called 2G.

J2ME Java 2 Micro Edition. Stripped down version of the Java plat-form, for use on phones and other small devices. Limited inprocessing power.

69

Javascript Limited scripting languages for use in webpages: The codeis send by the webserver, and executed in the webbrowser. Itforms the J in AJAX.

LBS Location Based System: System uses the location of the user forshowing relevant results.

MAC adress Unique hardware address for (wireless) network devices.

Midlet Java program written in J2ME, for mobile devices supportingthe MIDP.

MIDP Mobile Information Device Profile. Standard for Java pro-grams on mobile devices.

NFC Near Field Communication: enhanced RFID: Where RFID isread-only, NFC can communicate and the tags often contain morememory.

NMEA National Marine Electronics Association. Their standardNMEA 0183 is the most common way of exchanging GPS databetween parts of systems, for example from a Bluetooth GPS toa phone.

Nulaz The system that build for this thesis is called Nulaz.

RFID Radio Frequency ID. A small radio tag that acts as a radiobarcode, and can be read wireless over a small distance (10cm-1m) with a special reader.

SMS Short Message Service. Text message service between mobilephones, with a maximum message length of 160 characters (al-though many phones allow the concatenating of messages).

UMTS Universal Mobile Telecommunications System. A 3G mobilenetwork technique, that allows faster data access rates than pre-vious generations.

WiFi Wireless Fidelity, standard for wireless networking

References

“All of the books in the world contain no more information than isbroadcast as video in a single large American city in a single year.

Not all bits have equal value.”– Carl Sagan

[1] L. Aalto, N. Gthlin, J. Korhonen, and T. Ojala. Bluetooth andWAP push based location-aware mobile advertising system. Pro-ceedings of the 2nd international conference on Mobile systems,applications, and services, pages 49–58, 2004.

[2] G. D. Abowd, C. G. Atkeson, J. Hong, S. Long, R. Kooper, andM. Pinkerton. Cyberguide: A mobile context-aware tour guide.Wireless Networks, 3(5):421–433, 1997.

[3] Tomi T. Ahonen and Alan Moore. Communities dominatebrands: business and marketing challenges for the 21st century.Futuretext, London, 2005.

[4] E. Amitay, N. Har’El, R. Sivan, and A. Soffer. Web-a-where:geotagging web content. Proceedings of the 27th annual interna-tional ACM SIGIR conference on Research and development ininformation retrieval, pages 273–280, 2004.

[5] Gemeente Amsterdam. Bereikbaar Amsterdam - parkeerkans,2007. http://www.bereikbaaramsterdam.nl/live/main.asp?name=pagina&item_id=902.

[6] anyone. Main page - Wikipedia, the free encyclopedia, 2007.http://en.wikipedia.org/wiki/Main_Page.

[7] The Internet Archive. Hyves on the Internet Archive, 2004-2006.http://web.archive.org/web/*/http://www.hyves.nl.

71

http://www.bereikbaaramsterdam.nl/live/main.asp?name=pagina&item_id=902

http://www.bereikbaaramsterdam.nl/live/main.asp?name=pagina&item_id=902

http://en.wikipedia.org/wiki/Main_Page

http://web.archive.org/web/*/http://www.hyves.nl

72 REFERENCES

[8] Michael Arrington. Breaking: Yahoo toshut down yahoo photos in favor of flickr,2007. http://www.techcrunch.com/2007/05/03/breaking-yahoo-to-announce-closure-of-yahoo-photos-tomorrow/.

[9] M. Baldauf, S. Dustdar, and F. Rosenberg. A survey on context-aware systems. International Journal of Ad Hoc and UbiquitousComputing, 1(3), 2006.

[10] S. J. Barnes and S. L. Huff. Rising sun: iMode and the wirelessinternet. Communications of the ACM, 46(11):78–84, 2003.

[11] Douglas W. Bass. RSS, OPML and weblog ecosystems: A surveyof new technologies in internet publication. In Conference onAdvances in Internet Technologies and Applications, 2004.

[12] P. Bellavista, A. Corradi, and C. Stefanelli. The ubiquitous pro-visioning of internet services to portable devices. Pervasive Com-puting, IEEE, 1(3):81–87, 2002.

[13] Mark Bolick. The future of personal computing, 2003.http://www.clubofamsterdam.com/press.asp?contentid=339&catid=85.

[14] G. Borriello, M. Chalmers, A. LaMarca, and P. Nixon. Deliveringreal-world ubiquitous location systems. Communications of theACM, 48(3):36–41, 2005.

[15] G. Buchanan, S. Farrant, M. Jones, H. Thimbleby, G. Marsden,and M. Pazzani. Improving mobile internet usability. Proceedingsof the tenth international conference on World Wide Web, pages673–680, 2001.

[16] D. Butler. The web-wide world. Nature(London), 439(7078):776–778, 2006.

[17] G. Chen and D. Kotz. A survey of context-aware mobile com-puting research. Dartmouth Computer Science Technical ReportTR2000-381, 2000.

[18] Y. C. Cheng, Y. Chawathe, A. LaMarca, and J. Krumm. Accu-racy characterization for metropolitan-scale Wi-Fi localization.Proceedings of MobiSys, 5, 2005.

http://www.techcrunch.com/2007/05/03/breaking-yahoo-to-announce-closure-of-yahoo-photos-tomorrow/

http://www.techcrunch.com/2007/05/03/breaking-yahoo-to-announce-closure-of-yahoo-photos-tomorrow/

http://www.clubofamsterdam.com/press.asp?contentid=339&catid=85

http://www.clubofamsterdam.com/press.asp?contentid=339&catid=85

REFERENCES 73

[19] K. Cheverst, N. Davies, K. Mitchell, and A. Friday. Experiencesof developing and deploying a context-aware tourist guide: theguide project. Proceedings of the 6th annual international con-ference on Mobile computing and networking, pages 20–31, 2000.

[20] Open Geospatial Consortium. Ogc newsletter - jan-uary, 2007. http://www.opengeospatial.org/pressroom/newsletters/200701.

[21] Chetan Sharma Consulting. Global wireless data marketupdate 2006, 2007. http://www.chetansharma.com/Global%20Wireless%20Market%202006%20Update%20April%202007%20-%20Chetan%20Sharma%20Consulting.pdf.

[22] E. Costanza and M. Leinss. Telling a story on a tag: The impor-tance of markers’ visual design for real world applications. Work-shop Mobile Interaction with the Real World (MIRW 2006) inconjunction with 8th International Conference on Human Com-puter Interaction with Mobile Devices and Services (MobileHCI2006), Espoo, Finland, 2006.

[23] A. K. Dey, G. D. Abowd, and P. Steggles. Towards a betterunderstanding of context and context-awareness. 1999.

[24] DomainNameSoup.com. Five letter random pronounceabledomain names, 2007. http://www.domainnamesoup.com/five-letter-random-domain-names.php.

[25] T. Erickson. Some problems with the notion of context-awarecomputing. Communications of the ACM, 45(2):102–104, 2002.

[26] E. Ferro and F. Potorti. Bluetooth and wi-fi wireless protocols: asurvey and a comparison. Wireless Communications, IEEE [seealso IEEE Personal Communications], 12(1):12–26, 2005.

[27] Flickr. Flickr API, 2007. http://www.flickr.com/services/api/.

[28] Flickr. Flickr map, 2007. http://www.flickr.com/map/.

[29] Dan Foster. GPX: the GPS Exchange Format, 2004. http://www.topografix.com/gpx.asp.

[30] Geoffrey A. Fowler. QR codes: In Japan, billboards take code-crazy ads to new heights. Wall Street Journal, 2005.

http://www.opengeospatial.org/pressroom/newsletters/200701

http://www.opengeospatial.org/pressroom/newsletters/200701

http://www.chetansharma.com/Global%20Wireless%20Market%202006%20Update%20April%202007%20-%20Chetan%20Sharma%20Consulting.pdf



http://www.domainnamesoup.com/five-letter-random-domain-names.php

http://www.domainnamesoup.com/five-letter-random-domain-names.php

http://www.flickr.com/services/api/

http://www.flickr.com/services/api/

http://www.flickr.com/map/

http://www.topografix.com/gpx.asp

http://www.topografix.com/gpx.asp

74 REFERENCES

[31] Joel De Gan. Infer latitude and longitude from cell id and thefcc database, 2006. http://blog.peoplesdns.com/index.php?tag=navigation.

[32] GeoRSS. GeoRSS, 2007. http://georss.org/.

[33] S. Golder, D. M. Wilkinson, and B. A. Huberman. Rhythms ofsocial interaction: messaging within a massive online network.Arxiv preprint cs.CY/0611137, 2006.

[34] E. Goodman and A. Moed. Community in mashups: The case ofpersonal geodata. 2006.

[35] Google. Mapping your way, 2005. http://googleblog.blogspot.com/2005/02/mapping-your-way.html.

[36] Google. Google maps API, 2007. http://www.google.com/apis/maps/.

[37] Google. Google milestones, 2007. http://www.google.com/corporate/history.html.

[38] Google. U.s. holocaust memorial museum and google join in on-line darfur mapping initiative, 2007. http://www.google.com/intl/en/press/pressrel/darfur_mapping.html.

[39] Google Keyhole. KML, 2007. http://earth.google.com/kml/.

[40] R. E. Grinter and M. Eldridge. y do tngrs luv 2 txt msg. Proceed-ings of the Seventh European Conference on Computer-SupportedCooperative Work ECSCW, 1:219–238, 2001.

[41] R. E. Grinter and L. Palen. Instant messaging in teen life. Pro-ceedings of the 2002 ACM conference on Computer supported co-operative work, pages 21–30, 2002.

[42] JSR 118 Expert Group. Mobile information device profile for java2 micro edition, 2006. http://jcp.org/en/jsr/detail?id=118.

[43] Network Working Group. Hypertext transfer protocol –HTTP/1.1, 1999. http://www.ietf.org/rfc/rfc2616.txt.

[44] U.S. Coast Guard. Gps frequently asked questions, 2005. http://www.navcen.uscg.gov/faq/gpsfaq.htm.

[45] M. Guy and E. Tonkin. Tidying up tags. D-Lib Magazine,12(1):1082–9873, 2006.

http://blog.peoplesdns.com/index.php?tag=navigation

http://blog.peoplesdns.com/index.php?tag=navigation

http://georss.org/

http://googleblog.blogspot.com/2005/02/mapping-your-way.html

http://googleblog.blogspot.com/2005/02/mapping-your-way.html

http://www.google.com/apis/maps/

http://www.google.com/apis/maps/

http://www.google.com/corporate/history.html

http://www.google.com/corporate/history.html

http://www.google.com/intl/en/press/pressrel/darfur_mapping.html

http://www.google.com/intl/en/press/pressrel/darfur_mapping.html

http://earth.google.com/kml/

http://jcp.org/en/jsr/detail?id=118

http://www.ietf.org/rfc/rfc2616.txt

http://www.navcen.uscg.gov/faq/gpsfaq.htm

http://www.navcen.uscg.gov/faq/gpsfaq.htm

REFERENCES 75

[46] J. Haartsen, M. Naghshineh, J. Inouye, O. J. Joeressen, andW. Allen. Bluetooth: Vision, goals, and architecture. ACM Mo-bile Computing and Communications Review, 2(4):38–45, 1998.

[47] A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster.The anatomy of a context-aware application. Wireless Networks,8(2):187–197, 2002.

[48] Toine van der Heijden. Nokia voorziet 100 miljoen mobielt-jes van maps, 2007. http://www.emerce.nl/nieuws.jsp?id=1995648&WT.mc_id=rss.

[49] J. Hightower and G. Borriello. Location systems for ubiquitouscomputing. Computer, 34(8):57–66, 2001.

[50] J. Hightower, S. Consolvo, A. LaMarca, I. Smith, and J. Hughes.Learning and recognizing the places we go. Proceedings of theSeventh International Conference on Ubiquitous Computing (Ubi-comp 2005), pages 159–176, 2005.

[51] Adrian Holovaty. Chicagocrime, 2005. autor: Adrian Holovaty.http://www.chicagocrime.org/.

[52] R. Hull, P. Neaves, and J. Bedford-Roberts. Towards SituatedComputing. Hewlett-Packard Laboratories, 1997.

[53] Open Geospatial Consortium Inc. and Carl Reed. An introduc-tion to GeoRSS: A standards based approach for geo-enablingRSS feeds. 2006.

[54] A. Jhingran. Enterprise information mashups: integrating infor-mation, simply. Proceedings of the 32nd international conferenceon Very large data bases, pages 3–4, 2006.

[55] M. Jones and G. Marsden. Mobile Interaction Design. John Wiley& Sons, 2006.

[56] Steve Jones. The internet goes to college. Pew Internet & Amer-ican Life, 15, 2002.

[57] R. Jos and N. Davies. Scalable and flexible location-based ser-vices for ubiquitous information access. Proceedings of the FirstInternational Symposium on Handheld and Ubiquitous Comput-ing, page 5266, 1999.

[58] E. Kaasinen. User needs for location-aware mobile services. Per-sonal and Ubiquitous Computing, 7(1):70–79, 2003.

http://www.emerce.nl/nieuws.jsp?id=1995648&WT.mc_id=rss

http://www.emerce.nl/nieuws.jsp?id=1995648&WT.mc_id=rss

http://www.chicagocrime.org/

76 REFERENCES

[59] Robbert Kauffman. XML-SQL, 2007. http://www.strengers.nl/~jh/bekijkhetmaar/pmwiki.php?n=Main.XML-SQL.

[60] A. Khalil and K. Connelly. Context-aware telephony: privacypreferences and sharing patterns. Proceedings of the 2006 20thanniversary conference on Computer supported cooperative work,pages 469–478, 2006.

[61] M. Kim, J. J. Fielding, and D. Kotz. Risks of using ap locationsdiscovered through war driving. Proceedings of The 4th Interna-tional Conference on Pervasive Computing (Pervasive 2006) pp,pages 67–82, 2006.

[62] O. Kolsi and T. Virtanen. Midp 2.0 security enhancements. Sys-tem Sciences, 2004. Proceedings of the 37th Annual Hawaii In-ternational Conference on, pages 287–294, 2004.

[63] Arjen Kruithof. Treinvizier, 2006. http://www.treinvizier.nl/.

[64] A. LaMarca, Y. Chawathe, S. Consolvo, J. Hightower, I. Smith,J. Scott, T. Sohn, J. Howard, J. Hughes, and F. Potter. Place lab:Device positioning using radio beacons in the wild. Proceedingsof Pervasive, 2005.

[65] A. LaMarca, Y. Chawathe, and I. Smith. Finding yourself. Spec-trum, IEEE, 41(12):51–54, 2004.

[66] A. LaMarca, J. Hightower, I. Smith, and S. Consolvo. Self-mapping in 802.11 location systems. Proceedings of the Sev-enth International Conference on Ubiquitous Computing (Ubi-comp 2005), page 87104, 2005.

[67] J. Lewis. Bluetooth security. 2005.

[68] K. Lorincz and M. Welsh. Motetrack: A robust, decentralizedapproach to rf-based location tracking. Proceedings of Intl. Work-shop on Location and Context-Awareness, 2005.

[69] Yahoo! Maps Web Services. Yahoo! Maps GeoRSS, 2007. http://developer.yahoo.com/maps/georss/index.html.

[70] Mikel Maron. GeoRSS. In Where 2.0 2006, 2006.

[71] Mikel Maron. GeoRSS : Geographically Encoded Objects forRSS Feeds, 2006. http://xtech06.usefulinc.com/schedule/paper/56.

http://www.strengers.nl/~jh/bekijkhetmaar/pmwiki.php?n=Main.XML-SQL

http://www.strengers.nl/~jh/bekijkhetmaar/pmwiki.php?n=Main.XML-SQL

http://www.treinvizier.nl/

http://www.treinvizier.nl/

http://developer.yahoo.com/maps/georss/index.html

http://developer.yahoo.com/maps/georss/index.html

http://xtech06.usefulinc.com/schedule/paper/56

http://xtech06.usefulinc.com/schedule/paper/56

REFERENCES 77

[72] Bad Math. The beer hunter, 2005. http://www.beerhunter.ca/.

[73] mr. J. Mendlik. Kranten.com-zaak, 2000. http://www.ivir.nl/rechtspraak/kranten.com.html.

[74] G. E. Moore. Cramming more components onto integrated cir-cuits, 1965. http://download.intel.com/research/silicon/moorespaper.pdf.

[75] David Mountain and Jonathan Raper. Positioning techniques forlocation-based services (lbs): characteristics and limitations ofproposed solutions. Aslib Proceedings, 53(10):404, 2001.

[76] J. Munnelly. Context Awareness in Mobile Phone Based Appli-cations Using Bluetooth. PhD thesis, 2005.

[77] Museumnacht. Museumnacht mobiel, 2006. http://www.n8.nl/2006/mobiel.

[78] mySociety.org. Placeopedia API, 2007. http://www.placeopedia.com/data/.

[79] Nokia. It’s what computers have become - the new nokia N95,2006. http://www.nokia.com/A4136002?newsid=1077775.

[80] G. M. P. O’Hare and M. J. O’Grady. Gulliver’s genie: a multi-agent system for ubiquitous and intelligent content delivery. Com-puter Communications, 26(11):1177–1187, 2003.

[81] O. Orajrvi. Context aware computing. 2006.

[82] C. Enrique Ortiz. The generic connection framework,2003. http://developers.sun.com/techtopics/mobility/midp/articles/genericframework/index.html.

[83] V. Otsason, A. Varshavsky, A. LaMarca, and E. de Lara. Accu-rate gsm indoor localization. the Seventh International Confer-ence on Ubiquitous Computing (UbiComp 2005), 2005.

[84] J. Pascoe, N. Ryan, and D. Morse. Issues in developing context-aware computing. Proceedings of the 1st international symposiumon Handheld and Ubiquitous Computing, pages 208–221, 1999.

[85] Dana Peters. GPS Track, 2006. http://qcontinuum.org/gpstrack/.

http://www.beerhunter.ca/

http://www.beerhunter.ca/

http://www.ivir.nl/rechtspraak/kranten.com.html

http://www.ivir.nl/rechtspraak/kranten.com.html

http://download.intel.com/research/silicon/moorespaper.pdf

http://download.intel.com/research/silicon/moorespaper.pdf

http://www.n8.nl/2006/mobiel

http://www.n8.nl/2006/mobiel

http://www.placeopedia.com/data/

http://www.placeopedia.com/data/

http://www.nokia.com/A4136002?newsid=1077775

http://developers.sun.com/techtopics/mobility/midp/articles/genericframework/index.html

http://developers.sun.com/techtopics/mobility/midp/articles/genericframework/index.html

http://qcontinuum.org/gpstrack/

http://qcontinuum.org/gpstrack/

78 REFERENCES

[86] Frederic Poirot. ...or another..., 2006. http://www.flickr.com/photos/fredarmitage/281476560/.

[87] Morgan Quinto Press. America’s most unsafe cities, 2006. http://www.mibazaar.com/unsafecities/.

[88] Java Community Process. Jsr-000082 java apis for bluetooth,2002.

[89] ProgrammableWeb.com. Api dashboard, 2007. http://www.programmableweb.com/apis.

[90] M. Raento, A. Oulasvirta, R. Petit, and H. Toivonen. Context-phone: a prototyping platform for context-aware mobile applica-tions. IEEE Pervasive Computing, 4(2):51–59, 2005.

[91] C. Randell and H. Muller. Context awareness by analysing ac-celerometer data. The Fourth International Symposium on Wear-able Computers, 1(1):175–176, 2000.

[92] J. H. Ratcliffe. On the accuracy of tiger-type geocoded addressdata in relation to cadastral and census areal units. Interna-tional Journal of Geographical Information Science, 15(5):473–485, 2001.

[93] E. Reid. Electropolis: Communication and community on inter-net relay chat. University of Melbourne, 1991.

[94] J. Rekimoto and Y. Ayatsuka. Cybercode: designing augmentedreality environments with visual tags. Proceedings of DARE 2000on Designing augmented reality environments, pages 1–10, 2000.

[95] R. Rettie. M-commerce: the role of SMS text messages. 2001.

[96] C. Rizos. Trends in geopositioning for LBS, navigation and map-ping. Proceedings of Int. Symp. & Exhibition on Geoinformation,pages 27–29, 2005.

[97] M. Rohs. Linking physical and virtual worlds with visual markersand handheld devices. PhD thesis, 2005.

[98] M. Rohs and B. Gfeller. Using camera-equipped mobile phonesfor interacting with real-world objects. Advances in PervasiveComputing, page 265271, 2004.

[99] Andrew Rowbottom. Debug maps. http://www.ponies.me.uk/maps/dbgmap.html.

http://www.flickr.com/photos/fredarmitage/281476560/

http://www.flickr.com/photos/fredarmitage/281476560/

http://www.mibazaar.com/unsafecities/

http://www.mibazaar.com/unsafecities/

http://www.programmableweb.com/apis

http://www.programmableweb.com/apis

http://www.ponies.me.uk/maps/dbgmap.html

http://www.ponies.me.uk/maps/dbgmap.html

REFERENCES 79

[100] E. Rukzio. Physical Mobile Interactions: Mobile Devices as Per-vasive Mediators for Interactions with the Real World. PhD the-sis, PhD thesis. 2006, 2006.

[101] B. N. Schilit, N. Adams, and R. Want. Context-aware computingapplications. 1994.

[102] Adena Schutzberg. Google KML search: What does it meanfor geospatial professionals?, 2007. http://www.directionsmag.com/article.php?article_id=2409&trv=1.

[103] Bernhard Seefeld. Keynote google geo developer day, 2007. Notyet published.

[104] Semacode. Semacode, 2007. http://semacode.org/.

[105] Semapedia. Semapedia, 2007. http://www.semapedia.org/.

[106] Y. Shafranovich. Rfc 4180: Common format and mime typefor comma-separated values (csv) files, 2005. http://rfc.net/rfc4180.html.

[107] ShockFire. Kmlimporter, 2007. http://www.worldwindcentral.com/wiki/Add-on:KMLImporter.

[108] R. Singh. Geoblogging: collaborative, peer-to-peer geographicinformation sharing. Annual Conference, 2004.

[109] I. Smith. Social-mobile applications. Computer, 38(4):84–85,2005.

[110] Windows Live Spaces. New version of live search mapslaunches!, 2007. http://virtualearth.spaces.live.com/blog/cns!2BBC66E99FDCDB98!8495.entry.

[111] Nigel Tao. KML and GeoRSS Support Added to the GoogleMaps API, 2007. http://googlemapsapi.blogspot.com/2007/03/kml-and-georss-support-added-to-google.html.

[112] Carlo Torniai, Steve Battle, and Steve Cayzer. Sharing, discov-ering and browsing geotagged pictures on the web. 2007.

[113] F. Trosby. SMS, the strange duckling of GSM. Telektronikk,100(3):187–194, 2004.

[114] R. G. Utting, C. Rudolph, and L. Girardeau. Extended rangeTDMA system, 1997.

http://www.directionsmag.com/article.php?article_id=2409&trv=1

http://www.directionsmag.com/article.php?article_id=2409&trv=1

http://semacode.org/

http://www.semapedia.org/

http://rfc.net/rfc4180.html

http://rfc.net/rfc4180.html

http://www.worldwindcentral.com/wiki/Add-on:KMLImporter

http://www.worldwindcentral.com/wiki/Add-on:KMLImporter

http://virtualearth.spaces.live.com/blog/cns!2BBC66E99FDCDB98!8495.entry

http://virtualearth.spaces.live.com/blog/cns!2BBC66E99FDCDB98!8495.entry

http://googlemapsapi.blogspot.com/2007/03/kml-and-georss-support-added-to-google.html

http://googlemapsapi.blogspot.com/2007/03/kml-and-georss-support-added-to-google.html

80 REFERENCES

[115] A. Varshavsky, M. Y. Chen, E. de Lara, J. Froehlich, D. Haehnel,J. Hightower, A. LaMarca, F. Potter, T. Sohn, and K. Tang.Are GSM phones THE solution for localization? Proceedings ofthe Seventh IEEE Workshop on Mobile Computing Systems &Applications, pages 20–28, 2006.

[116] R. Want, A. Hopper, V. Falco, and J. Gibbons. The activebadge location system. ACM Transactions on Information Sys-tems (TOIS), 10(1):91–102, 1992.

[117] M. Weiser. The computer for the 21st century. Scientific Amer-ican, 265(3):66–75, 1991.

[118] E. Welbourne, J. Lester, A. LaMarca, and G. Borriello. Mobilecontext inference using low-cost sensors. Proceedings of the Inter-national Workshop on Location-and Conext-Awareness (LoCA),page 254263, 2004.

[119] Wikipedia. Wikipedia statistics, 2007. http://en.wikipedia.org/wiki/Special:Statistics.

[120] Wikipedia. Wikipedia:wikiprojekt georeferenzierung/wikipedia-world/en, 2007. http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en.

[121] Wikipedia. Wikiproject geographical coordinates, 2007.http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates.

[122] M. Winget. User-defined classification on the online photo shar-ing site Flickr... or, how i learned to stop worrying and love themillion typing monkeys. 17th SIG/CR Classification ResearchWorkshop, November 4, 2006, 2006.

[123] Yahoo! Yahoo Maps API, 2007. http://developer.yahoo.com/maps/.

[124] P. Zweifel and M. Rohs. A conceptual framework for cameraphone-based interaction techniques. Proc. of PERVASIVE 2005,2005.

http://en.wikipedia.org/wiki/Special:Statistics

http://en.wikipedia.org/wiki/Special:Statistics

http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en

http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en

http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates

http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates

http://developer.yahoo.com/maps/

http://developer.yahoo.com/maps/

i’m bored! where is everybody? - martijn pannevis · “there is no such thing as a virtual...

Documents