HELSINKI UNIVERSITY OF TECHNOLOGY Department of ...

HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering

Mari Korkea-aho Location Information in the Internet

Licentiate’s thesis submitted in partial fulfillment of the requirements for the degree of Licentiate of Science in Technology

Supervisor: Professor Reijo Sulonen Instructor:

Helsinki 8.10.2001

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF LICENTIATE’S THESIS

Author: Mari Korkea-aho

Title: Location Information in the Internet

Date: 8.10.2001 Number of pages: 80

Department: Department of Computer Science and Engineering

Professorship: Tik-76 Information Processing Science

Supervisor: Professor Reijo Sulonen

Instructor:

Currently many organizations are specifying different location information formats and ways of providing location information to applications in the Internet. Such organizations are e.g. Internet Engineering Task Force (IETF), Open GIS Consortium (OGC), Third Generation Partnership project (3GPP), Location Inter-operability Forum (LIF), Wireless Application Protocol Forum (WAP Forum), and World Wide Web Consortium (W3C). Each of them basically specifies a way of their own of expressing and providing location information. This causes a serious problem. It will be difficult for applications in the Internet to use different location information sources, and the location information provided to applications might have different incompatible formats.

The objective of this work is to address this problem and propose some solutions for achieving interoperability. Interoperability can be reached on the level of a common way of expressing location information and on the level of a common way of obtaining location information. This work focuses on a common way of expressing location information, since this appears to be the easiest level to reach interoperability on.

This work introduces a common location data set that can be used by applications to enable interoperability. Because of the numerous ways of expressing location information and the different location information needs of applications, it will not be enough to provide and support only one common location data set. A common way of expressing different location data sets is also needed. Some initial suggestions for the common way of expressing different location data sets is made, including a common structure and way of encoding, naming, and registering different location data sets. The location applications might need to use several location data sets, or to express the location in different ways. For this the common location payload, a container for different location data sets and associated data was designed.

In the work it is proposed to encode the common location data set, the common way of expressing location information, and the location payload in Extensible Markup Language (XML). XML enables use of standard processing tools and provides easy methods for extending location data sets. In addition, many of the existing location expressions use XML.

In order to reach location information interoperability in the Internet in the future, cooperation between different location standardization activities will be essential, as well as having one leading standardization activity to steer the work. The Internet Engineering Task Force (IETF) should preferably lead this activity, since it is the most important standardization organization for the Internet.

The formats and syntaxes presented in this thesis are proposals, and should be improved through input from the location technology community and different standardization organizations.

Keywords: Location information, positioning, interoperability, Internet, standardization

TEKNILLINEN KORKEAKOULU LISENTIAATINTYÖN TIIVISTELMÄ

Tekijä: Mari Korkea-aho

Työn nimi: Paikkatieto Internetissä

Päivämäärä: 8.10.2001 Sivumäärä: 80

Osasto: Tietotekniikan osasto

Professuuri: Tik-76 Tietojenkäsittelyoppi

Työn valvoja: Professori Reijo Sulonen

Työn ohjaaja:

Tällä hetkellä monet organisaatiot määrittelevät erilaisia paikkatiedon esitysmuotoja ja tapoja joilla toimittaa paikkatietoa Internet-sovelluksille. Tällaisia organisaatioita ovat esimerkiksi Internet Engineering Task Force (IETF), Open GIS Consortium (OGC), Third Generation Partnership project (3GPP), Location Inter-operability Forum (LIF), Wireless Application Protocol Forum (WAP Forum), ja World Wide Web Consortium (W3C). Perimmiltään jokainen näistä organisaatioista määrittelee oman tapansa ilmaista ja toimittaa paikkatietoa. Tämä aiheuttaa vakavan ongelman. Internet-sovellusten voi olla vaikeata käyttää eri paikkatietolähteitä ja sovelluksille toimitettu paikkatieto voi olla yhteensopimatonta.

Tämän työn tavoitteena on käsitellä tätä ongelmaa ja ehdottaa joitakin ratkaisuja yhteensopivuuden saavuttamiseksi. Yhteensopivuus voidaan saavuttaa eri tasoilla: yhteisellä tavalla ilmaista paikkatietoa ja yhteisellä tavalla toimittaa paikkatietoa. Työssä keskitytään yhteiseen tapaan ilmaista paikkatietoa, koska tällä tasolla vaikuttaa olevan helpointa saavuttaa yhteensopivuus.

Tässä työssä ehdotetaan yhteistä paikkatietoa kuvaavaa tietojoukkoa, jota käyttäen eri sovellukset voivat saavuttaa yhteensopivuuden. Koska on olemassa lukemattomia tapoja esittää paikkatietoa ja sovellukset tarvitsevat erilaista paikkatietoa, yksi yhteinen paikkatieto-esitysjoukko ei ole riittävä. Tarvitaan myös yhteinen tapa ilmaista erilaisia paikkatietojoukkoja. Työssä tehdään joitakin alustavia ehdotuksia yhteiselle tavalle esittää erilaisia paikkatietojoukkoja. Työssä käsitellään yhteistä rakennetta ja koodaus-, nimitys- ja rekisteröintitapaa joukoille. Joskus sovellukset voivat tarvita monta eri paikkatietojoukkoa ilmaistakseen paikan, tai niiden tarvitsee ilmaista määrätty paikka eri tavoin samalla kertaa. Tätä varten luotiin yhteinen paikkatietopaketti (payload). Se on eräänlainen säiliö eri paikkatietojoukoille ja niihin liittyvälle tiedolle.

Työssä ehdotetaan että yhteinen paikkatietojoukko, yhteinen tapa esittää eri paikkatietojoukkoja, ja paikkatietopaketti ilmaistaisiin XML-kielellä (Extensible Markup Language). XML mahdollistaa standardi työkalujen käytön ja tarjoaa joustavat mahdollisuudet laajentaa paikkatietojoukkoja. Lisäksi monet nykyiset paikkatiedon esitysmuodot käyttävät XML-kieltä.

Paikkatiedon yhteensopivuuden saavuttamiseksi tulevaisuudessa Internetissä tarvitaan yhteistyötä paikkatietoa koskevien standardointihankkeiden välillä. Sen lisäksi tarvitaan yksi johtava standardointihanke ohjaamaan työtä. Hanke tulisi mieluiten olla Internet Engineering Task Forcen (IETF:n) johtama, sillä tämä on Internetin kehitystä johtava standardointiorganisaatio.

Tässä työssä esitetyt ilmaisutavat ja syntaksit ovat ehdotuksia, ja niitä tulisi parantaa paikkatietoyhteisön ja eri standardointiorganisaatioiden palautteen perusteella.

Avainsanat: paikkatieto, paikannus, yhteensopivuus, Internet, standardointi

Location Information in the Internet

Mari Korkea-aho Helsinki University of Technology Licentiate’s Thesis

PREFACE i


PREFACE

This thesis is based on work conducted at Nokia Research Center in several

location-related activities1 during the period of May 1998 – May 2001. It

summarizes ideas and solutions on how location information should be handled

in the Internet.

1 In Spring 2000 the IETF Spatial Location Protocol (SLoP) activity [SLo00b] was initiated,

where the author was one of the initiators. The goal of the activity was to enable a common

standard way for obtaining location information in the Internet. The author has also participated

in location standardization activities related to the Wireless Access Protocol Forum (WAP

Forum), World Wide Web Consortium (W3C), and Location Inter-operability Forum (LIF).

ACKNOWLEDGEMENTS ii


ACKNOWLEDGEMENTS

There are numerous persons who have directly or indirectly helped me with this

work. I won’t be able to mention you all here by name, but I would like you to

know that I'm immensely grateful for your help. Without your support and

valuable comments this thesis would never have been completed. Thank you!

Especially, my gratitude goes to my colleague Dr. Haitao Tang for good

cooperation, support, and all the inspiring discussions. With Haitao’s assistance

I learnt what research is all about. I’m also grateful to my supervisor Professor

Reijo “Shosta” Sulonen at the Helsinki University of Technology for his support

and comments.

Then I would like to thank the members of the Electronic Commerce group at

Nokia Research Center. It was very nice working with you. I would also like to

thank R&D Manager Petteri Saarinen for giving me the opportunity to work on

location technologies and services. The “location guys” Arto Mattila, Frank

Zillikens, and Tommi Ojala also need to be mentioned – thanks for good

cooperation. There are many other colleagues at Nokia that have been of

tremendous value to me in many different ways. To list you all is impossible.

Thank you everybody!

There are also many other colleagues that I owe my gratitude to. This

includes my earlier colleagues from the OtaOnline team (especially Marko

Turpeinen, Tuomas Puskala, and Janne Saarela), who got me interested in

research in the first place, and the people from the IETF SLoP team (especially

Dr. Kenji Takahashi (NTT), and James Polk (Cisco)), who were great sources of

knowledge and comments.

Last, but not least, I would like to thank my family and friends for their

invaluable support.

And finally we are at the end, and …

the end is the beginning of something new.

Helsinki, 8.10.2001,

Mari Korkea-aho

ACRONYMS AND ABBREVIATIONS iii


ACRONYMS AND ABBREVIATIONS

3GPP Third Generation Partnership Project

ABNF Augmented Backus-Naur Form

AFLT Advanced Forward Link Trilateration

API Application Program Interface

BS Base Station

CDMA Code Division Multiple Access

CI Cell Identity

DoD U. S. Department of Defense

DTD Document Type Definition

ECEF Earth Centered-Earth Fixed coordinate system

E-OTD Enhanced Observed Time Difference

ETSI European Telecommunications Standards Institute

FCC Federal Communications Commission

GIS Geographic Information System

GLONASS GLObal Navigation Satellite System

GML Geography Markup Language

GMLC Gateway Mobile Location Center

GPS Global Positioning System

GSM Global System for Mobile communications

GTD Geometric Time Difference

G-XML Geospatial-eXtensible Markup Language

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

ID Identifier

IESG Internet Engineering Steering Group

IETF Internet Engineering Task Force

IP Internet Protocol

ISO International Organization for Standardization

LIF Location Inter-operability Forum

LMU Location Measurement Unit

MIME Multipurpose Internet Mail Extensions

MOSTEC Mobile Information Standard TEchnical Committee

ACRONYMS AND ABBREVIATIONS iv


MS Mobile Station

NMEA National Marine Electronics Association

NVML NaVigation Markup Language

OTD Observed Time Difference

OGC Open GIS Consortium

OTDOA-IPDL Observed Time Difference Of Arrival-Idle Period DownLink

POIX Point Of Interest eXchange Language

RDF Resource Description Framework

RFC Request For Comments

RTD Real Time Difference

SIM Subscriber Identity Module

SLo Spatial Location

SLoP Spatial Location Protocol

SSL Secure Sockets Layer

TA Timing Advance

TDOA Time Difference of Arrival

TDMA Time Division Multiple Access

TOA Time Of Arrival

UAProf User Agent Profile

UL-TOA UpLink Time Of Arrival

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

URL Uniform Resource Locator

UTM Universal Transverse Mercator

W3C World Wide Web Consortium

W5C W5 Consortium

WAP Wireless Application Protocol

WGS-84 World Geodetic Reference System of 1984

WLIA Wireless Location Industry Association

XML Extensible Markup Language

TABLE OF CONTENTS v


TABLE OF CONTENTS

Part 1: Background 1. Introduction ..................................................................................................1

1.1 Objective and Scope ..............................................................................2

1.2 Organization of this Thesis.....................................................................2

2. What is Location Information?......................................................................5

2.1 Location .................................................................................................5

2.1.1 Absolute Spatial Location ................................................................6

2.1.1.1 Geodetic Datums ......................................................................6

2.1.1.2 Coordinate Systems..................................................................7

2.1.2 Descriptive Location ......................................................................10

2.1.3 Transformations.............................................................................11

2.2 Other Related Data ..............................................................................11

3. Positioning Methods for Determining the Location.....................................12

3.1 Satellite Navigation Systems................................................................12

3.2 Positioning in Mobile Networks ............................................................13

3.2.1 Positioning Methods for GSM........................................................14

3.2.1.1 Cell Identity and Timing Advance............................................14

3.2.1.2 UpLink Time of Arrival.............................................................15

3.2.1.3 Enhanced Observed Time Difference (E-OTD).......................16

3.2.1.4 Assisted GPS..........................................................................17

3.2.2 Positioning Methods in UMTS .......................................................17

3.2.3 Other Positioning Methods ............................................................18

3.3 Local Positioning Systems ...................................................................18

3.4 Configuration and Manual Input upon Request....................................18

3.5 Summary of Positioning Methods.........................................................18

4. Applications Using Location Information ....................................................20

4.1 Different Types of Applications.............................................................21

4.2 Service Initiation...................................................................................21

4.3 Providing Location Information to the Applications...............................22

4.4 Requirements on the Location Information ..........................................23

5. Interfaces for Providing Location Information.............................................24

6. Standardization Activities ...........................................................................25

6.1 ETSI and 3GPP....................................................................................26

6.2 LIF........................................................................................................26

TABLE OF CONTENTS vi


6.3 WAP Forum .........................................................................................27

6.4 W3C.....................................................................................................28

6.5 IETF .....................................................................................................28

6.6 Open GIS Consortium..........................................................................29

6.7 ISO/TC211 ...........................................................................................30

6.8 Bluetooth..............................................................................................30

6.9 Others ..................................................................................................31

6.10 Summary of the Different Standardization Activities .........................31

7. Existing Location Information Expressions.................................................32

7.1 Analysis of Location Expressions.........................................................34

7.1.1 Types of Information......................................................................34

7.1.2 Encoding........................................................................................35

8. Challenges of the Current Situation ...........................................................35

Part 2: A Common Way of Expressing and Obtaining Location Information

in the Internet 9. A Common Way of Expressing and Obtaining Location Info......................39

9.1 Initial Ideas for Providing Location Information to Applications ............39

9.2 Two Levels of Interoperability ..............................................................40

9.2.1 A Common Way of Expressing Location Information ....................40

9.2.2 A Common Way of Obtaining Location Information.......................41

9.2.3 Summary .......................................................................................43

10. A Common Way of Expressing Location Information ..............................43

11. A Common Location Data Set.................................................................44

11.1 Design Requirements .......................................................................45

11.2 Location Information Required by Services ......................................45

11.2.1 Absolute Spatial and Descriptive Location .................................46

11.2.2 Size and Shape of Positioned Object .........................................46

11.2.3 Other Information .......................................................................47

11.3 The Elements of the Common Spatial Location Data Set .................47

11.4 Syntax of the Elements in the Common Spatial Location Data Set ..49

11.5 Encoding of the Data Elements ........................................................51

11.5.1 Comparing Encoding Methods ...................................................51

11.5.2 Encoding with XML.....................................................................52

11.5.3 Comments on the Use of XML ...................................................52

TABLE OF CONTENTS vii


11.5.3.1 XML DTD for the Common Spatial Location Data Set ............53

11.5.3.2 XML Schema for the Common Spatial Location Data Set ......53

11.5.4 XML Examples of the Common Spatial Location Data Set ........55

12. A Common Way of Expressing Location Data Sets ................................56

12.1 Common Structure and Encoding.....................................................56

12.2 Common Naming and Registering....................................................57

12.3 Possible Additional Data to Enable Processing ................................57

12.4 XML as a Common Way of Coding Location Data Sets....................58

12.4.1 Example of a Common Way of Expressing Location Data Sets.58

12.5 Extendibility of Data Sets Encoded in XML.......................................59

12.5.1 Extendibility with XML Schema ..................................................59

12.5.2 Example of Extending the Common Spatial Location Data Set..61

12.5.3 Summary on Extendibility...........................................................62

13. A Common Location Payload..................................................................63

13.1 The Elements and Structure of the Location Payload.......................63

13.2 Encoding of the Location Payload ....................................................64

13.2.1 DTD-Based Solution...................................................................65

13.2.2 XML Schema-Based Solution ....................................................66

14. Other Issues Related to Location Information .........................................67

15. Conclusion and Future Work...................................................................68

16. References..............................................................................................70

APPENDIX A - LIST OF PUBLICATIONS.........................................................80

1. Introduction 1


1. INTRODUCTION

Due to the increasing availability of positioning technologies for determining

the physical location of objects and persons, the interest in different kinds of

services that make use of location information has grown rapidly. One factor

furthering this development is the E-911 mandate in the US, stating that from

October 2001 mobile phone subscribers calling the emergency number must be

locatable. This has led to the development of positioning methods in the mobile

networks. Another reason for the increasing interest is the large potential

identified for services providing or using location information. It will be possible

to create many new types of services, leading to new potential sources of

revenue, and new possibilities of attracting and retaining customers.

The increasing availability of location information has awakened the

opportunity for many new services also in the Internet, e.g. in the areas of

tracking, local information, guidance and navigation, access authorization,

resource announcement and discovery, billing, and network management. In

order to work, the location information of the object or person being positioned

needs to be provided to the service application.

Currently several organizations, standardization bodies, industry consortiums

and vendors are working on location-related technologies, and on how to

express and provide location information to applications in the Internet. Such

organizations are e.g. Internet Engineering Task Force (IETF), Open GIS

Consortium (OGC), Third Generation Partnership project (3GPP), Location

Inter-operability Forum (LIF), Wireless Application Protocol Forum (WAP

Forum), and World Wide Web Consortium (W3C). The reason for many

different activities is that the different organizations are working on these

matters from the perspective of their field of technology and their specific needs.

Another reason is that everybody wants to cover the field, because of the large

potential identified for services providing or using location information.

Each of the different activities basically specifies a way of its own of providing

and expressing location information to applications in the Internet. This creates

a serious disadvantage. The location information provided to the applications

might have different incompatible formats, and there might be different

1. Introduction 2


incompatible ways for applications to obtain location information from different

location information sources. This means that the various location information

formats, sources, and applications will not be interoperable in the Internet.

1.1 Objective and Scope

The objective of this work is to address the current situation of interoperability

of location information in the Internet, and propose how the problem can be

overcome by providing common ways of expressing and obtaining location

information to applications in the Internet.

The main focus will be on interoperability through a common way of expressing

location information, and on different ways of tackling this. A common way of

expressing location information appears to be the first thing to tackle, since it

enables interoperability independently of used transfer method, and it is the

easiest level to deploy by different standardization activities. The issues of a

common way of obtaining location information to applications in the Internet will

be only briefly addressed.

The work summarizes ideas gathered in several location-related activities at

Nokia Research Center during the period of May 1998 – May 2001. The author

was among the initiators of the Internet Engineering Task Force (IETF) Spatial

Location Protocol (SLoP) activity in January 2000. The goal of the activity was

to enable a common standard way for obtaining location information in the

Internet. The ideas described in this thesis are mainly outcomes and results of

this activity. The author has also participated in location standardization

activities related to the WAP Forum, W3C, and Location Inter-operability Forum

(LIF).

1.2 Organization of this Thesis

This thesis is divided into two parts. Part 1 gives background information

about what location information is, how it can be expressed, how the location of

an object can be determined, how the location information can be obtained and

transferred to applications in the Internet, what kind of requirements the

applications have on the location information, and what the current situation is

regarding different location expression, interface and transfer standardization

activities.

1. Introduction 3


Chapter 2 explains what location information is and gives an introduction to

the numerous ways location can be expressed in. In Chapter 3 different

methods for positioning objects are presented. Chapter 4 presents different

types of applications needing location information, how the location information

can be provided to them, and their requirements on the location information.

Chapter 5 introduces some possible interfaces for obtaining the location

information. Then different existing location information standardization

activities somehow relating to the Internet are presented in Chapter 6. After this

existing or proposed location information expressions are introduced and

analyzed in Chapter 7. Part 1 is concluded in Chapter 8 with a summary of the

current challenges caused by the different ways of expressing and providing

location information to applications in the Internet.

In Part 2 solutions for enabling interoperability are discussed. In Chapter 9

different ideas related to reaching interoperability by common ways of

expressing and obtaining location information are introduced. Chapter 10 deals

with the common way of expressing location information in the Internet,

presenting three different solution approaches: a common data set, a common

way of expressing different location data sets, and a common payload for

transporting location information. The approaches are then discussed in more

detail in the subsequent chapters. The common location data set is discussed in

Chapter 11. The requirements for such a set are presented and location data

elements needed by different applications are analyzed. After this a common

location data set is proposed. This includes the elements of the location data

set, their syntax, and encoding. Chapter 12 considers a common way of

expressing different location data sets and the requirements of such a concept,

including the naming, encoding and extendibility of data sets. In Chapter 13 the

common location payload for transferring location data sets is presented. In

Chapter 14 other important issues related to location information, including

privacy, security, billing and transformation of location information are briefly

addressed. In Chapter 15 the work is concluded and future work items

presented.

4


Part 1: Background

2. What is Location Information? 5


2. WHAT IS LOCATION INFORMATION?

A location expresses where an object is situated. The location of an object

can be expressed in many different ways. For example, the physical location of

a house can be indicated with a street address. The virtual location of a

computer in an Internet Protocol (IP)-network can be expressed by the IP-

address. This thesis focuses on expressions defining the physical location of an

object in the real world, as for example the street address above does. The

object can be a moving or stationary item, such as a person, car, dog, PC, etc.

The focus in this work is on physical objects of minor size (approx. <10 m),

whose location can be expressed as a point, independently of the object’s form

or size. This type of location will simply be called location in this work.

Sometimes the term spatial location is used to emphasize that the location is

expressed using the earth as reference frame. That is, the location is expressed

in relation to the earth.

Location information can be more than just the data expressing the location

of an object. It can also include other additional information that can be

necessary for using the location data, for improving the location measurement,

or for bringing additional value to the location data. Such information is e.g. the

velocity of the positioned object, the direction the object is moving in, the

orientation of the object, etc. The way of expressing the location information

reflects the needs of the applications it was planned for.

2.1 Location

A location is a place where an object is physically situated in the real world.

The location can be expressed in different ways using different reference

frames. It can be expressed, e.g. as absolute spatial location, descriptive

location, or relative location.

The different ways of expressing location will pinpoint the location of the

object to a certain point, area or region somewhere on or close to the earth. The

accuracy will depend on the way of expressing the location. Very often the

positioned object is considered to be a point, independently of its form or size.

This kind of location is the focus of this work. Location information is quite

challenging since a location can be expressed in so many different ways,



depending on the context of use and the needs of the application using the

information.

2.1.1 Absolute Spatial Location

Absolute spatial location is the location of a physical object in the world,

expressed via a 2- or 3-dimensional coordinate system in a particular spatial

reference system2. With the help of the coordinate system a specific spatial

location is converted into a set of two or three numbers, such as an x- and y-

value (and possibly a z-value). The spatial reference system expresses a 2- or

3-dimensional model of the earth and determines how the used coordinate

system is attached to the model.

2.1.1.1 Geodetic Datums

In the spatial reference system, the geodetic datum defines the size and

shape of the earth, and the origin and orientation of the coordinate system. The

shape of the earth and its surface is irregular and the different datums attempt

to model it. Since the datums describe the earth differently, the used datum will

affect e.g. how accurately one can express the position of an object, or how

exact the distance along the earth surface between two points can be

calculated. There are hundreds of different geodetic datums in use around the

world. Referencing coordinates to the wrong datum can result in position errors

of hundreds of meters.

The datums have evolved in course of time from flat- and spherical-earth

models to ellipsoidal models and complex models that completely describe the

size, shape, orientation, gravity field, and angular velocity of the earth. Flat

earth models are still used for plane surveying over distances short enough

(less than 10 km) so that the earth curvature is insignificant. Spherical earth

models represent the shape of the earth with a sphere of a specified radius.

2 The terms “coordinate system” and “spatial reference system” are used differently in different

location-related communities. When referring to a coordinate system, sometimes a coordinate

system in a specific spatial reference system is meant, sometimes again only the coordinate

system without a spatial reference system is meant. In this thesis the term is used according to

the latter definition. To indicate a combination of a certain coordinate system and a spatial

reference system the term “coordinate reference system” is used.



Spherical earth models are often used for short-range navigation and for global

distance approximations. Ellipsoidal earth models are used for more accurate

positioning and navigation.

One widely used datum is World Geodetic Reference System of 1984 (WGS-

84) [NIM97] specified by the United States Defense Mapping Agency. It is used

e.g. by the satellite navigation system Global Positioning System (GPS).

[Dan99b]

2.1.1.2 Coordinate Systems

The absolute spatial location can be expressed using many different

coordinate systems, for example the Latitude-Longitude-Altitude coordinate

system, the Earth Centered-Earth Fixed (ECEF) coordinate system, or the

Universal Transverse Mercator (UTM) coordinate system. The most commonly

used coordinate system today is the Latitude-Longitude-Altitude3 coordinate

system [Dan99a].

Latitude-Longitude-Altitude coordinate system

In the Latitude-Longitude-Altitude coordinate system a location is expressed

with latitude, longitude, and altitude (see Figure 1). Latitude is the north/south

Figure 1 Latitude-Longitude-Altitude coordinate system

3 Altitude is also often called height.

Pole

Equator0o Latitude

Ellipsoidsurface

Prime Meridian0o Longitude

Point P

Altitude(Height)

at Point P

a) Latitude at Point P

b) Longitude at Point P



component. Originally, when the earth was thought to be spherical, the latitude

was the angle between a line starting at the center of the earth and being

perpendicular to the surface of the earth and the plane of the equator.

Now that we know the earth to be ellipsoidal in shape, there are several

types of latitudes. The usual definition of latitude is the angle a line

perpendicular to the surface of the ellipsoid makes with the plane of the equator

(a, Figure 1). This is also referred to as geodetic latitude. Whenever the

unqualified term latitude is used, it is generally accepted that it refers to the

geodetic latitude. [Men01]

The longitude is the east/west component in the coordinate system. The

longitude is the angle between a reference plane (the prime meridian) and a

plane passing through the point whose location is being expressed, both planes

being perpendicular to the equatorial plane (b, Figure 1) [Dan99a]. Thus the

lines of longitude pass through the North and South Poles and intersect the

equator. The line of longitude that passes through Greenwich in England is the

most common prime meridian in use today.

Since latitude can be expressed in many different ways and there can be

different prime meridians, several latitude-longitude-altitude coordinate systems

exist. When referring to the latitude-longitude-altitude coordinate system, people

generally mean the coordinate system using geodetic latitude and the equator

and the prime meridian at Greenwich as reference planes.

The latitude and longitude are generally expressed in degrees, minutes and

seconds, or in degrees, minutes and fractional minutes, or degrees and

fractional degrees. The latitude is expressed in a range of 0-90 degrees, where

0 degrees is at the equator and 90 degrees at the North and South Poles. To

differentiate between a latitude on the northern or southern hemisphere “+” or

“N” is used to indicate northern hemisphere, and “-“ or “S” is used to indicate the

southern hemisphere. The longitude is expressed in a range of 0-180 degrees

to the west or east from the prime meridian. To express degrees to the west “+”

or “W” is used, and to express degrees to the east “-“ or “E” is used. The

altitude (or height) at a point is the distance from the reference ellipsoid to the

point in a direction normal to the reference ellipsoid. It is generally expressed in

meters.



Earth Centered-Earth Fixed (ECEF) coordinate system

Earth Centered, Earth Fixed coordinates (x, y, z) define a three-dimensional

position with respect to the center of mass of the reference ellipsoid (see Figure

2). The z-axis points towards the North Pole. The x-axis is defined by the

intersection of the plane defined by the prime meridian and the equatorial plane.

The y-axis is in the intersection of a plane 90 degree east of the x-axis and the

equator. [Dan99a]

Figure 2 Earth Centered-Earth Fixed (ECEF) coordinate system

Universal Transverse Mercator (UTM) coordinate system

In the Universal Transverse Mercator (UTM) coordinate system the earth is

divided into zones indicated by a number and character (see Figure 3). UTM

zone numbers designate 6 degree longitudinal strips extending from 80 degrees

south latitude to 84 degrees north latitude. UTM zone characters designate 8

degrees zones extending north and south from the equator. There are special

UTM zones between 0 degrees and 36 degrees longitude above 72 degrees

latitude and a special zone 32 between 56 and 64 degrees north latitude.

Universal Transverse Mercator (UTM) coordinates (zone, easting, and northing)

define two-dimensional horizontal positions. Each zone has a central meridian.

Eastings are measured from the central meridian with a 500 km false easting to

ensure positive coordinates. Northings are measured from the equator with a

10 000 km false northing for positions south of the equator. [Dan99a]

Pole

Equator

Ellipsoid

y

x

z

PrimeMeridian

Point (x, y, z)



Figure 3 Universal Transverse Mercator (UTM) zones [Dan99a]

2.1.2 Descriptive Location

Descriptive location is a location described through other means than a

coordinate system. Examples of descriptive locations are:

• Locality - a named location, e.g. “Helsinki” or “Market Square”

• Street address, e.g. “Itämerenkatu 11”

• Postal or zip code, e.g. “00100 Helsinki” or “MA 01803”

• Building number, e.g. “10 A 49”

• State or province, e.g. “Massachusetts” or “New Brunswick”

• Country - country name or code [ISO97], e.g. “Finland” or “FI”

Descriptive location is quite challenging in several ways. It can be expressed

in very many different ways, it tends to have regional differences, and it

depends on the specific human language used. There are many different

existing classifications that can be used, e.g. national postal codes, ISO country

codes [ISO97, ISO98], and Getty Thesaurus of Geographic Names [Get01].

Relative location is a specific type of descriptive location, where the location

of an object is described relative to some other object, e.g. “100 meters from the

store”, “the building next to the tower”, “close to me”, “nearest shop”, etc.

Generally, a descriptive location can be mapped to an absolute spatial location.



2.1.3 Transformations

The different ways of expressing location cover different needs. With the help

of different transformation rules [Dan99b] and transformation applications one

can convert between the different location formats. Converting a set of

coordinates in one spatial reference system to a set of coordinates in another

spatial reference system can generally be accomplished with acceptably small

loss of accuracy. The European Petroleum Survey Group (EPSG) [EPS01]

maintains a registry of most of the commonly used coordinate reference

systems along with the coordinate transformation parameters, which provides

the basis for the calculations [OGC00]. Each object in the registry, i.e.

coordinate reference systems and the objects needed to define them, have a

unique integer code. For example, the code for the unit meter is 9001, and the

code for the WGS-84 datum is 6326.

There is separate software that can be used for transformation between

different coordinate systems and ways of expressing location data, e.g.

EasyTrans 1.24, or FME Universal Translator5. Most of the Geographical

Information System6 (GIS) products, e.g. ArcGIS from ESRI7, also incorporate

this possibility. Open GIS Consortium is currently specifying an open interface

that enables systems to request and receive services related to coordinate

transformations [OGC00].

2.2 Other Related Data

In addition to the location of the object, there are several other parameters

that positioning methods can produce or that can be necessary for using the

location data, for improving the location measurement, or for bringing additional

value to the location data. They are, e.g., accuracy information describing the

accuracy of the position measurement, object identifiers (IDs) for identifying the

positioned object, time stamps indicating when the positioning took place or

how long a certain measurement is valid, the size and shape of the positioned

4 http://www.geoima.de/EasyTrans.html 5 http://www.safe.com/ 6 Geographical Information System is a “computer system for capturing, managing, integrating,

manipulating, analyzing and displaying data which is spatially referenced to the Earth”. 7 http://www.esri.com/

3. Positioning Methods for Determining the Location 12


object, the orientation of the positioned object, the velocity of the positioned

object, the direction the object is moving in, and its intended course. Besides

the location, these kinds of parameters related to the object and its location are

defined to be part of the location information.

3. POSITIONING METHODS FOR DETERMINING THE LOCATION

There are different positioning methods available for determining the location

of an object. In this chapter a brief overview will be given. Those interested in

more details can refer to the different references mentioned in the text.

3.1 Satellite Navigation Systems

Objects can be positioned with satellite navigation systems, e.g. Global

Positioning System (GPS) [Par96, Dan00] and The GLObal NAvigation Satellite

System (GLONASS) [Bör00]. The positioning in these systems is based on

measuring the distance between the receiver and the satellites by calculating

the time it takes to transmit a signal from the satellite to the receiver and the

knowledge of the position of the satellites.

When we know the position of the satellites and the distance to three

satellites we can use triangulation to calculate the 2-dimensional position

(latitude, longitude) of the receiver (see Figure 4).

Figure 4 Positioning with the help of triangulation in a satellite navigation system

S3 (x3, y3, z3)

S2 (x2, y2, z2) S1 (x1, y1, z1)

r2

rs

r1

SP1

SP3

SP2

Circle C1 on the intersection of sphere SP1 and sphere SP2

Circle C2 on the intersection of sphere SP2 and sphere SP3

P1

P2



In Figure 4, S1, S2, S3 represent the position of the satellites. The r1 is the

calculated distance from the satellite S1 to the receiver. The receiver is located

somewhere on the sphere SP1 with the radius r1. When having the distance

measurement to satellite S2, we can narrow down the location of the receiver to

somewhere on the circle C1 where the sphere SP1 and SP2 intersect. When

having the distance to a third satellite S3 the possible positions are narrowed

down further to two points, P1 and P2, in the intersection of circle C1 and circle

C2. In order to decide which one is the true location of the receiver, a fourth

measurement could be made. But usually one of the two points is a ridiculous

answer and can be rejected without a measurement. With the distance

measurements to four or more satellites we can determine the 3-dimensional

position (latitude, longitude, altitude) of the receiver.

The Global Positioning System (GPS) is funded and controlled by the US

Department of Defense (DoD). The system was designed for military use and is

operated by the US military. However, in the 1980s, the US government made

the system available for civilian use worldwide. Earlier, there was an artificial

error (Selective Availability) introduced into the satellite data by the US DoD to

reduce the possible accuracy of a position to 100 meters for civil users. This

was removed on May 1, 2000, enabling an accuracy of about 10 meters for

civilian users [IGE00]. GPS is widely used around the world. The GLObal

NAvigation Satellite System (GLONASS) is managed for the Russian

Federation Government by the Russian Space Forces. The European Union is

currently planning a global navigation satellite system called Galileo [Gal01].

The system is planned to be developed by 2008.

3.2 Positioning in Mobile Networks

The development of positioning methods in the mobile networks, e.g. in GSM

(Global System for Mobile communications) and in UMTS (Universal Mobile

Telecommunications System), has been furthered by the Federal

Communication Commission’s (FCC) E-911 mandate in the US. The mandate

states that from October 2001 it must be possible to locate mobile phone

subscribers calling the emergency number 911 in the US [FCC99]. As a result,

positioning methods for positioning mobile phone subscribers have been

developed for different mobile networks.



3.2.1 Positioning Methods for GSM

For GSM networks Cell Identity (CI) and Timing Advance (TA), UpLink Time

Of Arrival (UL-TOA) and Enhanced Observed Time Difference (E-OTD)

positioning methods based on measurements performed within the mobile

network, and the Assisted GPS positioning method based on GPS technology

are included in GSM standards [Ran00]. The methods will be presented in this

chapter, for more details see [Ran00, Swe01, Läh01].

CI and TA based methods were the first to be developed, since they require

no or only little changes to the mobile networks. Network infrastructure vendors

have also developed solutions incorporating some of the other mentioned

positioning methods. As a result of the E-911 amendment, especially during the

year 2001, many platforms providing positioning services have been

announced. In addition to the standardized positioning methods, different

vendors have developed proprietary positioning systems, e.g. based on CI, TA

and SIM Toolkit8.

3.2.1.1 Cell Identity and Timing Advance

The easiest way to locate a terminal in a GSM network is to use the Cell

Identity (CI), which identifies the mobile network cell that is currently serving the

mobile terminal (Figure 5). If we know the coordinates of the base station (BS)

of the network cell, the location of the terminal can be determined with the

accuracy of the size of the cell. The accuracy of this method varies depending

CI CI + TA CI Sector CI Sector + TA

Base Station

Figure 5 Different Cell Identity (CI) and Timing Advance (TA) methods

8 SIM Toolkit is a standard for value added services in GSM. Essentially, SIM Toolkit is a

client-server architecture where the SIM (Subscriber Identity Module) card in the mobile phone

acts as the gateway to the mobile network operator's server, which houses the applications. The

mobile handset is the client. [Wie01]



on the size of the cells (approximately 50 m indoors – 35 km rural areas).

In the Cell Identity (CI) and Timing Advance (TA) method the location

measurement is improved by using Timing Advance information (Figure 5). The

Timing Advance is a parameter conceived to avoid different terminals

transmitting overlapping signal bursts to a base station during calls. It describes

how much earlier the mobile terminal needs to send its signal burst so that it

reaches the base station in time for the time slot allocated to the terminal. The

Timing Advance is proportional to the distance between the terminal and the

base station. With the help of the Timing Advance the terminal can be

positioned more exactly. Cell Sector information, i.e. the orientation and angular

width of the serving cell sector, can be used to further improve the accuracy of

the Cell Identity (CI) or the combined Cell Identity (CI) and Timing Advance (TA)

method (Figure 5).

3.2.1.2 UpLink Time of Arrival

In the UpLink Time of Arrival (UL-TOA) positioning method the Time Of

Arrival (TOA) of a known signal from a mobile terminal to at least three location

measurement units (LMUs) situated at three mobile network base stations is

measured (BS1, BS2, BS3 in Figure 6).

Figure 6 Positioning principle of the UpLink Time Of Arrival method

Time Difference of Arrival (TDOA) is calculated by subtracting pairs of TOA

values and adding the timing offset between the respective LMUs where the

TOA values were measured. The TDOA is a scaled measure of the relative

distance between the mobile terminal and the pair of base stations where the

LMUs are located, e.g. TDOA2-1=(d2-d1)/c, where c is the speed of the radio

BS1

BS2

BS3

d1

d2

d3

TDOA2-1 = = constantd2- d1

c

TDOA3-1 = = constantd3- d1

c



waves, and d1 and d2 are the distance from the mobile terminal to the base

stations BS1 and BS2, respectively. Each TDOA measurement defines a

hyperbola (with the base stations where the TOA measurements were

conducted being at the foci of the parabola). Three such hyperbolas have a

unique intersection point. To obtain three TDOA measurements four TOA

measurements at four different measurement units (LMUs) need to be done.

However, in many cases two hyperbolas have a unique intersection and then

three TOA measurements are sufficient. In order to determine the position, the

geographical coordinates of the measurement units (LMUs) need to be known.

3.2.1.3 Enhanced Observed Time Difference (E-OTD)

The Enhanced Observed Time Difference (E-OTD) method is based on the

measured Observed Time Difference (OTD) in the mobile terminal between

arrivals of bursts from nearby pairs of base stations. Since the transmissions

from the base stations are not synchronized, Location Measurement Units

(LMUs), installed through the network in fixed and known positions, measure

Real Time Difference (RTD). If a burst is transmitted by BS1 (respectively BS2)

at the instant tTX1 (respectively tTX2) and received by the mobile terminal at the

instant tRX1 (respectively tRX2) the RTD is tTX2-tTX1 and the OTD is tRX2-tRX1. From

the OTD and RTD measurements, the Geometric Time Difference (GTD= RTD-

OTD) can be calculated. The GTD is a scaled measure of the relative distance

between the MS and a pair of base stations (BS1, BS2 in Figure 7).

Figure 7 Positioning principle of the Enhanced Observed Time Difference method

In fact GTD = RTD-OTD=(tRX1-tTX1)-(tRX2-tTX2)=(d1-d2)/c, being c the speed of

radio waves and d1=c(tRX1-tTX1), d2=c(tRX2-tTX2) the distance between the mobile

BS1

BS2

BS3

d1

d2

d3

GTD1,2 = = constantd1- d2

c

GTD1,3 = = constantd1- d3

c



terminal and BS1, BS2 respectively. The possible positions of the mobile

terminal are located on a hyperbola having foci at BS1 and BS2. To obtain

accurate positioning, OTD and RTD measurements are needed for at least

three geographically distinct pairs of base stations.

Two variants of the E-OTD method exist: MS Assisted E-OTD and MS Based

E-OTD (MS standing for Mobile Station, i.e. the mobile terminal). In the MS

Assisted E-OTD method the mobile terminal makes the OTD measurements

and sends them for location calculation to the network. In the MS Based E-OTD

method the network broadcasts assistance data (essentially RTD values and

base stations’ coordinates) to the mobile terminal, so that it can calculate its

own position.

3.2.1.4 Assisted GPS

The idea of the assisted GPS method is to assist a GPS receiver integrated

in the mobile terminal to determine the position. Assistance data for calculating

the position is provided by stationary receivers in a GPS reference network,

which is connected to the GSM network. The advantage of these stationary

receivers is that they have clear views of the sky and can operate continuously.

[Ran00]

Different assistance data allow a reduction of receiver start-up time, an

increase of receiver sensitivity, a reduction of power consumption in the mobile

terminal, a decrease of acquisition time, and an improvement of location

accuracy. There are also proposed methods where the position is calculated in

the network instead of the mobile terminal.

3.2.2 Positioning Methods in UMTS

The UMTS standards include the methods Cell Identity, Observed Time

Difference Of Arrival-Idle Period DownLink (OTDOA-IPDL), and Assisted GPS.

The Observed Time Difference Of Arrival-Idle Period DownLink (OTDOA-IPDL)

is an adaptation of the Enhanced Observed Time Difference (E-OTD) method

(described in Section 3.2.1.3) to the UMTS system [Ran00]. The positioning

method will be deployed after the UMTS networks have been taken into public

use.



3.2.3 Other Positioning Methods

In addition to the standardized methods, several proprietary positioning

systems have been developed, e.g. based on CI, TA and SIM Toolkit. Lists of

positioning solutions and vendors can be found at [GEO01] or [T3G01].

Positioning methods standardization is also conducted for other mobile

networks, e.g. for IS-136 Time Division Multiple Access (TDMA) widely used in

America, and IS-95 Code Division Multiple Access (CDMA) cellular systems.

For IS-95 a method called Advanced Forward Link Trilateration (AFLT) is

specified. The method is based on measuring the time of arrival of radio signals

from the base stations.

3.3 Local Positioning Systems

There are also so-called local positioning systems for indoor and local area

positioning. The systems are based on short-range communication, using e.g.

Infra-Red (IR) [ATT01, MIT99], Radio Frequency Identification (RFID) [AIM01,

WER99], Bluetooth, and Wireless Local Area Networks (WLAN). The solutions

vary depending on the used technologies. In the basic systems, objects having

unique identifiers can be located to a specific space/room, or the objects can be

informed about their current location (e.g. a room number). In the more

advanced systems, the object is positioned by measuring signal strengths or by

using triangulation.

3.4 Configuration and Manual Input upon Request

The location information of physically stationary objects can also be needed,

e.g. of IP-network routers for network optimization, of an Internet device

behaving maliciously, or of a stationary PC via which an emergency call is

made. In such stationary devices the location information can be preconfigured.

For mobile terminals the location can, in addition to being determined with some

positioning method, also be given manually by the user of the terminal upon a

request by the application needing this information.

3.5 Summary of Positioning Methods

The different positioning methods fulfill different needs, since their optimal

area of use and their accuracy differ (Table 1 gives an overview). Thus a



specific positioning method can be the best one for a specific application (e.g.

local positioning for indoor tracking).

Positioning method

Accuracy Operational area (works best)

GPS 10 m Where GPS-signals can be received (outdoors in open areas).

CI 50 m - 35 km Mobile network (GSM) coverage area (best accuracy where network cells are dense: city centers, or indoors if indoor transceivers installed).

CI+TA 100 - 200 m Mobile network (GSM) coverage area (best accuracy where network cells are dense: city centers, or indoors if indoor transceivers installed)

UL-TOA 50 - 200 m Mobile network (GSM) coverage area (best accuracy where network cells are dense: city centers, or indoors if indoor transceivers installed).

E-OTD 50 - 200 m Mobile network (GSM) coverage area (best accuracy where network cells are dense: city centers, or indoors if indoor transceivers installed).

Assisted GPS 1 - 10 m Where GPS-signals can be received (outdoors).

Local positioning systems

1 m - area Where local positioning systems are installed (limited indoor and outdoor areas).

Configuration 1 m - region Where the position is known in advance (stationary objects).

Manual input 1 m - region Where the position can be determined by the person being positioned (position can be expressed in text: street address, region, etc.).

Table 1 Accuracy and operational areas of different positioning methods

Several positioning methods can be used in parallel for positioning the same

object. The advantage of this is that different positioning methods can

complement each other providing positioning in a wider operative area or

providing a better overall location accuracy. The usage of several positioning

methods parallel is, however, a question of added value and cost.

4. Applications Using Location Information 20


One highly debated issue regarding positioning is the privacy of the person

being positioned. The privacy issue is the biggest threat to the acceptance and

deployment of positioning methods and services using location information. The

common understanding is that the person being positioned should be aware of

the positioning, and in most cases (with the exception of some tracking

applications, e.g. tracking of prisoners) should be able to control who can

position and who can get access to the location information at a certain time for

what purpose. The positioning methods in the mobile networks include privacy

mechanisms. The privacy issues have been widely discussed, but there are still

many legislative and technical challenges ahead.

4. APPLICATIONS USING LOCATION INFORMATION

The applications using location information can generally be categorized as

location-based and location-dependent services. A location-based service is a

service that uses information about the location of a locatable target (e.g. a

mobile phone client). A location-dependent service is a service that is only

available within a certain geographical area. The term location service is often

used for applications that can provide location information.

The applications implementing location-based and -dependent services can

be deployed e.g. within the mobile network (GSM, UMTS, etc.), or as services

in the Internet (Figure 8). The scope of this work is services located in the

Internet and how they can obtain location information.

Figure 8 Applications implementing location-based and -dependent services can be deployed e.g. within the mobile network or the Internet

GSM, UMTS, etc.)Internet

Location-based/dependent

serviceapplication

Location-based/dependent

serviceapplication



4.1 Different Types of Applications

There are numerous different kinds of location-based and -dependent

services that can be deployed in the Internet, and also many different ways of

categorizing the different types of services. Figure 9 presents examples of

different types of location-based and -dependent services.

Figure 9 Different types of location-based and -dependent services

4.2 Service Initiation

Different types of services have different models how the service is initiated,

and how the location information is provided to the service. For the service

initiation there are three models: the user initiates the service (described as “self

initiated” in Figure 9), somebody else initiates the service (described as

“initiated by others” in Figure 9), or the user subscribes to the service (described

as “subscribed” in Figure 9).

Yellow page services:Where is

the nearest restaurant?Point-of-interest services:

Closest attractionWhat happens here today?

Information Services InformationMemorizing & AssociationAdding and storing location

information to data, e.g. html-pages, emails, Calendar entries,

photos, maps

Navigation & Guidance

Where am I?How do I get to X?(single request or

continuous navigation)

��

��

Safety Services

��

��

��

��

��

��

Notification Services

��

��

��

��

��

��

Tracking Services

Authorization and access to resources, information,

spaces according to location

Security & AuthorizationServices

Location sensitive billing

Billing Services

Network managementLocation-specific

resource management and discovery

Management Services

one time

Self initiated

Initiated by othersSubscribed

Self initiated Self initiated

Self initiated

Initiated by others Initiated by others Initiated by others

one time

periodic

periodic

one time

region

one time

one time

periodicregion

periodicregion

periodicregion

one time

periodicregion



4.3 Providing Location Information to the Applications

There are principally two ways to provide location information to the

application implementing the location-based or -dependent service in the

Internet (Figure 10). They are: (1) the client interacting with the application

provides the information with its service requests, or (2) the application asks for

the information from a location information source via an interface.

Figure 10 Different ways of providing location information to applications

In the first case, where the user provides the location information with its

service requests, the client can reside inside the Internet, i.e. be directly

connected to the Internet (e.g. a World Wide Web browser), or be outside the

Internet, i.e. connect to the Internet via a gateway translating the requests into

the right message format (e.g. Wireless Access Protocol (WAP) client) (1,

Figure 10). The client can obtain the location information via some positioning

device connected to it (e.g. GPS receiver), via preconfiguration, manual input or

some location information source being able to position the device. In the latter

case, it is also possible for the gateway to attach the location information to the

request. Possible interfaces to different location information sources will be

presented in Chapter 5.

In the “self initiated” services the location information can be provided with

the service request, or obtained by the application implementing the service

from some location information source. In the service types “initiated by others”

and “subscribed” the application implementing the service generally obtains the

location from some location information source.

Location

API

Application

Internet

Gate-way

(1)

(2)

Location

Location



4.4 Requirements on the Location Information

Common for all the service types are that they require the location

information as input either once immediately, once delayed, or several times at

certain intervals. On a general level, the services can be identified to require

two different types of input: point-like location information in some form, or a

notification that a user enters or leaves a certain region (this can of course also

be calculated from location information within the service). In Figure 9, the

location information needs of different types of services are described. The term

“one time” means that service needs the location information once, “periodic”

that the service needs periodic updates with location information, and “region”

that the service could make use of information about when the user

enters/leaves a certain region.

The kind of location information needed by a service varies depending on the

service, but most of the services can manage with absolute spatial location

information (for a more detailed discussion see Section 11.2). The required

accuracy varies for the different services. Table 2 gives some indication of

required accuracies for different services. For a detailed analysis, see e.g.

[kor01a].

Accuracy of the location

Service

Regional Weather services, general traffic alerts, regional advertisement

District (<20 km) Local news, traffic reports

< 2 km Fleet management

1 km Roadside assistance

< 200 m Locating person in emergency or needing assistance

10 - 50 m Navigation and guidance services, asset location, continuous location-based information storing

Table 2 Required location accuracy by different types of services (adapted from [Dah99])

5. Interfaces for Providing Location Information 24


5. INTERFACES FOR PROVIDING LOCATION INFORMATION

As presented in Section 4.3 the client interacting with the service provides

the location information to the location-based/dependent service application or

the application obtains the location information from a location information

source via an interface. Some proposed interfaces are (Figure 11):

1) Interfaces in mobile networks (GSM, UMTS, etc.) for providing the

location of a mobile terminal

2) Interfaces in mobile terminals for providing the location determined by

some external positioning device, the mobile network, or manually by the

user

3) Interfaces towards local positioning systems (e.g. IR, RFID, WLAN,

Bluetooth)

4) Interfaces in stationary devices connected to the network, e.g. IP routers,

or local PCs

Figure 11 Different possible interfaces towards positioning systems

WLAN

(4) stationary devices(2) mobile devices

(3) local positiong systems

GSM, UMTS, etc.)

(1) mobile networks

API

API

API

APIAPI

API

API

RF

Bluetooth IR

APIAPI API

API

Application

6. Standardization Activities 25


6. STANDARDIZATION ACTIVITIES

There are many on-going standardization activities related to location-

technologies, location information, and location interfaces in different

standardization bodies and industry consortiums. They are, among others,

European Telecommunications Standards Institute (ETSI), Third Generation

Partnership Project (3GPP), Location Inter-operability Forum (LIF), Wireless

Application Protocol Forum (WAP Forum), World Wide Web Consortium (W3C),

Internet Engineering Task Force (IETF), Open GIS Consortium (OGC),

ISO/TC211, Bluetooth Special Interest Group, Magic Service Initiative, Wireless

Location Industry Association (WLIA), and W5 Consortium (W5C). Especially

during the past year (2000-2001) many new activities were established.

There are several reasons why there are so many different standardization

activities. One reason is that there are many fields of technology to cover. Quite

a few of the activities are developing location technologies, location information,

and interfaces specific for their field of technology and its specific needs.

Another reason for so many different activities is the large potential identified for

different kinds of location services providing or using location information. The

increasing availability of location information will enable many new types of

services. This again will mean new possible sources of revenue, and new

possibilities of attracting and retaining customers. Everybody wants to

participate, in order to get a piece of the cake. This is probably the main reason

why so many new activities have been established lately. Everybody wants to

cover the field.

The objectives and scope of the different standardization activities will be

presented in the following sections. In the review our main focus will be on

standardization activities that are in some way related to the Internet. In Section

6.10 the different activities, their scopes, and possible similar objectives

between the activities are summarized.



6.1 ETSI and 3GPP

The European Telecommunications Standards Institute (ETSI)9 and Third

Generation Partnership Project (3GPP)10 are telecommunication

standardization organizations working on the standardization of the mobile

networks GSM and UMTS, among other things. As a result of the E-911

amendment stating that emergency calls must be locatable, they are

standardizing a location service architecture for GSM and UMTS11. The main

objective of the work is to enable positioning of mobile (phone/terminal)

subscribers in the mobile networks. The standards specify positioning methods

for positioning mobile subscribers (see Section 3.2), and an architecture with

network elements for positioning measurements, calculations, and provisioning

of location information. The architecture includes a Gateway Mobile Location

Center (GMLC) that provides the location information of mobile subscribers.

The GMLC is planned to have an interface towards the Internet. The standards

also define a location information format for expressing and transporting the

location information of a mobile subscriber within the mobile networks [3GP00].

6.2 LIF

Nokia, Ericsson, and Motorola established the Location Inter-operability

Forum12 (LIF) in September 2000. The objectives of this industry initiative are to

[LIF01]:

• Define a simple and secure access method (i.e. an application program

interface - API) for appliances and Internet applications to access location

information from the wireless networks irrespective of their underlying air

interface technologies and positioning methods.

• Promote a family of standards-based location determination methods and

their supporting architectures, which are based on Cell Sector

9 http://www.etsi.org/ 10 http://www.3gpp.org/ 11 Actually T1P1.5 subcommittee of the American telecommunications standardization

organization T1 (http://www.t1.org/) conducted part of the GSM location service standardization

work. 12 http://www.locationforum.org/



information, Cell Identity and Timing Advance, E-OTD (GSM), AFLT (IS-

95), and Assisted GPS (for definitions of these see Section 3.2).

• Work with industry experts and organizations to define/adopt common

solutions that facilitate billing, revenue sharing and provisioning of

location services and applications in multi-network, multi-vendor and

multi-service environments.

• Establish a framework for contributing to the global standard bodies and

specification organizations to define common methods and procedures for

the testing and verification of the LIF-recommended access method and

positioning technologies.

The API for Internet applications (called LIF-API) is being defined. It works as

an interface towards the GMLC. The on-going specification uses the interface of

Ericsson’s Mobile Positioning Center [Swe99] as basis. The LIF-API will use

XML (Extensible Markup Language) for describing location information and

service function calls, and Hypertext Transfer Protocol (HTTP) and Secure

Sockets Layer (SSL) for data transport.

6.3 WAP Forum

In the WAP Forum13, the industry consortium standardizing the Wireless

Application Protocol (WAP) technology, there is a Location Drafting Committee.

The purpose of the Location Drafting Committee is to define a WAP location

framework for enabling location-based services. Goals for the activity are to

[Zil00]:

• Define an extensible location framework architecture including the access

to position information available in the client and/or in the network

positioning entity and/or other entities.

• Define a simple, transparent and position procedure independent location

application interface.

• Address location-related privacy issues.

13 http://www.wapforum.org/



The messages in the location framework (location query requests and

responses) will be coded as XML documents. In the WAP location framework

latitude and longitude coordinates using the WSG-84 datum is the mandatory

location format. The WAP User Agent profile (UAProf) as described in [WAP99]

can be used to convey location capability information (e.g. the URL address of

the location information source, or the client location capabilities).

6.4 W3C

In cooperation with the WAP Forum the World Wide Web Consortium14

(W3C) arranged a workshop on Position Dependent Information Services15 in

February 2000. The workshop pointed out that a simple extendible data model

for expressing location data, the way of transporting the information (including

the protocol and architecture) to Web-applications, and privacy and security

mechanisms to protect the information need to be defined. After the workshop

there have not been any further W3C public activities in this field.

In 1999 W3C received two independent submissions describing XML-based

data representation formats that include location data. They are Point Of

Interest eXchange Language (POIX) [Kan99] and NaVigation Markup Language

(NVML) [Sek99].

6.5 IETF

At the beginning of 2000 a group of people started the Spatial Location

Protocol (SLoP) activity in the IETF16 (Internet Engineering Task Force)

[SLo00b]. The objective of the activity was to specify a common protocol

(implying also a common API) for obtaining location information in the Internet.

This means that different location sources, devices, applications, etc, connected

to the Internet would have one common way of communicating location

information [Tan00a].

Initially the work considered a general location architecture where location

information of locatable objects would be accessible on SLoP-servers in the

14 http://www.w3.org/ 15 http://www.w3.org/Mobile/posdep 16 http://www.ietf.org/



Internet. In addition, the object could roam between SLoP-servers and there

would be a server discovery mechanism for locating the server providing the

location of a certain object.

The protocol considerations also included a common data set to express

location information and a framework for representing other location information

expressions, negotiation mechanisms for agreeing on what location information

representation to use, security mechanisms for securing the location information

data and controlling who can access the information, policy mechanisms for

setting privacy policies for who can access what location information,

transmission and reliability mechanisms for the protocol, and the coding of the

protocol messages [Lou00, Ros00, Tan00b, SLo00a, Tan01a].

The working group proposal was later steered by IESG (Internet Engineering

Steering Group) to first focus on the protocol messages (called payload). This

includes the definition of a default location data set, a framework for

representing other location expressions, and other data needed in the

messages. In addition, the task is also to identify and define appropriate policy

and security mechanisms, as well as to check what existing protocols could be

used for transferring the data. Submissions related to the SLoP activity are

available at [SLo00b]. In May 2001 a working group “Geographic

Location/Privacy” with the objectives to work on location privacy issues was

established in IETF [GLP00].

6.6 Open GIS Consortium

Open GIS Consortium (OGC)17 is an international industry consortium of

companies, government agencies and universities working to create open

interfaces to enable interoperability between different geoprocessing systems

and to achieve integration of spatial data and processing into mainstream

computing.

There is a whole range of working groups working on, among other things, a

service architecture for access, management, manipulation, representation, and

sharing of geodata, catalog service for discovering geodata and geoprocessing

17 http://www.opengis.org/



services, geographic features, metadata, coordinate transformations, common

ways to image sources and image exploitation systems, and web-based access

to geodata and geoprocessing services. The message encoding is done with

the Geography Markup Language (GML). It is an XML-based description

language for geographic information (including spatial and non-spatial

properties of geographic features).

In October 2000 the OGC announced the OpenLS Initiative18 with the

objectives to define interfaces for integration of geospatial data and

geoprocessing resources into mobile or wireless location services.

6.7 ISO/TC211

The ISO/TC211 Geographic information/Geomatics workgroup19 is a formal

international standards body creating an entire family of geospatial standards,

ranging from definition, description, management and processing to access and

transfer of geographic information.

There are also other groups in ISO working on geospatial related issues. In

May 2000, ISO established the ISO/IEC JTC 1 Special Group on Spatial

Standardization and Related Interoperability (ISO/IEC JSG)20. The purpose of

this steering group is to enable information sharing and coordination between

different spatial activities in the world. Currently this mainly means ISO and

OGC activities, but the objectives are to invite other activities to participate.

6.8 Bluetooth

Bluetooth21 is a specification for a low-cost short-range radio solution

providing links between mobile computers, mobile phones and other portable

handheld devices, and connectivity to the Internet. The Bluetooth Special

Interest Group (SIG) is developing the Bluetooth technology. There is also a

working group Local Pos working on positioning in Bluetooth networks and how

to export the position related data from Bluetooth devices.

18 http://www.openls.org/ 19 http://www.statkart.no/isotc211/ 20 http://www.statkart.no/jsgspatial/welcome.htm 21 http://www.bluetooth.com/



6.9 Others

In September 2000 nine companies (Alpine Electronics, Increment-P

Corporation (Pioneer), Panasonic, Microsoft, MobileGIS, Telcontar, Tele Atlas,

VDO/Siemens, and Xanavi) founded the MAGIC Service Initiative22. The goal of

the initiative is to define and promote open standard XML-based protocols and

corresponding APIs for mobile geographic information services.

The Wireless Location Industry Association (WLIA)23 was established in

December 2000. Founding members were companies, such as Cell-Loc,

SignalSoft, Cambridge Positioning Systems, and Zero Knowledge Systems.

The focus of the association is to promote wireless location industry, educate

the public, lobby regulators, endorse industry standards through alliance

building, track privacy issues, and develop self-regulating policies.

At the beginning of 2001 the activeRF company established the W5

Consortium (W5C)24 to create an open standard for the exchange of real time

location information.

6.10 Summary of the Different Standardization Activities

There are many on-going standardization activities. In the previous sections

we have presented several that somehow relate to the Internet. Figure 12

summarizes the claimed scope and objectives of the different activities.

The comparison focuses especially on identifying objectives that relate to

how location information can be provided to applications in the Internet. This

includes interfaces through which location information can be provided, a

protocol for providing location information to applications in the Internet, how to

express location information, and how the privacy of the object being located

can be protected. The goal of the comparison is to show that there are several

activities working on similar issues related to how to provide location information

to applications in the Internet. In Figure 12, the black boxes indicate activities

22 http:// www.MAGICServicesForum.org /magicsignup/index.html 23 http://www.wliaonline.com/ 24 http://www.activerf.com/w5wgroup/w5wg.htm

7. Existing Location Information Expressions 32


with similar objectives, gray boxes partly similar objectives, and white boxes

activities that are related to the specific technology domain.

Figure 12 Scope and objectives of different location standardization activities

When looking at the figure one can see that many activities have quite similar

objectives, even though the starting point and detailed objectives might vary

based on the backgrounds and the application domain of the standardization

activity. This situation might lead to a situation in the future where we will have

several different solutions for providing location information to applications in

the Internet.

7. EXISTING LOCATION INFORMATION EXPRESSIONS

There are many existing or proposed location expressions from a number of

organizations. The different location expressions have been defined based on

the location information needs of the specifying organization, and thus

represent different perspectives on location information. The expressions are

among others:

IETF LOCPRIV

Interfaces for integr. of geospat. data and geoproc. resources into mob. or wirel. loc. serv.

OpenLSInitiative

Family of geospatial standards; def., descr., mgt., proc., access and transf. of geo. InformationISO/TC211

Positioning methods, billing/revenue sharing/provisioning of location services/appl.LIF

Location architecture for WAP servicesWAP Forum

Privacy

Location architecture for WWW servicesW3C

XML-based protocol and API for mobile geographic information services

Magic Services

Exchange of real-time location informationW5

Promote wireless location industry, endorse standards, track privacy issuesWLIA

Information sharing and coordination between different spatial activitiesISO/IEC JSG

Open interfaces and standards for geodata and geoprocessingOGC

Positioning methodsBluetooth

Positioning methods, location architecture and services within mobile networksETSI/3GPP

Location architecture for the InternetIETF SLOP

Others

LocationInfoForm

at

LocationInfoProtocol

InternetLocationInterface

Activity

IETF LOCPRIV

Interfaces for integr. of geospat. data and geoproc. resources into mob. or wirel. loc. serv.

OpenLSInitiative

Family of geospatial standards; def., descr., mgt., proc., access and transf. of geo. InformationISO/TC211

Positioning methods, billing/revenue sharing/provisioning of location services/appl.LIF

Location architecture for WAP servicesWAP Forum

Privacy

Location architecture for WWW servicesW3C

XML-based protocol and API for mobile geographic information services

Magic Services

Exchange of real-time location informationW5

Promote wireless location industry, endorse standards, track privacy issuesWLIA

Information sharing and coordination between different spatial activitiesISO/IEC JSG

Open interfaces and standards for geodata and geoprocessingOGC

Positioning methodsBluetooth

Positioning methods, location architecture and services within mobile networksETSI/3GPP

Location architecture for the InternetIETF SLOP

Others

LocationInfoForm

at

LocationInfoProtocol

InternetLocationInterface

Activity



• Expression standardized for GSM and UMTS (called here “3GPP”) to be

used internally in the mobile networks specified by the 3GPP [3GP00].

• An interface (LIF-API) towards mobile networks (e.g. GSM) for providing

access to location information of mobile terminals in consideration by the

Location-interoperability Forum (LIF) [And00].

• The Geography Markup Language (GML) for storing and transporting

geographic information specified by the Open GIS Consortium (OGC)

[Lak00, Cox00].

• NaVigation Markup Language (NVML) for describing navigation

information submitted by the Fujitsu Laboratories to the World Wide Web

Consortium (W3C) [Sek99].

• Point Of Interest eXchange Language (POIX) for exchange of location-

related information over the Internet created by MObile Information

Standard TEchnical Committee (MOSTEC) and submitted to the W3C

[Kan99].

• Geotags for geographic registration and resource discovery of Hypertext

Markup Language (HTML) documents [Dav01a, Dav01b].

• National Marine Electronics Association’s (NMEA) interface and data

protocol NMEA-0183 often used by GPS receivers [Ben00].

• The electronic business card format VCard and ICalendar for exchanging

electronic calendaring and scheduling information in the Internet include

elements to specify position [ver96, Daw98a, Daw98b].

• A Means for Expressing Location Information in the Domain Name

System (DNS-LOC) specified in an Internet draft by Davis et al. [Davi96].

• Simple Text Format for the Spatial Location Protocol (SLoP) (here called

“SLoP-simple”) proposing a simple text-based format to carry a minimal

location data set by Mahy [Mah00].

• GMML, XML-based geographical information for navigation with a mobile

specified at the University of Jyväskylä [Gar01].



• LandXML, an XML-based data format for exchange of data created during

land planning, civil engineering and land survey processes [Lan01].

• Geospatial-eXtensible Markup Language (G-XML) for encoding and

exchanging geospatial data specified by the G-XML Committee in Japan

[G-XML].

• Common Spatial Location Data Set [Kor01b], Spatial Location Payload

[Kor01c], and Common Syntax and Coding for Descriptive Location

[Tan01b] developed during the IETF SLoP activity. They are discussed in

more detail in this thesis.

In addition to these we have several other non-public specifications, including

those from WAP Forum Location Drafting Committee, Bluetooth Special Interest

Group, ISO/TC211, etc.

7.1 Analysis of Location Expressions

7.1.1 Types of Information

In brief, most of the formats express location with latitude, longitude, using

WGS-84 as reference datum. GML, LIF, NAVML, POIX, NMEA, LandXML, and

G-XML also enable expressions using other coordinate systems and reference

datum. Some allow altitude, if the data is available. In the location expressions,

altitude usually means the height above WGS-84 reference ellipsoid, while it is

unclear in some cases.

Most of the formats focus on the specification of the location of a point object,

whereas others also include the expression of object shapes (3GPP, LIF, GML,

LandXML, and G-XML). In DNS-LOC and NVML the radial size of the object

can be defined.

When the accuracy for estimating a location is defined, it is mostly expressed

as horizontal and vertical error. However, the 3GPP proposal includes more

complex accuracy descriptions.

LIF, POIX, NMEA, 3GPP, and G-XML also include fields for velocity/speed. It

is expressed as horizontal speed in all the cases except 3GPP. The 3GPP

8. Challenges of the Current Situation 35


proposal defines horizontal velocity (horizontal speed + bearing) and vertical

velocity (vertical speed + vertical direction).

Direction of movement is also included in LIF, POIX, and NMEA, using true

and/or magnetic North. POIX and NMEA include the possibility to define the

course, as well.

7.1.2 Encoding

The location information can be encoded in different ways. Table 3 shows a

brief overview of how the location expressions mentioned in this chapter are

encoded. The comparison excludes Common Spatial Location Data Set

[kor01b], Spatial Location Payload [kor01c], and Common Syntax and Coding

for Descriptive Location [tan01b] discussed in this thesis. They are all encoded

in Extensible Markup Language (XML). Especially during the past year the use

of XML has increased (more about this in Part 2 of the thesis).

Encoding

3GPP

LIF

GM

L

NVM

L

POIX

Geotags

NM

EA

VCard

ICalendar

DN

S-LOC

SLoP-simple

GM

ML

LandXML

G-XM

L

XML x x x x x x x Binary x x

Text x1 x x2 x2 x x

x1 using HTML META tags, x2 using GEO element in VCard and ICalender, or LOCATION element in VCard

Table 3 Encoding of different location information data formats

8. CHALLENGES OF THE CURRENT SITUATION

Currently there are different organizations, standardization bodies, industry

consortiums and vendors specifying different ways of expressing location

information, different ways of transferring location information, and different

interfaces (APIs) for location information in the Internet (Chapter 6). This

creates a serious disadvantage. The location information provided to

applications in the Internet might have different incompatible formats, and there

might be different incompatible ways for applications in the Internet to obtain

location information from different location information sources (Figure 13).



From an Internet point of view, where we want to achieve openness and

interoperability, this situation is not good. A common solution enabling

interoperability is needed.

Figure13 Incompatibility of Internet applications caused by different location formats, interfaces and protocols

Interoperability in the area of providing location information to Internet

applications can be reached on different levels:

1) By having a common way of expressing location. Different applications

could use this common way independent of the way the information is

provided to them.

2) By having a common way of obtaining location information to applications

in the Internet. This actually means that there are common interfaces and

transfer protocols with which location information can be obtained to

applications in the Internet. This level can also make use of the common

way of expressing location information.

Lately the first steps towards interoperability have been taken by different

organizations. For example, LIF is trying to standardize the interface towards

different mobile networks. This is, however, not sufficient for complete

WLAN

stationary devicesmobile devices

local positiong systems

GSM, UMTS, etc.)

mobile networks

API

API

API

APIAPI

API

API

RF

Bluetooth IR

APIAPI API

API

Gate-way

Internet

incompatibility



interoperability in the Internet. For this we need more common and general

solutions. The common ways of expressing and obtaining location information

to Internet applications will be discussed in more detail in Part 2 of this thesis.

The focus will be on the common way of expressing location information. This

appears to be the first thing to tackle, since it enables interoperability

independently of used transfer method, and it is the easiest level of

interoperability to be deployed by different standardization activities.

38


Part 2: A Common Way of Expressing and Obtaining Location Information in the Internet

9. A Common Way of Expressing and Obtaining Location Info 39


9. A COMMON WAY OF EXPRESSING AND OBTAINING LOCATION INFO

As a result of the current development there are different ways of expressing

and providing location information to applications in the Internet. The application

can be any application in the Internet needing location information of a locatable

object in order to provide a location-based/dependent service (as defined in

Chapter 4). For interoperability reasons it would be good if there were one

commonly agreed way for expressing and obtaining location information to

applications in the Internet.

9.1 Initial Ideas for Providing Location Information to Applications

In order to provide a solution, the Spatial Location Protocol (SLoP) activity

was started in January 2000 in IETF [SLo00b]25. The objective of the activity

was to create a common way of obtaining location information to applications in

the Internet.

In the activity an architecture was considered, where SLoP-servers in the

Internet would represent one or several locatable objects providing their current

location information to applications needing the information. The architecture

would enable a common way of obtaining location information for all objects

represented in the Internet. In addition, the location information for a certain

object could be obtained from different location information sources through one

common interface in the SLoP-server.

The work included initial considerations on possible architectures for SLoP-

servers, requirements on a common spatial location protocol for obtaining the

location information, including thoughts about a common data set to express

location information and a framework for representing other location information

expressions, negotiation mechanisms for agreeing what location information

representation to use, security mechanisms for securing the location information

data and controlling who can access the information, policy mechanisms for

setting privacy policies for who can access what location information,

transmission and reliability mechanisms for the protocol, and the coding of the

protocol messages. In addition, different ways to find the server representing a

25 The author was one of the initiators of the activity.



certain locatable object, as well as naming schemes for the objects, and how

objects could roam between SLoP-servers were considered. [Lou00, Ros00,

Tan00b, Tan01a]

9.2 Two Levels of Interoperability

When the SLoP work progressed and as I participated in different location

standardization activities, it grew evident to me that there are two separate

levels where interoperability can be reached:

1) A common way of expressing location information – Independent of the

way the location information is provided to the application.

2) A common way of obtaining location information – Including common

interfaces and protocols for getting the location information to the

application.

9.2.1 A Common Way of Expressing Location Information

The primary level to reach interoperability on is a common way of expressing

location information. Different applications (location information

consumers/sources) can then use the common way of expressing location

information enabling interoperability and reuse of tools, independently of the

location information transfer methods. This is the level of interoperability that

can be most easily reached by different standardization activities and

applications.

Let us consider an example of a location-based service in the Internet

(application in Figure 14) that can provide a user information about the closest

restaurant. In order to do so, the location of the user is needed. The user is

using the service via his/her Web browser in the mobile terminal (a, Figure 14).

The location information can be provided to the service in two ways:

1) From the terminal (a, Figure 14) that has access to the location

information e.g. via a GPS receiver connected to the terminal. The

terminal can provide the location information e.g. with the help of the

Hypertext Transfer Protocol (HTTP) (b, Figure 14).



2) From the mobile network the terminal is connected to via the planned LIF

Application Program Interface (LIF-API, presented in Section 6.2) (c,

Figure 14). The terminal gives the IP-address from where the location can

be obtained, and the application can then obtain the location information

from the LIF-API with the LIF interface protocol (d, Figure 14).

Figure 14 A Common way of expressing location information

If the terminal and the LIF-API had the same way of expressing the location

information, the application would be able to understand the information directly

without any transformations and could use the same tools, parsers, and

processing methods to process the location information. If different location

information sources used the common way of expressing location information,

location-based/dependent services could understand the location information

independent of the original source.

9.2.2 A Common Way of Obtaining Location Information

If an application obtains location information from different location

information sources, it would be an advantage if there were a common way of

doing so. This implies common interfaces for location information sources and

common protocols for a location-based/dependent service application to obtain

the location information of a locatable object.

GSM, UMTS, etc.)

LIFAPI

Location

Location

Internet

Applicationa)b)

c)

d)



As an example, let us consider an application that tracks prisoners

(application in Figure 15). For tracking the prisoners, two different positioning

methods are used (positioning in the GSM network and Bluetooth positioning).

Two different positioning methods are used in order to improve the positioning

accuracy and the area of operation. In the example, the GSM network

positioning will provide good tracking outdoors and within the prison Bluetooth is

used for more accurate positioning. Thus, the application needs to access

location information from a GSM network as well as from a Bluetooth network

(Figure 15).

Figure 15 Common way of obtaining location information

If the GSM network and Bluetooth network have the same interface (API) and

protocol for obtaining the location information, the application can access the

information in the same way from both sources. It would be an additional

advantage if the sources expressed the location information in a common way.

There is also another approach of implementing a common way of obtaining

location information. There could be specific “middleware” servers (SLoP-

servers) in the Internet representing one or several locatable objects (Figure

16). This idea was explored during the SLoP activity. The server could provide

location information in a common way for different incompatible location

information sources. “Incompatible” here implying that the interface and protocol

for accessing the information from these sources are different, as possibly also

the used location information format.

Bluetooth

GSM, UMTS, etc.)

Application

Internet

CommonAPI

CommonAPI

Location

Location

10. A Common Way of Expressing Location Information 43


Figure 16 “Middleware” server for providing location information

With this kind of “centralized” solution for location information, privacy and

security issues as well as the billing of location information can be handled in a

centralized and common way for many objects and information sources.

A more detailed discussion of a common solution/architecture for obtaining

location information is out of the scope of this thesis.

9.2.3 Summary

Since there are many different ways of providing location information to

applications, it can be quite challenging to try to create one common way of

obtaining location information to applications in the Internet. A common way of

expressing location information can be deployed independently of how the

location information is provided to the application. Thus it will be easier to reach

interoperability on this level, and the solution can be used by several

applications independently of how the location information is transferred. This

also appears to be the level of interoperability that the different players and

activists in the field of location technologies can easily accept and deploy.

Because of this, a common way of expressing location information appears to

be the issue that should be dealt with first. That is why the rest of the thesis

concentrates on a common way of expressing location information.

10. A COMMON WAY OF EXPRESSING LOCATION INFORMATION

If we can agree on a common way of expressing location information, we can

reach interoperability for location information in applications. This means that

Internet

LocationApplication”Middleware”

server

Bluetooth

GSM, UMTS, etc.)

LIFAPI

API

11. A Common Location Data Set 44


applications could use location information from different location information

sources and use the same tools, parsers, and processing methods to process

the information. The interoperability of location information can be tackled in

several different ways:

1) A Common Location Data Set – A set of location data elements common

to most of the location information sources and applications, expressed

and encoded in a common way. Interoperability can be reached if location

information sources and applications use this common data set.

2) A Common Way of Expressing Different Location Data Sets – Different

location applications need different location information, thus it is

necessary also to enable the use of different location data sets. If there is

a common structure and way of encoding, naming, and registering the

data, the identification, processing, and transformation of different data

sets is unified, leading to interoperability.

3) A Common Location Payload for Data Sets – This is a common way of

packaging one or several location data sets. Sometimes applications

might need information from several location data sets and the payload is

a common container for combining several data sets and other associated

data.

These three issues will be discussed in more detail in the following chapters.

In Chapter 11 the common location data set and what kind of elements it should

include will first be evaluated. Chapter 12 will investigate the issue of

expressing different location data sets in a common way. In Chapter 13 the

common container (payload) for different location data sets and associated data

is discussed.

11. A COMMON LOCATION DATA SET

The purpose of a common location data set in the Internet is to enable

Internet services and applications to express location information in an

interoperable way. This chapter proposes such a set. The work was conducted

as part of the SLoP activity in the IETF, and was initially started to create



discussion and development of a common spatial location data set in the

Internet. The chapter is based on [Kor01a, Kor01b] with some improvements.

11.1 Design Requirements

Our aim was to create a data set containing as many elements as possible

common to different location information expressions, so that as many location

information sources and applications as possible could use it. The goal was

also to keep the set as small as possible, to enable as many types of devices as

possible to use it. When designing the set our purpose was to bridge various

existing and proposed location data representation formats, as well as to meet

the requirements on spatial location information by existing or proposed

location-based/dependent services.

The advantage of a common data set is that it enables interoperability

between applications and different location information sources. For example,

one application could use different location information sources without needing

to worry about different location data formats. It would also enable applications

to use the same processing and parsing methods. In addition, not every

application or service would need to create its own location data set. Instead

they could reuse the common location data set and extend it with application-

specific elements, if needed.

To enable this kind of interoperability a well defined set of location data

elements, expressed and encoded in a common way, is needed.

11.2 Location Information Required by Services

In order to determine what kind of elements are needed for the common

location data set, we analyzed what location information different location-

based/dependent services generally require (see [Kor01a]). The different types

of services analyzed were:

• Information (e.g. yellow pages, point-of-interest services)

• Navigation & guidance

• Notification (ads, traffic alerts, weather services, etc.)

• Information memorizing & association

• Tracking & resource management



• Authorization

• Location-specific resource management and discovery

• Location-sensitive billing

• Network management

11.2.1 Absolute Spatial and Descriptive Location

The analysis showed that most of the different services primarily need

absolute spatial position as input. This is also the format that most existing

location measurement systems can provide. Thus absolute spatial position

should be included in the common data set.

Some of the services also need descriptive location such as addresses, and

regions (e.g. Helsinki, Forum shopping mall). For example, the information

services could make use of both, the information memorizing and association

services could use address information to store notes to a specific location, and

the guidance services could use address as input.

Descriptive location is generally created by manual input or via

transformation services using coordinate data as input. It is quite challenging in

several ways. It can be expressed in very many different ways, it tends to have

regional differences, it depends on the human language used, and it can be

very application specific. It is, thus, difficult to add descriptive location elements

to a common location data set.

11.2.2 Size and Shape of Positioned Object

The size and shape of the positioned object could principally be used in two

ways. Firstly, to describe the object that is positioned in order to determine what

region it is covering (e.g. in finding, guidance, notification, tracking,

authorization, resource discovery, billing, and management services). Secondly,

to indicate the region of interest or object to attach information to (in information

and information memorizing & association services).

When designing the data set, the question whether the size and shape of the

positioned object ought to be included or not was considered carefully. It was

decided that the shape and size parameters should be excluded from the

common location data set. This is because most of the positioned objects are



generally of minor size (<10 m). It is also difficult to express shapes and sizes in

a common interoperable way, and the required data structures can be complex.

11.2.3 Other Information

In addition to the position information itself, there are several other

parameters that will bring added value. Many position measurement devices

also provide accuracy and altitude information. This information will bring added

value to services, but most applications can also survive without it.

It is quite evident that it is important to attach the time of measurement to the

location information. This can be essential to the processing and management.

Other information that could bring added value to services includes the

orientation of the object, its moving direction, intended course, and speed.

11.3 The Elements of the Common Spatial Location Data Set

The proposal of a common spatial location data set is based on identified

elements important to applications, and on the available data from different

devices and interfaces. In the first proposal [Kor01a] an element for unspecified

attributes was incorporated, enabling the common spatial location data set to

include some application specific elements. The very strict syntax (parameter

name = value) was later changed, so that any content could be added as

unspecified attributes. Finally, however, the element was removed all together

in order to keep the data set unambiguous and unique [Kor01b]. This simplifies

the validation and possible transformation of the complete data set. See Section

12.5 for a discussion on extending the data set.

The common spatial location data set proposal includes the following

elements:

Coordinates and Datum (mandatory)

When reviewing the various existing interfaces and location data

representation formats, it was found that most of them support coordinates

expressed in latitude, longitude, and altitude (optional) using WGS-84 datum.

Thus it is proposed that these should be used in the common spatial location

data set, where latitude and longitude would be mandatory. In order to keep the



data set simple, no other datum or coordinate systems are supported. The

choice was made to enable the altitude to be expressed both as the altitude

above the WGS-84 reference ellipsoid and as the altitude above the mean sea

level.

Location Accuracy (optional)

Location accuracy is the estimation or measurement error of a location. The

different interfaces include different types of accuracy information. It is proposed

that the most common way to express the accuracy should be included in the

common data set, i.e. horizontal accuracy, expressed by the circle of radius

from the positioned point, and height accuracy, expressed by range from the

positioned point.

Time (mandatory)

Time is the time of a measurement/fix of the location of an object. It is an

important factor for location information. With the help of the time it is easier to

manage location information, and it enables different kinds of approximations. It

is a mandatory element.

Speed (optional)

Speed is indicated as horizontal ground and vertical speed. This expression

is chosen because many systems are able to indicate horizontal ground and

vertical speed.

Direction (optional)

Direction indicates the direction of movement. It is expressed in a 2-

dimensional (horizontal) frame indicated by the magnetic (or true) North.

Course (optional)

Course indicates the direction from the current position to a defined

destination. It is expressed in a 2-dimensional (horizontal) frame indicated by

the magnetic (or true) North.

Orientation (optional)



Orientation describes the orientation of the positioned object. Orientation is

often given with a local coordinate system as reference. Since this reference

frame can be different for different objects, it will be difficult to make a common

expression based on this. One possibility would be to attach an object type

directly indicating the used reference framework. Instead of such a solution, a

method where the orientation is expressed in a 2-dimensional (horizontal) frame

indicated by the magnetic (or true) North, and a vertical element expressed by

the angle between horizontal plane and the main axis of the object is proposed.

11.4 Syntax of the Elements in the Common Spatial Location Data Set

The way of expressing each data element in the common spatial location

data set needs to be defined. Some of the existing data formats (e.g. the

location representation format in LIF [And00]) allow different optional ways to

express the data elements and include syntax information. However, in order to

keep processing as simple as possible one single way of expression is

preferred. Table 4 summarizes the proposal.

Element Expression format and Example

Coordinates

- Latitude (mandatory) - Longitude (mandatory)

- Altitude above datum (optional)

- Altitude above mean sea level (optional)

[N|S]degree.minute.second.f, degree range [0-90], decimal fraction f in arbitrary length N60.08.00.235556 [E|W]degree.minute.second.f, degree range [0-180], decimal fraction f in arbitrary length E25.00.00 [(+)|-]x.f meter from WGS-84 datum reference ellipsoid, + above, - below, decimal fraction f in arbitrary length +12 [(+)|-]x.f meter from mean sea level, + above, - below, decimal fraction f in arbitrary length +10



Location Accuracy - Horizontal accuracy (optional) - Height accuracy (optional)

by circle of radius from the positioned point in (+)x.f meter, decimal fraction f in arbitrary length 50.0 in (+)x.f meter, decimal fraction f in arbitrary length

2.5

Time [Wol97, Kuh95]

- Real time of the measurement/fix (mandatory)

YYYY-MM-DDThh:mm:ss.sTZD, where YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) 1999-08-15T11:16:31.0+2:00

Speed

- Ground speed (optional)

- Vertical speed (optional)

(+)x.f [ms|kmh|mph|knot], where default meter/second (ms), decimal fraction f in arbitrary length 2.0 ms (+)x.f [ms|kmh|mph|knot], where default meter/second (ms), decimal fraction f in arbitrary length 1.0 ms

Direction (optional)

Magnetic/true direction, 360 degrees from North clockwise [M|T][0-360].f degrees, where fractional degrees f in arbitrary length, M default M240



Course (optional)

Magnetic/true direction, 360 degrees from North clockwise [M|T][0-360].f degrees, where fractional degrees f in arbitrary length, M default

M30

Orientation

- Horizontal (optional) - Vertical (pitch) (optional)

magnetic/true direction, 360 degrees from North clockwise [M|T][0-360].f, degrees, where fractional degrees f in arbitrary length, M default M240 [(+)|-][0-180].f degrees, where fractional degrees f in arbitrary length 0

Table 4 Syntax of the elements in the common spatial data set

A formal syntax definition using the ABNF (Augmented Backus-Naur Form)

grammar for the common spatial location data set can be found in Appendix A

in the Internet draft “Common Spatial Location Data Set” [Kor01b]. The same

draft includes, in its Appendix B, a table clarifying the allowed prefixes for the

different elements.

11.5 Encoding of the Data Elements

In order to enable interoperability, a common way of encoding the

parameters is needed. The data elements can be encoded in many different

ways, e.g. as text based attribute-value pairs, in binary, in MIME (Multipurpose

Internet Mail Extensions) [Fre96a, Fre96b, Fre96c], in XML (Extensible Markup

Language) [Bra00], or in RDF (Resource Description Framework) [Las99,

Bri00].

11.5.1 Comparing Encoding Methods

When comparing the different alternatives, XML was selected. The

advantages of XML are that the encoding is easily understandable, readable by

humans, and standard tools and parsers can be used. In addition to this, many



of the other location information proposals make use of XML (as shown in

Section 7.1.2). A possible disadvantage of using XML is that it is quite verbose.

11.5.2 Encoding with XML

In XML a DTD (Document Type Definition) can be used to ensure that XML

documents conform to a common grammar. Thus a DTD of the common data

set can be used for correct parsing and validation of an XML instance of the

data set.

The DTD does not enable very good means of defining the structure, content,

and semantics of an XML document. To solve this, the XML Working Group in

the World Wide Web Consortium (W3C) has defined the XML Schema definition

language [Fal01]. It became a recommendation in May 2001. It provides a

means of defining the structure, content, and semantics of XML documents

more precisely than a DTD. With the help of the XML Schema the constraints

on the different data elements can be expressed better (more about XML

Schema in Section 12.5.1). Since there are not many tools supporting XML

Schema yet, both a DTD and an XML Schema solution are presented for the

common location data set.

11.5.3 Comments on the Use of XML

As Heflin points out in [Hef00], a DTD (the same is true for XML Schemas)

provides a syntax for an XML document, but the semantics of a DTD are

implicit. That is, the meaning of an element in a DTD is either inferred by a

human due to the name assigned to it, is described in a natural-language

comment within the DTD, or is described in a document separate from the DTD.

Humans can then build these semantics into tools that are used to interpret or

translate the XML documents, but software tools cannot acquire these

semantics independently. Thus, an exchange of XML documents works well if

the parties involved have agreed to a DTD beforehand, but becomes

problematic when one wants to search across the entire set of DTDs or to

spontaneously integrate information from multiple sources.

This is sufficient for the presented case, since a world where location data

sets are predefined, named with a unique label (ID), and published for use by

others (if preferred) is foreseen. Generally, the interacting parties will agree in



advance what data set to use, or indicate by negotiation what data sets they

support. This means that the semantics will be preprogrammed into the tools.

11.5.3.1 XML DTD for the Common Spatial Location Data Set

The Document Type Definition (DTD) for the common spatial location data

set is presented in Table 5. The DTD is publicly available at http://www-

nrc.nokia.com/ietf-spatial/2001/05/08/slo_default.dtd.

<!ELEMENT SLO (POS, ALT?, ALT_MSL?, H_ACC?, V_ACC?, TIME, G_SPEED?,V_SPEED?, DIR?, COURSE?, H_ORIENT?, V_ORIENT?)><!ELEMENT POS (LAT, LONG)><!ELEMENT LAT (#PCDATA)><!ELEMENT LONG (#PCDATA)><!ELEMENT ALT (#PCDATA)><!ELEMENT ALT_MSL (#PCDATA)><!ELEMENT H_ACC (#PCDATA)><!ELEMENT V_ACC (#PCDATA)><!ELEMENT TIME (#PCDATA)><!ELEMENT G_SPEED (#PCDATA)><!ATTLIST G_SPEED unit (ms|kmh|mph|knot) "ms"><!ELEMENT V_SPEED (#PCDATA)><!ATTLIST V_SPEED unit (ms|kmh|mph|knot) "ms"><!ELEMENT DIR (#PCDATA)><!ELEMENT COURSE (#PCDATA)><!ELEMENT H_ORIENT (#PCDATA)><!ELEMENT V_ORIENT (#PCDATA)>

Table 5 XML DTD for the common spatial location data set

11.5.3.2 XML Schema for the Common Spatial Location Data Set

The XML Schema for the common spatial location data set can be found

below, in Table 6. The schema is publicly available at http://www-

nrc.nokia.com/ietf-spatial/2001/05/08/location.xsd

<?xml version="1.0"?><xsd:schema targetNamespace="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location" xmlns:this="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="SLO" type="this:LocationData"/><xsd:complexType name="LocationData">

<xsd:sequence><xsd:element name="POS" type="this:POSType"/><xsd:element name="ALT" type="xsd:decimal" minOccurs="0"/><xsd:element name="ALT_MSL" type="xsd:decimal" minOccurs="0"/>



<xsd:element name="H_ACC" type="this:NonNegativeDecimal"minOccurs="0"/>

<xsd:element name="V_ACC" type="this:NonNegativeDecimal"minOccurs="0"/>

<xsd:element name="TIME" type="xsd:dateTime"/><xsd:element name="G_SPEED" type="this:Speed" minOccurs="0"/><xsd:element name="V_SPEED" type="this:Speed" minOccurs="0"/><xsd:element name="DIR" type="this:DegreesFromNorth"

minOccurs="0"/><xsd:element name="COURSE" type="this:DegreesFromNorth"

minOccurs="0"/><xsd:element name="H_ORIENT" type="this:DegreesFromNorth"

minOccurs="0"/><xsd:element name="V_ORIENT" type="this:PlusMinus180Decimal"

minOccurs="0"/></xsd:sequence>

</xsd:complexType><xsd:complexType name="POSType">

<xsd:sequence><xsd:element name="LAT" type="this:LATType"/><xsd:element name="LONG" type="this:LONGType"/>

</xsd:sequence></xsd:complexType><xsd:simpleType name="LATType">

<xsd:restriction base="xsd:string"><xsd:pattern value="(N|S)((\d|[0-8]\d)\.([0-5]\d)\.[0-

5]\d(\.\d+)?)|90\.00\.00(\.0+)?"/></xsd:restriction>

</xsd:simpleType><xsd:simpleType name="LONGType">

<xsd:restriction base="xsd:string"><xsd:pattern value="(E|W)((\d|\d\d|[0-1][0-7]\d)\.([0-5]\d)\.[0-

5]\d(\.\d+)?)|180\.00\.00(\.0+)?"/></xsd:restriction>

</xsd:simpleType><xsd:simpleType name="DegreesFromNorth">

<xsd:restriction base="xsd:string"><xsd:pattern value="(M?|T)((\d|\d\d|[0-3][0-

5]\d)(\.\d+)?)|(360(\.0+)?)"/></xsd:restriction>

</xsd:simpleType><xsd:simpleType name="PlusMinus180Decimal">

<xsd:restriction base="xsd:decimal"><xsd:minInclusive value="-180"/><xsd:maxInclusive value="180"/>

</xsd:restriction></xsd:simpleType><xsd:simpleType name="NonNegativeDecimal">

<xsd:restriction base="xsd:decimal"><xsd:minInclusive value="0"/>

</xsd:restriction></xsd:simpleType><xsd:simpleType name="SpeedUnit">

<xsd:restriction base="xsd:string"><xsd:enumeration value="ms"/><xsd:enumeration value="kmh"/><xsd:enumeration value="mph"/><xsd:enumeration value="knot"/>

</xsd:restriction></xsd:simpleType><xsd:complexType name="Speed">

<xsd:simpleContent><xsd:extension base="this:NonNegativeDecimal">



<xsd:attribute name="unit" type="this:SpeedUnit"default="ms"/>

</xsd:extension></xsd:simpleContent>

</xsd:complexType></xsd:schema>

Table 6 XML Schema for the common spatial location data set

11.5.4 XML Examples of the Common Spatial Location Data Set

Below, in Table 7, is an example XML instance of the common spatial

location data set using XML Schema.

<?xml version="1.0" encoding="UTF-8"?><loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location.xsd"><POS>

<LAT>N60.08.00.235556</LAT><LONG>E025.00.00</LONG>

</POS><ALT>+12.99</ALT><ALT_MSL>010</ALT_MSL><H_ACC>50</H_ACC><V_ACC>2.5</V_ACC><TIME>2001-01-01T12:00:01+02:00</TIME><G_SPEED>2.0</G_SPEED><V_SPEED unit="knot">1</V_SPEED><DIR>M240</DIR><COURSE>M30</COURSE><H_ORIENT>T25</H_ORIENT><V_ORIENT>179</V_ORIENT>

</loc:SLO>

Table 7 XML instance of the common spatial location data set using XML Schema

Table 8 gives another example where the DTD is used.

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE IETF_SLO_Default PUBLIC "-//IETF//SLO default//EN""http://www-nrc.nokia.com/ietf-spatial/2001/05/08/slo_default.dtd"><loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"><POS>

<LAT>N60.08.00.235556</LAT><LONG>E025.00.00</LONG>

</POS><ALT>+12.99</ALT><ALT_MSL>010</ALT_MSL><H_ACC>50</H_ACC><V_ACC>2.5</V_ACC><TIME>2001-01-01T12:00:01+02:00</TIME><G_SPEED>2.0</G_SPEED><V_SPEED unit="knot">1</V_SPEED>

12. A Common Way of Expressing Location Data Sets 56


<DIR>M240</DIR><COURSE>M30</COURSE><H_ORIENT>T25</H_ORIENT><V_ORIENT>179</V_ORIENT>

</loc:SLO>

Table 8 XML instance of the common spatial location data set using DTD

12. A COMMON WAY OF EXPRESSING LOCATION DATA SETS

The common spatial location data set was designed in order to enable

location-based/dependent applications and services to have a common

vocabulary in the Internet. However, studies show that location information can

be expressed in very many different ways (see e.g. Chapter 6), and additionally

that different applications require different location information. Thus, it will not

be possible for all applications to restrict themselves to the use of only the

common spatial location data set. It is necessary to enable also the use of other

location data sets. If there is a common structure and way of encoding, naming,

and registering these data sets, the identification, processing, and

transformation of the data sets are unified leading also to interoperability. In this

chapter we will discuss these different aspects of a common way of expressing

different location data sets.

12.1 Common Structure and Encoding

A common structure and encoding of the different data sets will simplify the

processing. This will enable the use of the same processing tools. Principally

the common encoding and structure can be seen as a common envelope for the

data sets (see Figure 17). The location data set in the common envelope could

principally even be encoded in different ways, but this would complicate the

processing of the set, since specific processing tools are then required to

process the contents (more about this in Section 12.3).



Figure 17 A common structure, encoding, naming and registering of location

data sets

12.2 Common Naming and Registering

If each data set has a unique identifier, the different data sets can be

identified (see Figure 17). The naming scheme should be a common one in

order to process identifiers easily. A common unique identifier simplifies the

processing and possible transformation between different location data sets. It

could be based on URIs (Unified Resource Identifiers).

So as to enable transformations between data sets, the syntax and

transformation rules for the data sets must be previously known. It is therefore

preferable to have a common registration authority for registering data sets that

are meant for public use. The European Petroleum Survey Group (EPSG)

[EPS01] currently maintains a registry of most of the commonly used coordinate

reference systems along with the coordinate transformation parameters. The

Open GIS Consortium uses this as a starting point for the OpenGIS Coordinate

Transformation Services Specification [OGC00]. The authority for this could e.g.

be one of the previously mentioned ones, or IANA (Internet Assigned Numbers

Authority). Transformation services could then check the data sets and the

transformation rules with the registration authority.

12.3 Possible Additional Data to Enable Processing

It can be valuable to include other information than the data set ID/name for

describing the data set. This could be done in a header of the data set, or

possible as external metadata identified by the unique ID/name of the data set.

Location Data Set

Location data elements

ID

Registering authority

Transformationservice

Registeringfor public use

Common namingscheme

Common structureand encoding



This includes information such as, owner, version, content type (e.g. XML,

binary), and encoding (e.g. UTF-8, base64, etc.) (Figure 18). This kind of

scheme could support several types of content in the content envelope. This

type of scheme was partially implemented in the common syntax and encoding

for descriptive location [Tan01b].

Figure 18 Information relevant for the processing of a location data set

12.4 XML as a Common Way of Coding Location Data Sets

As presented in Chapter 7 there are many different ways of expressing

location information. Several of the data sets are targeted for different

applications and their data sets may thus vary. When looking at how different

location data sets are currently encoded and at the availability of processing

tools, XML seems to be a strong candidate for a common way of encoding

different data sets. If XML is used, standard tools can be used for the

processing. XML also enables extendibility of existing data sets.

12.4.1 Example of a Common Way of Expressing Location Data Sets

In this section some initial considerations on how XML could be used for a

common way of expressing location data sets is presented, with the help of the

example in Table 9. The XML root element (here DLS-FIN1:dls-finnish1)

works as the common envelope. Principally the contents within the envelope

could be encoded in any suitable way. The common naming scheme for

identifying the data set could be based on the namespace URL of the data set

Name/ID

OwnerVersion

Content type

Encoding

Location Data Set


Location Data Set


Location Data Set




(dark area in Table 9) or the schema location reference (if the schema location

is required in an XML instance, for an example see Table 7). An attribute for the

ID/name could also be introduced in the root element of the data set, a bit like

the srsName attribute in GML 2.0 [Cox00]. Other attributes in the root element

could include the processing data. The example in Table 9 includes the

attributes DL-Type, Charaset, and Time.

<?xml version="1.0" encoding="UTF-8"?><DLS-FIN1:dls-finnish1 xmlns:DLS-FIN1="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/dls-finnish1" DL-Type="featured" Charaset="UTF-8"Time="1999-08-15T11:16:31.0+2:00">

<f1-level1><Street>Samitie 8</Street><Apartment>D 35</Apartment>

</f1-level1><f1-level2>

<Postal-code>00900</Postal-code><Metropolitan-Area>Helsinki</Metropolitan-Area>

</f1-level2><Country>Finland</Country>

</DLS-FIN1:dls-finnish1>

Table 9 An example of adding naming and processing data into a data set in XML

12.5 Extendibility of Data Sets Encoded in XML

Many applications might want to extend the common spatial location data set

with elements of their own. In this chapter the mechanisms XML offers for

extending a data set is briefly presented. The presentation concentrates on

extendibility with the help of XML Schemas. It enables much richer extendibility

than XML DTDs26, and is expected to be the future way of validating XML

documents.

12.5.1 Extendibility with XML Schema

The XML Schema definition language [Fal01] offers facilities for describing

the structure and constraining the contents of XML 1.0 documents. The schema

language, which is itself defined in XML 1.0 and uses namespaces,

26 The following possibilities to extend a data set represented by a DTD exist. A data set

represented by a new DTD can refer to external DTDs as long as the root elements of the

referred DTDs are somewhere in the tree structure of the new DTD. Another possibility is to

refer to external DTDs in an instance of an XML document.



substantially reconstructs and considerably extends the capabilities found in

XML 1.0 document type definitions (DTDs).

An XML Schema declares the XML elements, element attributes, and defines

their types. This is done in a hierarchical way starting from the XML root

element going down the XML element tree. Elements that contain subelements

or carry attributes are said to have complex types, whereas elements that

contain numbers (and strings, and dates, etc.) but do not contain any

subelements are said to have simple types. Attributes always have simple

types. The XML Schema definition language provides a rich set of primitive

types (e.g. string, boolean, float, month), and it allows the creation user-defined

simple and complex types. To be able to define unambiguous elements and mix

vocabularies from different schemas, the XML Namespace mechanism [Bra99]

is used in the XML Schema definition language.

The XML Schema definition language enables rich possibilities for reusing,

extending, and redefining an XML Schema or components of it (type definitions,

element or attribute declarations) in other XML Schemas. The include

mechanism can be used for including schema components from other schemas

having the same namespace. The import mechanism can be used for

including schema components from other namespaces. Schemas including

components from other schemas can again be included in other schemas. An

example from [Cox00] visualizes this in Figure 19.

Figure 19 Extending a schema with components from other schemas [Cox00]



Schema-B includes Schema-A from the same namespace foo with include.

Schema-A includes Feature schema from namespace gml with import. This

Feature schema again includes components from the Geometry schema.

In addition to including/importing other schemas or components of them,

internal or referenced (imported/included) type definitions can be extended or

restricted (with extension or restriction elements). There is also the

possibility to redefine types, groups and attribute groups that are obtained from

external schemas with redefine in the same namespace. XML Schema also

provides a mechanism called substitution groups that allows elements to be

substituted for other elements.

12.5.2 Example of Extending the Common Spatial Location Data Set

In this section an example of how to extend the common spatial location data

set is presented. Assume that we have a car application that in addition to the

information provided by the common location data set also needs information

about the size of the positioned car and the type of positioning device the car is

using. For this need we create a new location data set called car_location. This

data set uses the common spatial location data set as basis with the help of the

XML Schema import mechanism and extends it with its own elements. Table

10 shows the XML schema for the car_location data set.

<?xml version="1.0"?><xsd:schematargetNamespace="http://www.hut.fi/~mkorkeaa/schemata/2001/05/08/car"xmlns:this="http://www.hut.fi/~mkorkeaa/schemata/2001/05/08/car"xmlns:slo="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:import namespace="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location" schemaLocation="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location.xsd"/>

<xsd:element name="car_location" type="this:CarLocation"/><xsd:complexType name="CarLocation">

<xsd:sequence><xsd:element name="car_size" type="xsd:positiveInteger"/><xsd:element name="pos_device" type="xsd:string"/><xsd:element ref="slo:SLO"/>

</xsd:sequence></xsd:complexType>

</xsd:schema>

Table 10 car_location data set extending on the common spatial location data set



Table 11 shows an XML instance of the car_location data set. <?xml version="1.0" encoding="UTF-8"?><car:car_locationxmlns:car="http://www.hut.fi/~mkorkeaa/schemata/2001/05/08/car"xmlns:slo="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.hut.fi/~mkorkeaa/schemata/2001/05/08/car http://www.hut.fi/~mkorkeaa/schemata/2001/05/08/car.xsd">

<car_size>5</car_size><pos_device>gps4everyone</pos_device><slo:SLO>

<POS><LAT>N60.08.00.235556</LAT><LONG>E025.00.00</LONG>


</slo:SLO></car:car_location>

Table 11 An XML instance of the car_location data set

12.5.3 Summary on Extendibility

As shown XML Schema enables rich possibilities for reusing, extending, and

redefining an XML Schema or components of it. This also implies numerous

possibilities for location data sets encoded in XML to use declarations and

definitions from other data sets. In order to prevent different location data sets

having the same name, causing problems for transformation services, each

extended or changed data set should have a unique name.

The rich extension possibility also creates a possible drawback. Since it is so

easy to create new location data sets, we can end up with thousands of

different ones. This can cause manageability problems, especially for

transformation services of location data sets, since each new data set needs to

have its transformation rules registered.

There will be fewer problems if only complete location data sets, or parts with

clear transformation rules, are included into new location data sets. Another

possibility is to create a separate data set for the new extension data, and

13. A Common Location Payload 63


combine it with the existing location data set with the help of the location

payload described in the next chapter.

13. A COMMON LOCATION PAYLOAD

It might not be possible for all applications to restrict themselves to the use of

only the common spatial location data set or one location data set. Sometimes

the application might want to use elements from several location data sets or

express the location in several ways with the help of different location data sets.

For example, an application might want to express the location with the help of

latitude and longitude as well as with the current street address. Or the

application wants to use elements from the common spatial location data set as

well as from a data set with application-specific extensions. The common

(spatial) location payload was designed to enable this [Kor01c]. The payload is

a common container to carry any location data set and associated data, e.g.

elements from the common spatial location data set [Kor01b], from the

descriptive location data set defined in [Tan01b], or from any other location data

set.

The advantage of the payload is that there will be a general way of

expressing collections of location data sets and associated data, enabling

interoperability between applications and the use of common tools. The payload

will enable a location to be expressed in many different ways, or to combine

different location data sets (e.g. enable application-specific extensions to

existing location data sets). The payload was designed only as a common

container independent of any specific protocol.

13.1 The Elements and Structure of the Location Payload

The payload can include any number of location data sets (Figure 19) and

their associated elements. It could e.g. contain the SLO common spatial

location set [Kor01b] and some application-specific extensions to SLO27. The

formal ABNF notation of the payload structure can be found in [Kor01c].

27 Note: Instead of combining SLO common spatial location set and the application-specific

extensions in the payload, SLO and the extensions can be defined as a common data set using

DTD/XML Schema extension mechanisms.



Figure19 The structure of the payload and a payload example

The payload is a data container, without any header information, e.g. for

identifying starting points of the different data sets, or describing the contents of

the data sets. This kind of data could be attached to the beginning of the

container or defined separately, e.g. by the payload transfer protocol.

13.2 Encoding of the Location Payload

XML or MIME was considered for encoding the location payload. It was

decided that XML should be used, since so many location data sets are using

XML and this enables the usage of the same processing tools. The structure of

the current payload is very simple. It consists of a container indicated by the

element <Location-Payload>. The different location data sets are identified

as the child elements of the <Location-Payload> element. Examples of the

payload will be given in Section 13.2.1 and 13.2.2, using DTDs and XML

Schemas respectively.

Principally the payload can carry any location data set encoded in any way

as long as it is packed in an XML container as suggested in the previous

chapter. As pointed out, the payload is only a data container without any header

information. Header information for the different data sets could be carried by

the data sets themselves according to the methods presented in Section 12.3.

The different location data sets are currently identified by the DTD URI or public

Elements oflocation data set 1


Elements oflocation data set n

...

Payload Structure

Elements ofCommon Location

Data Set SLO

Extensions toSLO

Payload Example




...

Payload Structure




...




...

Payload Structure


Data Set SLO

Extensions toSLO

Payload Example


Data Set SLO

Extensions toSLO

Payload Example



identifier in the DTD-based solution, and the schema URI or namespace in the

XML Schema-based solution.

13.2.1 DTD-Based Solution

For correct parsing, only the DTDs for the different location data sets carried

in the payload are needed. Below in Table 12 an example is given. It carries two

location data sets, the common location data set SLO [Kor01b] and a

descriptive location data set dls-finnish1 (defined in [Tan01b]).

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE Location-Payload [<!ENTITY % slo-default-dtd PUBLIC "-//IETF//SLO-Default//EN""http://www-nrc.nokia.com/ietf-spatial/2001/05/08/slo_default.dtd"><!ENTITY % dls-finnish1-dtd PUBLIC "-//FIN//DESCRIPTIVE-Location//EN""http://www-nrc.nokia.com/ietf-spatial/2001/05/08/dls-finnish1.dtd">%slo-default-dtd;%dls-finnish1-dtd;<!ELEMENT Location-Payload (SLO, dls-finnish1)>]><Location-Payload><SLO>


</POS><ALT>+12.99</ALT><ALT_MSL>010</ALT_MSL><H_ACC>50</H_ACC><V_ACC>2.5</V_ACC><TIME>2001-01-01T12:00:01+02:00</TIME>

</SLO><dls-finnish1 DL-Type="featured" Charaset="UTF-8" Time="unknown">

<f1-level1><Street>Samitie 8</Street><Apartment>D 35</Apartment>

</f1-level1><f1-level2>

<Postal-code>00900</Postal-code><Metropolitan-Area>Helsinki</Metropolitan-Area>

</f1-level2><Country>Finland</Country>

</dls-finnish1></Location-Payload>

Table 12 An example XML location payload using DTDs

In order to avoid conflicts in the payload, the elements of the different

location data sets in the payload should be unique. This can be achieved by

using XML namespaces [Bra99].



13.2.2 XML Schema-Based Solution

For correct parsing, only the XML Schemas defined for the different location

elements carried in the payload are needed. Below in Table 13 an example is

given. It carries two location data sets, the common spatial location data set

SLO [Kor01b] and a data set defining some specific elements for a car

application (the schema for the data set can be found in Appendix A.2 in

[Kor01c]).

<?xml version="1.0" encoding="UTF-8"?><Location-Payload><loc:SLO xmlns:loc="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location http://www-nrc.nokia.com/ietf-spatial/2001/05/08/location.xsd">



</loc:SLO><car:car-data xmlns:car="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/car" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www-nrc.nokia.com/ietf-spatial/2001/05/08/car http://www-nrc.nokia.com/ietf-spatial/2001/05/08/car.xsd">

<car_orientation><x>360</x><y>40</y><z>20</z>

</car_orientation><hardware>

<gps>gps4everyone

</gps></hardware>

</car:car-data></Location-Payload>

Table 13 An example XML location payload using XML Schemas

14. Other Issues Related to Location Information 67


14. OTHER ISSUES RELATED TO LOCATION INFORMATION

Location information privacy and security – Location alone usually means

nothing but a “point” somewhere. However, when associated with a meaningful

target such as a person, the location is potentially private or sensitive, even

though some parties may like to release their location information to the public.

There must be privacy, security and policy mechanisms available to protect the

location information.

The privacy issues have been widely discussed, but the technological

solutions for providing location privacy are still in their infancy. There will be

privacy mechanisms for the location services in the mobile networks. For GSM

networks they are described in [ETS00]. Governmental agencies and industry

associations in the USA and Europe have addressed the location information

privacy in different petitions, draft directives, etc., e.g. in [CEC00], [CTI00]. They

bring up issues such as: the user should give prior consent to being located, the

user should be notified when located, the user should know who is locating, it

should be possible for the user to change location options at any time, the

location information should be sent in a secure manner, and it is important to be

able to control that the location information is used only for stated use and only

by those having the right to use the information.

To fulfill these kinds of privacy requirements, the following kinds of

mechanisms need to be implemented on location information protocol or on the

application level: authentication of location requester and location source, data

confidentiality, integrity and non-repudiation mechanisms, policy rules on who is

allowed to access what information at what granularity, request authorization,

and non-replication of location data.

Common methods are needed to handle privacy of location information in the

Internet. It will then be easier for locatable targets (users) to control in a

common way who is accessing what information from what source. The first

steps in this direction have been taken by the new working group Geographic

Location/Privacy (geopriv) in IETF [GLP00], as well as by LIF [LIF01]. The

privacy issue is very complex. How privacy can be handled depends on the type

of location application and how the location information is provided and used in

15. Conclusion and Future Work 68


the application. Privacy can be handled in a common way if there is a common

way of obtaining location information in the Internet.

Billing – In future location information sources will probably want to be able

to charge for the location information they provide to services. Common billing

mechanisms will therefore need to be specified.

Transformation services – If several location data sets are used

transformation services will be required. Transformation services could be

offered as a service in the Internet.

15. CONCLUSION AND FUTURE WORK

As shown in this thesis there are many organizations currently working on

location-related technologies, different location expression formats, and ways of

providing location information to applications in the Internet. In one way this is

good, because this will cause progress in this field, but on the other hand, there

is a risk that we will end up with many different non-interoperable location

information formats and ways of providing location information to applications.

From an Internet point of view, where we want to achieve openness and

interoperability, it would be good to have common interoperable solutions. For

reaching such solutions, cooperation between different location standardization

activities will be essential. One leading activity ought to provide a common

solution for the Internet. The Internet Engineering Task Force (IETF) should

preferably lead this activity, since it is the most important standardization

organization for the Internet.

Interoperability can be reached on the level of a common way of expressing

location information and on the level of a common way of obtaining location

information. This work focuses on a common way of expressing location

information, since this appears to be the easiest level to deploy and reach

interoperability on. Detailed considerations for a common way of obtaining

location information are left for the future.

If we can agree on a common way of expressing location information, we can

reach interoperability of location information in applications. This means that

applications could use location information from different location information

15. Conclusion and Future Work 69


sources and use the same tools, parsers, and processing methods to process

the information.

The interoperability of location information can be tackled in different ways.

The work proposes a common location data set that can be used by

applications to enable interoperability. Because of the numerous ways of

expressing location information and the different location information needs of

applications, it will not be enough to provide and support only one common

location data set. A common way of expressing different location data sets is

also needed.

The common way of expressing different location data sets means a common

structure and way of encoding, naming and registering different location data

sets. Such a solution will simplify the identification, processing, and

transformation of the different sets, and enable interoperable processing. The

processing can be improved by including additional processing data into the

header of the data set or optionally as external metadata.

The location applications might need to use several location data sets, or to

express the location in different ways. For this the common location payload, a

container for different location data sets and associated data was designed.

The common way of expressing location information, the common location

data set, and the location payload is proposed to be encoded in XML. This

because XML enables the use of standard processing tools, and provides easy

methods for extending location data sets. In addition, many of the existing

location expressions use XML.

The formats and syntaxes presented in this thesis are proposals, and should

be improved through input from the location technology community and different

standardization organizations.

16. References 70


16. REFERENCES

[3GP00] 3rd Generation Partnership Project (2000). Universal Geographical

Area Description (GAD), Technical Specification, Release 1999, 3G

TS 23.032, v. 3.1.0, May 2000.

[AIM01] AIM (2001). Radio Frequency Identification (RFID) home page.

http://www.aimglobal.org/technologies/rfid/

[And00] Andersson, J. (2000). Definition of A Mobile Location API,

Contribution to Location Inter-operability Forum (LIF), API

Specification, v. 0.2, 13 June 2000.

[ATT01] AT&T Laboratories Cambridge (2001). The Active Badge System,

(last modified 27.2.2001). http://www.uk.research.att.com/ab.html

[Ben00] Bennett, P. (2000). The NMEA FAQ, version 6.3, 25 April 2000.

http://vancouver-webpages.com/pub/peter/nmeafaq.txt

[Bra99] Bray T., Hollander, D., and Layman, A. (1999). Namespaces in

XML, World Wide Web Consortium, 14 January 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114

[Bra00] Bray, T., Paoli, J., Sperberg-McQueen, C.M., and Maler, E. (2000).

Extensible Markup Language (XML) 1.0 (Second Edition), W3C

Recommendation, 6 October 2000.

http://www.w3.org/TR/2000/REC-xml-20001006

[Bri00] Brickley, D., and Guha, R.V. (2000). Resource Description

Framework (RDF) Schema Specification 1.0, W3C Candidate

Recommendation, 27 March 2000. http://www.w3.org/TR/2000/CR-

rdf-schema-20000327/

[Bör00] Börjesson, J. (2000). GLONASS Information, (last modified

17.11.2000). http://www.oso.chalmers.se/~geo/glonass.html

16. References 71


[CEC00] Commission of the European Communities (2000). Proposal for a

Directive of the European Parliament and of the Council concerning

the processing of personal data and the protection of privacy in the

electronic communications sector, COM(2000) 385, Brussels, July

2000.

http://europa.eu.int/comm/information_society/policy/framework/pdf/

com2000385_en.pdf

[Cox00] Cox, S., Cuthbert, A., Lake, R., and Martell, R. (Eds.) (2000).

Geography Markup Language (GML) 2.0, OpenGIS Implementation

Specification, OGC Document Number: 01-029, 20 February 2001.

http://www.opengis.net/gml/01-029/GML2.html

[Dah99] Dahlin, M., and Krook, P. (1999). Mobile Positioning - Aspects and

Trends. Department of Industrial Dynamics, Chalmers University of

Technology, Gothenburg, Sweden.

http://www.kipling.se/upload/mobile_positioning.pdf

[CTI00] Cellular Telecommunications & Internet Association (CTIA) (2000).

Petition of the Cellular Telecommunications Industry Association for

a Rulemaking to Establish Fair Location Information Practices,

CTIA petition to FCC, November 2000. http://www.wow-

com.com/pdf/ctia112200.pdf

[Dan99a] Dana, P. H. (1999). Coordinate Systems Overview, Department of

Geography, University of Texas at Austin, July 1995 (last modified

15.12.1999).

http://www.colorado.Edu/geography/gcraft/notes/coordsys/coordsys

_f.html

[Dan99b] Dana, P. H. (1999). Geodetic Datum Overview, Department of

Geography, University of Texas at Austin, (last modified

15.12.1999).

http://www.colorado.Edu/geography/gcraft/notes/datum/datum_f.ht

ml

16. References 72


[Dan00] Dana P. H. (2000). Global Positioning System Overview, (last

modified 5.1.2000).

http://www.colorado.edu/geography/gcraft/notes/gps/gps.html

[Dav01a] Daviel, A., and Kaegi, F.A. (2001). Geographic registration of HTML

documents, Internet draft, Internet Engineering Task Force, work in

progress, April 2001. http://geotags.com/geo/draft-daviel-html-geo-

tag-05.txt

[Dav01b] Daviel, A., and Kaegi, F.A. (2001). Geographic extensions for HTTP

transactions, Internet draft, Internet Engineering Task Force, work

in progress, April 2001. http://geotags.com/geo/draft-daviel-http-

geo-header-03.txt

[Davi96] Davis, C., Vixie, P., Goodwin, T., and Dickinson, I. (1996). A Means

for Expressing Location Information in the Domain Name System,

RFC 1876, Internet Engineering Task Force, January 1996.

ftp://ftp.funet.fi/pub/doc/rfc/rfc1876.txt

[Daw98a] Dawson, F., and Howes, T. (1998). vCard MIME Directory Profile,

RFC 2426, Internet Engineering Task Force, September 1998.

http://www.imc.org/rfc2426

[Daw98b] Dawson, F., and Stenerson, D. (1998), Internet Calendaring and

Scheduling Core Object Specification (iCalendar), RFC 2445,

Internet Engineering Task Force, November 1998.

http://www.imc.org/rfc2445

[EPS01] European Petroleum Survey Group (2001). Petroconsultants

distributes: EPSG Geodesy Parameters version 4.4, 19th

November 1999, (last modified 14.3.2001).

http://geps2.ihsenergy.com/products/geodetic2.html

16. References 73


[ETS00] European Telecommunications Standards Institute (ETSI) (2000).

Digital cellular telecommunications system (Phase 2+); Location

Services (LCS); (Functional description) - Stage 2, (GSM 03.71

version 8.0.0 Release 1999), Technical Specification, ETSI TS 101

724 V8.0.0, October 2000.

http://webapp.etsi.org/pda/home.asp?wki_id=11817

[Fal01] Fallside, D.C. (ed.) (2001). XML Schema Part 0: Primer. W3C

Recommendation, 2 May 2001. http://www.w3.org/TR/xmlschema-

0/

[FCC99] FCC (1999). Third Report & Order, FCC 99-245, FCC, Washington

DC, 6 October 1999.

[Fre96a] Freed, N., and Borenstein, N. (1996). Multipurpose Internet Mail

Extensions (MIME) Part One:Format of Internet Message Bodies,

RFC2045, Internet Engineering Task Force, November 1996.

http://www.ietf.org/rfc/rfc2045.txt?number=2045

[Fre96b] Freed, N., and Borenstein, N. (1996). Multipurpose Internet Mail

Extensions (MIME) Part Two: Media Types, RFC2046, Internet

Engineering Task Force, November 1996.


[Fre96c] Freed, N., Klensin, J., and Postel, J. (1996). Multipurpose Internet

Mail Extensions (MIME) Part Four: Registration Procedures,

RFC2048, Internet Engineering Task Force, November 1996.


[Gal01] Gallileo Project (2001). Gallileo - Global Navigation Satellite

System, project home page, (last modified 26.6.2001).

http://www.galileo-pgm.org/

[Gar01] Garmash, A. (2001). A geographic XML-based format for the mobile

environment, Hawaii International Conference on System Sciences,

16. References 74


HICSS-34, Hawaii, 3-6 January 2001.

http://www.cs.jyu.fi/~mmm/documents/garmash_0101.pdf

[GLP00] Geographic Location/Privacy IETF Working Group (2001). Home

page of the IETF working group Geographic Location/Privacy

(geopriv). http://www.ietf.org/html.charters/geopriv-charter.html

[GEO01] GEOPlace.com (2001). Business Geographics, Location-based

Services: A Complete Guide to Companies and Organizations.

http://www.geoplace.com/bg/2001/0101/0101lbs.asp

[Get01] Getty (2001). About the Thesaurus of Geographic Names (TGN),

(last modified 28.6.2001).

http://www.getty.edu/research/tools/vocabulary/tgn/about.html

[Hef00] Heflin, J., and Hendler, J. (2000). Semantic Interoperability on the

Web, Proceedings of Extreme Markup Languages 2000, 15-18

August 2000.

http://www.cs.umd.edu/projects/plus/SHOE/pubs/extreme2000.pdf

[IGE00] Interagency GPS Executive Board (2000). President Ends Selective

Availability Effective Midnight on May 1, 2000.

http://www.igeb.gov/sa/

[ISO97] International Organization for Standardization / Organisation

Internationale de Normalisation (ISO) (1997). Standard ISO 3166-

1:1997: Codes for the representation of names of countries and

their subdivisions - Part 1: Country codes.

http://www.din.de/gremien/nas/nabd/iso3166ma/

[ISO98] International Organization for Standardization / Organisation

Internationale de Normalisation (ISO) (1998). Standard ISO 3166-

2:1998: Codes for the representation of names of countries and

their subdivisions - Part 2: Country subdivision.

http://www.din.de/gremien/nas/nabd/iso3166ma/

16. References 75


[Kan99] Kanemitsu, H., and Kamada, T. (1999). POIX: Point Of Interest

eXchange Language Specification, Note submitted to W3C, 24

June 1999. http://www.w3.org/TR/poix

[Kor01a] Korkea-aho, M., and Tang, H. (2001). A Common Data Set and

Framework for Representing Spatial Location Information in the

Internet, Special Issue on Spatial Location in Networking, Cluster

Computing Journal, Baltzer Science Publishers, accepted for

publishing 2001.

[Kor01b] Korkea-aho, M., Tang, H., Racz, D., Polk, J., and Takahashi, K.

(2001). A Common Spatial Location Data Set, Internet draft,

Internet Engineering Task Force, work in progress, May 2001.

http://www.ietf.org/internet-drafts/ draft-korkea-aho-spatial-dataset-

01.txt

[Kork01c] Korkea-aho, M., and Tang, H. (2001). Spatial Location Payload,

Internet draft, Internet Engineering Task Force, work in progress,

May 2001. http://www.ietf.org/internet-drafts/ draft-korkea-aho-

spatial-location-payload-00.txt

[Kuh95] Kuhn, M. (1995). A Summary of the International Standard Date

and Time Notation, (last modified 17 4 2000).

http://www.cl.cam.ac.uk/~mgk25/iso-time.html

[Lak00] Lake, R., and Cuthbert, A. (eds.) (2000). Geography Markup

Language (GML) v1.0, Open GIS Consortium, Document Number:

00-029, 12 May 2000. http://www.opengis.net/gml/00-029/GML.html�

[Lan01] LandXML.org (2001). LandXML Schema Version 0.88

Documentation, 8 February 2001.

http://www.landxml.org/schema/LandXML-

0.88/Documentation/LandXMLDocu.html

16. References 76


[Las99] Lassila, O., and Swick, R. (1999). Resource Description

Framework (RDF) Model and Syntax, W3C Recommendation, 22

February 1999. http://www.w3.org/TR/REC-rdf-syntax-

19990222.html

[LIF01] Location Inter-operability Forum (2001). What's LIF ?, LIF

Statement, (referred to 29.5.2001).

http://www.locationforum.org/About_LIF/About_LIF.htm

[Lou00] Loughney, J., and Costa-Requena, J. (2000). Basic SLoP

Architecture Proposal, Internet draft, Internet Engineering Task

Force, work in progress, July 2000. http://www-nrc.nokia.com/ietf-

spatial/draft-loughney-spatial-arch-00.txt

[Läh01] Lähteenmäki, J., Laitinen, H., Nordström, T. (2001). Location

Methods. VTT Information Technology, 2001.

http://location.vtt.fi/source/technologies.html

[Mah00] Mahy, R. (2000). A Simple Text Format for the Spatial Location

Protocol (SLoP), Internet draft, Internet Engineering Task Force,

work in progress, July 2000. http://www-nrc.nokia.com/ietf-

spatial/draft-mahy-spatial-simple-coord-00.txt

[Men01] Mentor Software Inc. (2001). Norm's GIS Glossary.

http://www.mentorsoftwareinc.com/resource/glossary.htm

[MIT99] MIT MediaLab (1999). LOCUST, An Experiment in Private

Localization, (last modified 11.2.1999).

http://wearables.www.media.mit.edu/projects/wearables/locust/

[NIM97] National Imagery and Mapping Agency (1997). Department of

Defense World Geodetic System 1984: Its Definition and

Relationships with Local Geodetic Systems, NIMA TR8350.2, Third

Edition, Bethesda, MD, 4 July 1997 (updated 3 January 2000).

ftp://164.214.2.65/pub/gig/tr8350.2/wgs84fin.pdf

16. References 77


[OGC00] Open GIS Consortium (2000). Coordinate Transformation Services

Specification, (last modified 12.01.2000).

http://www.opengis.org/datasheets/Dat09CoordTran00516.htm

[Par96] Parkinson, B.W., and Spilker, J.J. Jr (eds.) (1996), Global

Positioning System: Theory and Applications, Vol. 1, American

Institute of Aeronautics and Astronautics, Inc., Washington DC.

[Ran00] Rantalainen, T., Spirito, M., and Ruutu, V. (2000). Evolution of

Location Services in GSM and UMTS Networks, Proceedings of the

3rd International Symposium on Wireless Personal Multimedia

Communications (WPMC'00), 12-15 November 2000, Bangkok,

Thailand, pp.1027-1032.

[Ros00] Rosen, B., Costa-Requena, J., Korkea-aho, M., Ylianttila, M., Mahy,

R., Takahashi, K., and Farrell, S. (2000). Spatial Location Protocol

Requirements, Internet draft, Internet Engineering Task Force, work

in progress, July 2000. http://www-nrc.nokia.com/ietf-spatial/draft-

ietf-spatial-requirements-00.txt

[Sek99] Sekiguchi, M., et al. (1999). NaVigation Markup Language (NVML),

Note submitted to W3C, 6 August 1999.

http://www.w3.org/TR/NVML

[SLo00a] SLoP activity (2000). Spatial Location Working Group, Description

of Working Group (v00). http://www-nrc.nokia.com/ietf-

spatial/charter-items-v031.txt

[SLo00b] SLoP activity (2000). Spatial Location BOF (spatial) of IETF, (last

modified 11.8.2000). http://www-nrc.nokia.com/ietf-spatial/

[Swe99] Swedberg, G. (1999). Ericsson’s Mobile Location Solution. Ericsson

Review No. 4, 1999.

http://www.ericsson.com/review/1999_04/article93.shtml

16. References 78


[Tan00a] Tang, H. (ed.) (2000). Charter for the Would-be BOF (v00), 26

January 2000. http://www-nrc.nokia.com/ip-location/charter-

v00.html

[Tan00b] Tang, H., Polk, J., Korkea-aho, M., and Takahashi, K. (2000).

Spatial Location Payload Requirements with Protocol

Recommendations, Internet draft, Internet Engineering Task Force,

work in progress, November 2000. http://www-nrc.nokia.com/ietf-

spatial/draft-tang-spatial-payload-reqs-00.txt

[Tan01a] Tang, H., Korkea-aho, M., Costa-Requena, J., and Ruutu, J. (2001).

Serving Spatial Location Information over the Internet, Proceedings

of the Mobile Data Management, Second International Conference,

MDM 2001, Hong Kong, China, January 2001, pp.246-251.

[Tan01b] Tang, H., and Korkea-aho, M. (2001). Common Syntax and Coding

for Descriptive Location, Internet draft, Internet Engineering Task

Force, work in progress, May 2001. http://www.ietf.org/internet-

drafts/draft-tang-spatial-descriptive-location-00.txt

[T3G01] The 3G Portal (2001). 3G Links Database, Home : Industry

Information : Software Applications : Location Services.

http://www.the3gportal.com/pages/Industry_Information/Software_A

pplications/Location_Services/more1.html

[ver96] versit Consortium (1996). vCard - The Electronic Business Card

Version 2.1, versit Consortium Specification, 18 September 1996.

http://www.imc.org/pdi/vcard-21.txt

[WAP99] WAP Forum, Wireless Application Group (1999). User Agent Profile

Specification, WAG UAPROF, 10 November1999.

http://www1.wapforum.org/tech/terms.asp?doc=WAP-174-UAProf-

19991110-a.pdf

16. References 79


[Wer99] Werb, J. (1999). Seven Ways to Track Your Assets, March 1999,

(last modified 4.4.2000).

http://www.idsystems.com/reader/1999_03/seve0399.htm

[Wie01] Wieland, K. (2001). Is time running out for the GSM SIM toolkit?,

Telecommunications.Online, January 2001. http://www.telecoms-

mag.com/issues/200101/tci/34_time_running.html

[Wol97] Wolf, M., and Wicksteed, C. (1997). Date and Time Formats, Note

submitted to W3C, 15 September 1997.

http://www.w3.org/TR/1998/NOTE-datetime-19980827

[Zil00] Zillikens, F. (2000). WAP Location DC Scope. Presentation at

Spatial Location BOF, 47th IETF Meeting, Adelaide, Australia, 26-

31 March 2000. http://www-nrc.nokia.com/ietf-

spatial/WAPLocationDC_Info_to_IETF.ppt

APPENDIX A - LIST OF PUBLICATIONS 80


APPENDIX A - LIST OF PUBLICATIONS

Reviewed publications 1. Haitao Tang, Mari Korkea-aho, Jose Costa-Requena, and Jussi

Ruutu, Serving Spatial Location Information over the Internet,

Proceedings of the Mobile Data Management, Second International

Conference, MDM 2001, Hong Kong, China, 7-10 January 2001,

pp.246-251.

2. Mari Korkea-aho and Haitao Tang, A Common Data Set and

Framework for Representing Spatial Location Information in the

Internet, Special Issue on Spatial Location in Networking, Cluster

Computing Journal, Baltzer Science Publishers, accepted for

publishing 2001.

Internet drafts 3. Mari Korkea-aho, Haitao Tang, David Racz, James M. Polk, and Kenji

Takahashi, A Common Spatial Location Dataset, Internet draft,

Internet Engineering Task Force, work in progress, May 2001.

http://www.ietf.org/internet-drafts/draft-korkea-aho-spatial-dataset-

01.txt

4. Mari Korkea-aho, and Haitao Tang, Spatial Location Payload, Internet

draft, Internet Engineering Task Force, work in progress, May 2001.

http://www.ietf.org/internet-drafts/draft-korkea-aho-spatial-location-

payload-00.txt

5. Haitao Tang, and Mari Korkea-aho, Common Syntax and Coding for

Descriptive Location, draft-tang-spatial-descriptive-location-00.txt,

Internet draft, Internet Engineering Task Force, work in progress, May

2001. http://www.ietf.org/internet-drafts/draft-tang-spatial-descriptive-

location-00.txt

PUBLICATION 1


Publication 1

PUBLICATION 2


Publication 2

PUBLICATION 3


Publication 3

PUBLICATION 4


Publication 4

PUBLICATION 5


Publication 5

Date post:	14-Feb-2017
Category:	Documents
Upload:	phamhuong
View:	218 times
Download:	1 times

HELSINKI UNIVERSITY OF TECHNOLOGY Department of ...

Documents