draft-ietf-geopriv-pdif-lo-profile-14.txt   rfc5491.txt 
Geopriv J. Winterbottom Network Working Group J. Winterbottom
Internet-Draft M. Thomson Request for Comments: 5491 M. Thomson
Updates: 4119 (if approved) Andrew Corporation Updates: 4119 Andrew Corporation
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: May 29, 2009 Nokia Siemens Networks Nokia Siemens Networks
November 25, 2008 GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-14
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on May 29, 2009. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The Presence Information Data Format Location Object (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise location information. There are, however, circumstances that arise
when information needs to be constrained in how it is represented. when information needs to be constrained in how it is represented.
In these circumstances the range of options that need to be In these circumstances, the range of options that need to be
implemented are reduced. There is growing interest in being able to implemented are reduced. There is growing interest in being able to
use location information contained in a PIDF-LO for routing use location information contained in a PIDF-LO for routing
applications. To allow successful interoperability between applications. To allow successful interoperability between
applications, location information needs to be normative and more applications, location information needs to be normative and more
tightly constrained than is currently specified in the RFC 4119 tightly constrained than is currently specified in RFC 4119 (PIDF-
(PIDF-LO). This document makes recommendations on how to constrain, LO). This document makes recommendations on how to constrain,
represent and interpret locations in a PIDF-LO. This further represent, and interpret locations in a PIDF-LO. It further
recommends a subset of Geography Markup Language (GML) 3.1.1 that is recommends a subset of Geography Markup Language (GML) 3.1.1 that is
mandatory to implement by applications involved in location based mandatory to implement by applications involved in location-based
routing. routing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................3
3. Using Location Information . . . . . . . . . . . . . . . . . . 6 3. Using Location Information ......................................4
3.1. Single Civic Location Information . . . . . . . . . . . . 9 3.1. Single Civic Location Information ..........................7
3.2. Civic and Geospatial Location Information . . . . . . . . 9 3.2. Civic and Geospatial Location Information ..................7
3.3. Manual/Automatic Configuration of Location Information . . 10 3.3. Manual/Automatic Configuration of Location Information .....8
3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11 3.4. Multiple Location Objects in a Single PIDF-LO ..............9
4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 4. Geodetic Coordinate Representation .............................10
5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 5. Geodetic Shape Representation ..................................10
5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15 5.1. Polygon Restrictions ......................................12
5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Shape Examples ............................................13
5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Point ..............................................13
5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Polygon ............................................14
5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.3. Circle .............................................17
5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.4. Ellipse ............................................17
5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.5. Arc Band ...........................................19
5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.6. Sphere .............................................21
5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 25 5.2.7. Ellipsoid ..........................................22
5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.8. Prism ..............................................24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations ........................................26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgments ................................................26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. References .....................................................26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References ......................................26
9.1. Normative references . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References ....................................27
9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Presence Information Data Format Location Object (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
[RFC4119] is the recommended way of encoding location information and [RFC4119] is the recommended way of encoding location information and
associated privacy policies. Location information in a PIDF-LO may associated privacy policies. Location information in a PIDF-LO may
be described in a geospatial manner based on a subset of Geography be described in a geospatial manner based on a subset of Geography
Markup Language (GML) 3.1.1 [OGC-GML3.1.1], or as civic location Markup Language (GML) 3.1.1 [OGC-GML3.1.1] or as civic location
information [RFC5139]. A GML profile for expressing geodetic shapes information [RFC5139]. A GML profile for expressing geodetic shapes
in a PIDF-LO is described in [GeoShape]. Uses for PIDF-LO are in a PIDF-LO is described in [GeoShape]. Uses for the PIDF-LO are
envisioned in the context of numerous location based applications. envisioned in the context of numerous location-based applications.
This document makes recommendations for formats and conventions to This document makes recommendations for formats and conventions to
make interoperability less problematic. make interoperability less problematic.
The PIDF-LO provides a general presence format for representing The PIDF-LO provides a general presence format for representing
location information, and permits specification of location location information, and permits specification of location
information relating to a whole range of aspects of a Target. The information relating to a whole range of aspects of a Target. The
general presence data model is described in [RFC4479] and caters for general presence data model is described in [RFC4479] and caters to a
a presence document to describe different aspects of the reachability presence document to describe different aspects of the reachability
of a presentity. Continuing this approach, a presence document may of a presentity. Continuing this approach, a presence document may
contain several GEOPRIV objects that specify different locations and contain several GEOPRIV objects that specify different locations and
aspects of reachability relating to a presentity. This degree of aspects of reachability relating to a presentity. This degree of
flexibility is important, and recommendations in this document make flexibility is important, and recommendations in this document make
no attempt to forbid the usage of a PIDF-LO in this manner. This no attempt to forbid the usage of a PIDF-LO in this manner. This
document provides a specific set of guidelines for building presence document provides a specific set of guidelines for building presence
documents when it is important to unambiguously convey exactly one documents when it is important to unambiguously convey exactly one
location. location.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The definition for "Target" is taken from [RFC3693]. The definition for "Target" is taken from [RFC3693].
In this document a "discrete location" is defined as a place, point, In this document a "discrete location" is defined as a place, point,
area or volume in which a Target can be found. area, or volume in which a Target can be found.
The term "compound location" is used to describe location information The term "compound location" is used to describe location information
represented by a composite of both civic and geodetic information. represented by a composite of both civic and geodetic information.
An example of compound location might be a geodetic polygon An example of compound location might be a geodetic polygon
describing the perimeter of a building and a civic element describing the perimeter of a building and a civic element
representing the floor in the building. representing the floor in the building.
The term "method" in this document refers to the mechanism used to The term "method" in this document refers to the mechanism used to
determine the location of a Target. This may be something employed determine the location of a Target. This may be something employed
by a location information server (LIS), or by the Target itself. It by a location information server (LIS), or by the Target itself. It
specifically does not refer to the location configuration protocol specifically does not refer to the location configuration protocol
(LCP) used to deliver location information either to the Target or (LCP) used to deliver location information either to the Target or
the Recipient. the Recipient.
The term "source" is used to refer to the LIS, node or device from The term "source" is used to refer to the LIS, node, or device from
which a Recipient (Target or Third-Party) obtains location which a Recipient (Target or Third-Party) obtains location
information. information.
3. Using Location Information 3. Using Location Information
The PIDF format provides for an unbounded number of <tuple>, The PIDF format provides for an unbounded number of <tuple>,
<device>, and <person> elements. Each of these elements contains a <device>, and <person> elements. Each of these elements contains a
single <status> element that may contain more than one <geopriv> single <status> element that may contain more than one <geopriv>
element as a child. Each <geopriv> element must contain at least the element as a child. Each <geopriv> element must contain at least the
following two child elements: <location-info> element and <usage- following two child elements: <location-info> element and <usage-
rules> element. One or more elements containing location information rules> element. One or more elements containing location information
are contained inside a <location-info> element. are contained inside a <location-info> element.
Hence, a single PIDF document may contain an arbitrary number of Hence, a single PIDF document may contain an arbitrary number of
location objects some or all of which may be contradictory or location objects, some or all of which may be contradictory or
complementary. Graphically, the structure of a PIDF-LO document can complementary. Graphically, the structure of a PIDF-LO document can
be depicted as shown in Figure 1. be depicted as shown in Figure 1.
<?xml version="1.0" encoding="UTF-8"?>
<presence> <presence>
<tuple> -- #1 <tuple> -- #1
<status> <status>
<geopriv> -- #1 <geopriv> -- #1
<location-info> <location-info>
location element #1 location element #1
location element #2 location element #2
... ...
location element #n location element #n
<usage-rules> <usage-rules>
skipping to change at page 7, line 51 skipping to change at page 6, line 4
<geopriv> -- #m <geopriv> -- #m
</person> </person>
<tuple> -- #2 <tuple> -- #2
<device> -- #2 <device> -- #2
<person> -- #2 <person> -- #2
... ...
<tuple> -- #o <tuple> -- #o
</presence> </presence>
Figure 1: Structure of a PIDF-LO Document Figure 1: Structure of a PIDF-LO Document
All of these potential sources and storage places for location lead All of these potential sources and storage places for location lead
to confusion for the generators, conveyors and consumers of location to confusion for the generators, conveyors, and consumers of location
information. Practical experience within the United States National information. Practical experience within the United States National
Emergency Number Association (NENA) in trying to solve these Emergency Number Association (NENA) in trying to solve these
ambiguities led to a set of conventions being adopted. These rules ambiguities led to a set of conventions being adopted. These rules
do not have any particular order, but should be followed by creators do not have any particular order, but should be followed by creators
and consumers of location information contained in a PIDF-LO to and consumers of location information contained in a PIDF-LO to
ensure that a consistent interpretation of the data can be achieved. ensure that a consistent interpretation of the data can be achieved.
Rule #1: A <geopriv> element MUST describe a discrete location. Rule #1: A <geopriv> element MUST describe a discrete location.
Rule #2: Where a discrete location can be uniquely described in more Rule #2: Where a discrete location can be uniquely described in more
skipping to change at page 8, line 26 skipping to change at page 6, line 27
separate <tuple>, <device>, or <person> element; only one geopriv separate <tuple>, <device>, or <person> element; only one geopriv
element per tuple. element per tuple.
Rule #3: Providing more than one <geopriv> element in a single Rule #3: Providing more than one <geopriv> element in a single
presence document (PIDF) MUST only be done if the locations refer presence document (PIDF) MUST only be done if the locations refer
to the same place or are put into different element types. For to the same place or are put into different element types. For
example, one location in a <tuple>, a second location in a example, one location in a <tuple>, a second location in a
<device> element, and a third location in a <person> element. <device> element, and a third location in a <person> element.
This may occur if a Target's location is determined using a This may occur if a Target's location is determined using a
series of different techniques, or the Target wishes to series of different techniques or if the Target wishes to
represent her location as well as the location of her PC. In represent her location as well as the location of her PC. In
general avoid putting more than one location into a document general, avoid putting more than one location into a document
unless it makes sense to do so. unless it makes sense to do so.
Rule #4: Providing more than one location chunk in a single Rule #4: Providing more than one location chunk in a single
<location-info> element SHOULD be avoided where possible. Rule #5 <location-info> element SHOULD be avoided where possible. Rule #5
and Rule #6 provide further refinement. and Rule #6 provide further refinement.
Rule #5: When providing more than one location chunk in a single Rule #5: When providing more than one location chunk in a single
<location-info> element the locations MUST be provided by a common <location-info> element, the locations MUST be provided by a
source at the same time and by the same location determination common source at the same time and by the same location
method. determination method.
Rule #6: Providing more than one location chunk in a single Rule #6: Providing more than one location chunk in a single
<location-info> element SHOULD only be used for representing <location-info> element SHOULD only be used for representing
compound location referring to the same place. compound location referring to the same place.
For example, a geodetic location describing a point, and a For example, a geodetic location describing a point, and a
civic location indicating the floor in a building. civic location indicating the floor in a building.
Rule #7: Where compound location is provided in a single <location- Rule #7: Where the compound location is provided in a single
info> element, the coarse location information MUST be provided <location-info> element, the coarse location information MUST be
first. provided first.
For example, a geodetic location describing an area, and a For example, a geodetic location describing an area and a civic
civic location indicating the floor should be represented with location indicating the floor should be represented with the
the area first followed by the civic location. area first followed by the civic location.
Rule #8: Where a PIDF document contains more than one <geopriv> Rule #8: Where a PIDF document contains more than one <geopriv>
element, the priority of interpretation is given to the first element, the priority of interpretation is given to the first
<device> element in the document containing a location. If no <device> element in the document containing a location. If no
<device> element containing a location is present in the document, <device> element containing a location is present in the document,
then priority is given to the first <tuple> element containing a then priority is given to the first <tuple> element containing a
location. Locations contained in <person> tuples SHOULD only be location. Locations contained in <person> tuples SHOULD only be
used as a last resort. used as a last resort.
Rule #9: Where multiple PIDF documents can be sent or received Rule #9: Where multiple PIDF documents can be sent or received
together, say in a multi-part MIME body, and current location together, say in a multi-part MIME body, and current location
information is required by the recipient, then document selection information is required by the recipient, then document selection
SHOULD be based on document order, with the first document SHOULD be based on document order, with the first document
considered first. considered first.
The following examples illustrate the application of these rules. The following examples illustrate the application of these rules.
3.1. Single Civic Location Information 3.1. Single Civic Location Information
Jane is at a coffee shop on the ground floor of a large shopping Jane is at a coffee shop on the ground floor of a large shopping
mall. Jane turns on her laptop and connects to the coffee-shop's mall. Jane turns on her laptop and connects to the coffee shop's
WiFi hotspot, Jane obtains a complete civic address for her current WiFi hotspot; Jane obtains a complete civic address for her current
location, for example using the DHCP civic mechanism defined in location, for example, using the DHCP civic mechanism defined in
[RFC4776]. A Location Object is constructed consisting of a single [RFC4776]. A Location Object is constructed consisting of a single
PIDF document, with a single <tuple> or <device> element, a single PIDF document, with a single <tuple> or <device> element, a single
<status> element, a single <geopriv> element, and a single location <status> element, a single <geopriv> element, and a single location
chunk residing in the <location-info> element. This document is chunk residing in the <location-info> element. This document is
unambiguous, and should be interpreted consistently by receiving unambiguous, and should be interpreted consistently by receiving
nodes if sent over the network. nodes if sent over the network.
3.2. Civic and Geospatial Location Information 3.2. Civic and Geospatial Location Information
Mike is visiting his Seattle office and connects his laptop into the Mike is visiting his Seattle office and connects his laptop into the
Ethernet port in a spare cube. In this case location information is Ethernet port in a spare cube. In this case, location information is
geodetic location, with the altitude represented as a building floor geodetic location, with the altitude represented as a building floor
number. Mike's main location is the point specified by the geodetic number. Mike's main location is the point specified by the geodetic
coordinates. Further, Mike is on the second floor of the building coordinates. Further, Mike is on the second floor of the building
located at these coordinates. Applying rules #6 and #7, the located at these coordinates. Applying rules #6 and #7, the
resulting compound location information is shown in Figure 2. resulting compound location information is shown in Figure 2.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
skipping to change at page 10, line 29 skipping to change at page 8, line 29
</cl:civicAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:8asd7d7d70cf</dm:deviceID> <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
Figure 2 Figure 2: PIDF-LO Containing a Compound Location
3.3. Manual/Automatic Configuration of Location Information 3.3. Manual/Automatic Configuration of Location Information
Loraine has a predefined civic location stored in her laptop, since Loraine has a predefined civic location stored in her laptop, since
she normally lives in Sydney, the address is for her Sydney-based she normally lives in Sydney, the address is for her Sydney-based
apartment. Loraine decides to visit sunny San Francisco, and when apartment. Loraine decides to visit sunny San Francisco, and when
she gets there she plugs in her laptop and makes a call. Loraine's she gets there, she plugs in her laptop and makes a call. Loraine's
laptop receives a new location from the visited network in San laptop receives a new location from the visited network in San
Francisco. As this system cannot be sure that the pre-existing, and Francisco. As this system cannot be sure that the preexisting and
new location, both describe the same place, Loraine's computer new location both describe the same place, Loraine's computer
generates a new PIDF-LO and will use this to represent Loraine's generates a new PIDF-LO and will use this to represent Loraine's
location. If Loraine's computer were to add the new location to her location. If Loraine's computer were to add the new location to her
existing PIDF location document (breaking rule #3), then the correct existing PIDF location document (breaking rule #3), then the correct
information may still be interpreted by the Location Recipient information may still be interpreted by the Location Recipient
providing Loraine's system applies rule #9. In this case the providing Loraine's system applies rule #9. In this case, the
resulting order of location information in the PIDF document should resulting order of location information in the PIDF document should
be San Francisco first, followed by Sydney. Since the information is be San Francisco first, followed by Sydney. Since the information is
provided by different sources, rule #8 should also be applied and the provided by different sources, rule #8 should also be applied and the
information placed in different tuples with the tuple containing the information placed in different tuples with the tuple containing the
San Francisco location first. San Francisco location first.
3.4. Multiple Location Objects in a Single PIDF-LO 3.4. Multiple Location Objects in a Single PIDF-LO
Vanessa has her PC with her at the park, but due to a Vanessa has her PC with her at the park, but due to a
misconfiguration, her PC reports her location as being in the office. misconfiguration, her PC reports her location as being in the office.
skipping to change at page 12, line 15 skipping to change at page 10, line 15
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Manual</gp:method> <gp:method>Manual</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:timestamp>2007-06-24T12:28:04Z</dm:timestamp> <dm:timestamp>2007-06-24T12:28:04Z</dm:timestamp>
</dm:person> </dm:person>
</presence> </presence>
Figure 3 Figure 3: PIDF-LO Containing Multiple Location Objects
4. Geodetic Coordinate Representation 4. Geodetic Coordinate Representation
The geodetic examples provided in RFC 4119 [RFC4119] are illustrated The geodetic examples provided in RFC 4119 [RFC4119] are illustrated
using the <gml:location> element, which uses the <gml:coordinates> using the <gml:location> element, which uses the <gml:coordinates>
element inside the <gml:Point> element and this representation has element inside the <gml:Point> element, and this representation has
several drawbacks. Firstly, it has been deprecated in later versions several drawbacks. Firstly, it has been deprecated in later versions
of GML (3.1 and beyond) making it inadvisable to use for new of GML (3.1 and beyond) making it inadvisable to use for new
applications. Secondly, the format of the coordinates type is opaque applications. Secondly, the format of the coordinates type is opaque
and so can be difficult to parse and interpret to ensure consistent and so can be difficult to parse and interpret to ensure consistent
results, as the same geodetic location can be expressed in a variety results, as the same geodetic location can be expressed in a variety
of ways. The PIDF-LO Geodetic Shapes specification [GeoShape] of ways. The PIDF-LO Geodetic Shapes specification [GeoShape]
provides a specific GML profile for expressing commonly used shapes provides a specific GML profile for expressing commonly used shapes
using simple GML representations. The shapes defined in [GeoShape] using simple GML representations. The shapes defined in [GeoShape]
are the recommended shapes to ensure interoperability. are the recommended shapes to ensure interoperability.
5. Geodetic Shape Representation 5. Geodetic Shape Representation
The cellular mobile world today makes extensive use of geodetic based The cellular mobile world today makes extensive use of geodetic-based
location information for emergency and other location-based location information for emergency and other location-based
applications. Generally these locations are expressed as a point applications. Generally, these locations are expressed as a point
(either in two or three dimensions) and an area or volume of (either in two or three dimensions) and an area or volume of
uncertainty around the point. In theory, the area or volume uncertainty around the point. In theory, the area or volume
represents a coverage in which the user has a relatively high represents a coverage in which the user has a relatively high
probability of being found, and the point is a convenient means of probability of being found, and the point is a convenient means of
defining the centroid for the area or volume. In practice, most defining the centroid for the area or volume. In practice, most
systems use the point as an absolute value and ignore the systems use the point as an absolute value and ignore the
uncertainty. It is difficult to determine if systems have been uncertainty. It is difficult to determine if systems have been
implemented in this manner for simplicity, and even more difficult to implemented in this manner for simplicity, and even more difficult to
predict if uncertainty will play a more important role in the future. predict if uncertainty will play a more important role in the future.
An important decision is whether an uncertainty area should be An important decision is whether an uncertainty area should be
specified. specified.
The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight
shape types most of which are easily translated into shapes shape types, most of which are easily translated into shape
definitions used in other applications and protocols, such as Open definitions used in other applications and protocols, such as the
Mobile Alliance (OMA) Mobile Location Protocol (MLP). For Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For
completeness the shapes defined in [GeoShape] are listed below: completeness, the shapes defined in [GeoShape] are listed below:
o Point (2d and 3d) o Point (2d and 3d)
o Polygon (2d) o Polygon (2d)
o Circle (2d) o Circle (2d)
o Ellipse (2d) o Ellipse (2d)
o Arc band (2d) o Arc band (2d)
skipping to change at page 14, line 51 skipping to change at page 11, line 34
o Prism (3d) o Prism (3d)
The above-listed shapes MUST be implemented. The above-listed shapes MUST be implemented.
The GeoShape specification [GeoShape] also describes a standard set The GeoShape specification [GeoShape] also describes a standard set
of coordinate reference systems (CRS), unit of measure (UoM) and of coordinate reference systems (CRS), unit of measure (UoM) and
conventions relating to lines and distances. The use of the world conventions relating to lines and distances. The use of the world
geodetic system 1984 (WGS84) [WGS84] coordinate reference system and geodetic system 1984 (WGS84) [WGS84] coordinate reference system and
the usage of European petroleum survey group (EPSG) code 4326 (as the usage of European petroleum survey group (EPSG) code 4326 (as
identified by the URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) for two identified by the URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) for two-
dimensional (2d) shape representations and EPSG 4979 (as identified dimensional (2d) shape representations and EPSG 4979 (as identified
by the URN urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) by the URN urn:ogc:def:crs:EPSG::4979) for three-dimensional (3d)
volume representations is mandated. Distance and heights are volume representations is mandated. Distance and heights are
expressed in meters using EPSG 9001 (as identified by the URN expressed in meters using EPSG 9001 (as identified by the URN
urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either
degrees or radians. Measures in degrees MUST be identified by the degrees or radians. Measures in degrees MUST be identified by the
URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be
identified by the URN urn:ogc:def:uom:EPSG::9101. Angles identified by the URN urn:ogc:def:uom:EPSG::9101. Angles
representing bearings are measured in a clockwise direction from representing bearings are measured in a clockwise direction from
Northing, as defined by the WGS84 CRS, not magnetic north. Northing, as defined by the WGS84 CRS, not magnetic north.
Implementations MUST specify the CRS using the srsName attribute on Implementations MUST specify the CRS using the srsName attribute on
skipping to change at page 15, line 33 skipping to change at page 12, line 17
[W3C.REC-xmlschema-2-20041028]. Leading zeros and trailing zeros [W3C.REC-xmlschema-2-20041028]. Leading zeros and trailing zeros
past the decimal point are not significant; for instance "03.07500" past the decimal point are not significant; for instance "03.07500"
is equivalent to "3.075". is equivalent to "3.075".
It is RECOMMENDED that uncertainty is expressed at a confidence of It is RECOMMENDED that uncertainty is expressed at a confidence of
95% or higher. Specifying a convention for confidence enables better 95% or higher. Specifying a convention for confidence enables better
use of uncertainty values. use of uncertainty values.
5.1. Polygon Restrictions 5.1. Polygon Restrictions
The Polygon shape type defined in [GeoShape] intentionally does not The polygon shape type defined in [GeoShape] intentionally does not
place any constraints on the number of vertices that may be included place any constraints on the number of vertices that may be included
to define the bounds of a polygon. This allows arbitrarily complex to define the bounds of a polygon. This allows arbitrarily complex
shapes to be defined and conveyed in a PIDF-LO. However, where shapes to be defined and conveyed in a PIDF-LO. However, where
location information is to be used in real-time processing location information is to be used in real-time processing
applications, such as location dependent routing, having arbitrarily applications, such as location-dependent routing, having arbitrarily
complex shapes consisting of tens or even hundreds of points could complex shapes consisting of tens or even hundreds of points could
result in significant performance impacts. To mitigate this risk result in significant performance impacts. To mitigate this risk,
Polygon shapes SHOULD be restricted to a maximum of 15 points (16 Polygon shapes SHOULD be restricted to a maximum of 15 points (16
including the repeated point) when the location information is including the repeated point) when the location information is
intended for use in real-time applications. This limit of 15 points intended for use in real-time applications. This limit of 15 points
is chosen to allow moderately complex shape definitions while at the is chosen to allow moderately complex shape definitions while at the
same time enabling interoperation with other location transporting same time enabling interoperation with other location transporting
protocols such as those defined in 3GPP (see [3GPP-TS-23_032]) and protocols such as those defined in the 3rd Generation Partnership
OMA where the 15 point limit is already imposed. Project (3GPP) (see [3GPP.23.032]) and OMA where the 15-point limit
is already imposed.
The edges of a polygon are defined by the shortest path between two The edges of a polygon are defined by the shortest path between two
points in space (not a geodesic curve). Two dimensional points MAY points in space (not a geodesic curve). Two-dimensional points MAY
be interpreted as having a zero valure for their altitude component. be interpreted as having a zero value for their altitude component.
To avoid significant errors arising from potential geodesic To avoid significant errors arising from potential geodesic
interpolation, the length between adjacent vertices SHOULD be interpolation, the length between adjacent vertices SHOULD be
restricted to a maximum of 130km. More information relating to this restricted to a maximum of 130km. More information relating to this
restriction is provided in [GeoShape]. restriction is provided in [GeoShape].
A connecting line SHALL NOT cross another connecting line of the same A connecting line SHALL NOT cross another connecting line of the same
Polygon. Polygon.
Polygons MUST be defined with the upward normal pointing up. This is Polygons MUST be defined with the upward normal pointing up. This is
accomplished by defining the vertices in a counter-clockwise accomplished by defining the vertices in a counter-clockwise
direction. direction.
Points specified in a polygon using 3 dimensional coordinates MUST Points specified in a polygon using three-dimensional coordinates
all have the same altitude. MUST all have the same altitude.
5.2. Shape Examples 5.2. Shape Examples
This section provides some examples of where some of the more complex This section provides some examples of where some of the more complex
shapes are used, how they are determined, and how they are shapes are used, how they are determined, and how they are
represented in a PIDF-LO. Complete details on all of the GeoShape represented in a PIDF-LO. Complete details on all of the GeoShape
types are provided in [GeoShape]. types are provided in [GeoShape].
5.2.1. Point 5.2.1. Point
skipping to change at page 17, line 26 skipping to change at page 13, line 42
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
Figure 4 Figure 4: PIDF-LO Containing a Two-Dimensional Point
Figure 5 shows a 3d point: Figure 5 shows a 3d point:
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:point3d@example.com"> entity="pres:point3d@example.com">
<dm:device id="point3d"> <dm:device id="point3d">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
skipping to change at page 17, line 51 skipping to change at page 14, line 27
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
Figure 5 Figure 5: PIDF-LO Containing a Three-Dimensional Point
5.2.2. Polygon 5.2.2. Polygon
The polygon shape may be used to represent a building outline or The polygon shape type may be used to represent a building outline or
coverage area. The first and last points of the polygon have to be coverage area. The first and last points of the polygon have to be
the same. For example, looking at the hexagon in Figure 6 with the same. For example, looking at the hexagon in Figure 6 with
vertices, A, B, C, D, E, and F. The resulting polygon will be defined vertices, A, B, C, D, E, and F. The resulting polygon will be
with 7 points, with the first and last points both having the defined with 7 points, with the first and last points both having the
coordinates of point A. coordinates of point A.
F--------------E F--------------E
/ \ / \
/ \ / \
/ \ / \
A D A D
\ / \ /
\ / \ /
\ / \ /
B--------------C B--------------C
Figure 6 Figure 6: Example of a Polygon
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:hexagon@example.com"> entity="pres:hexagon@example.com">
<tuple id="polygon-pos"> <tuple id="polygon-pos">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior> <gml:exterior>
skipping to change at page 19, line 34 skipping to change at page 15, line 34
</gml:Polygon> </gml:Polygon>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 7 Figure 7: PIDF-LO Containing a Polygon
In addition to the form shown in Figure 7 GML supports a posList In addition to the form shown in Figure 7, GML supports a posList
which provides a more compact representation for the coordinates of that provides a more compact representation for the coordinates of
the Polygon vertices than the discrete pos elements. The more the Polygon vertices than the discrete pos elements. The more
compact form is shown in Figure 8. Both forms are permitted. compact form is shown in Figure 8. Both forms are permitted.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:hexagon@example.com"> entity="pres:hexagon@example.com">
<tuple id="polygon-poslist"> <tuple id="polygon-poslist">
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 20, line 34 skipping to change at page 16, line 34
</gml:Polygon> </gml:Polygon>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 8 Figure 8: Compact Form of a Polygon Expressed in a PIDF-LO
5.2.3. Circle 5.2.3. Circle
The circular area is used for coordinates in two-dimensional CRSs to The circular area is used for coordinates in two-dimensional CRSs to
describe uncertainty about a point. The definition is based on the describe uncertainty about a point. The definition is based on the
one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre one-dimensional geometry in GML, gml:CircleByCenterPoint. The center
point of a circular area is specified by using a two dimensional CRS; point of a circular area is specified by using a two-dimensional CRS;
in three dimensions, the orientation of the circle cannot be in three dimensions, the orientation of the circle cannot be
specified correctly using this representation. A point with specified correctly using this representation. A point with
uncertainty that is specified in three dimensions should use the uncertainty that is specified in three dimensions should use the
Sphere shape type. sphere shape type.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:circle@example.com"> entity="pres:circle@example.com">
<tuple id="circle"> <tuple id="circle">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
skipping to change at page 21, line 28 skipping to change at page 17, line 39
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>OTDOA</gp:method> <gp:method>OTDOA</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
Figure 9 Figure 9: PIDF-LO Containing a Circle
5.2.4. Ellipse 5.2.4. Ellipse
An elliptical area describes an ellipse in two dimensional space. An elliptical area describes an ellipse in two-dimensional space.
The ellipse is described by a center point, the length of its semi- The ellipse is described by a center point, the length of its semi-
major and semi-minor axes, and the orientation of the semi-major major and semi-minor axes, and the orientation of the semi-major
axis. Like the circular area (Circle), the ellipse MUST be specified axis. Like the circular area (Circle), the ellipse MUST be specified
using the two dimensional CRS. using the two-dimensional CRS.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:Ellipse@somecell.example.com"> entity="pres:Ellipse@somecell.example.com">
<tuple id="ellipse"> <tuple id="ellipse">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
skipping to change at page 22, line 35 skipping to change at page 18, line 35
</gs:Ellipse> </gs:Ellipse>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Device-Assisted_A-GPS</gp:method> <gp:method>Device-Assisted_A-GPS</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 10 Figure 10: PIDF-LO Containing an Ellipse
The gml:pos element indicates the position of the center, or origin, The gml:pos element indicates the position of the center, or origin,
of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements of the ellipse. The gs:semiMajorAxis and gs:semiMinorAxis elements
are the length of the semi-major and semi-minor axes respectively. are the length of the semi-major and semi-minor axes, respectively.
The gs:orientation element is the angle by which the semi-major axis The gs:orientation element is the angle by which the semi-major axis
is rotated from the first axis of the CRS towards the second axis. is rotated from the first axis of the CRS towards the second axis.
For WGS 84, the orientation indicates rotation from Northing to For WGS 84, the orientation indicates rotation from Northing to
Easting, which, if specified in degrees, is roughly equivalent to a Easting, which, if specified in degrees, is roughly equivalent to a
compass bearing (if magnetic north were the same as the WGS north compass bearing (if magnetic north were the same as the WGS north
pole). Note: An ellipse with equal major and minor axis lengths is a pole). Note: An ellipse with equal major and minor axis lengths is a
circle. circle.
5.2.5. Arc Band 5.2.5. Arc Band
The arc band shape type is commonly generated in wireless systems The arc band shape type is commonly generated in wireless systems
where timing advance or code offsets sequences are used to compensate where timing advance or code offsets sequences are used to compensate
for distances between handsets and the access point. The arc band is for distances between handsets and the access point. The arc band is
represented as two radii emanating from a central point, and two represented as two radii emanating from a central point, and two
angles which represent the starting angle and the opening angle of angles that represent the starting angle and the opening angle of the
the arc. In a cellular environment the central point is nominally arc. In a cellular environment, the central point is nominally the
the location of the cell tower, the two radii are determined by the location of the cell tower, the two radii are determined by the
extent of the timing advance, and the two angles are generally extent of the timing advance, and the two angles are generally
provisioned information. provisioned information.
For example, Paul is using a cellular wireless device and is 7 timing For example, Paul is using a cellular wireless device and is 7 timing
advance symbols away from the cell tower. For a GSM-based network advance symbols away from the cell tower. For a GSM-based network,
this would place Paul roughly between 3,594 meters and 4,148 meters this would place Paul roughly between 3,594 meters and 4,148 meters
from the cell tower, providing the inner and outer radius values. If from the cell tower, providing the inner and outer radius values. If
the start angle is 20 degrees from north, and the opening angle is the start angle is 20 degrees from north, and the opening angle is
120 degrees, an arc band representing Paul's location would look 120 degrees, an arc band representing Paul's location would look
similar to Figure 11. similar to Figure 11.
N ^ ,.__ N ^ ,.__
| a(s) / `-. | a(s) / `-.
| 20 / `-. | 20 / `-.
|--. / `. |--. / `.
skipping to change at page 23, line 40 skipping to change at page 19, line 46
| . / ' | . / '
| . / ; | . / ;
.,' / .,' /
r(i)`. / r(i)`. /
(3594m) `. / (3594m) `. /
`. ,' `. ,'
`. ,' `. ,'
r(o)`' r(o)`'
(4148m) (4148m)
Figure 11 Figure 11: Example of an Arc Band
The resulting PIDF-LO is shown in Figure 12. The resulting PIDF-LO is shown in Figure 12.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:paul@somecell.example.com"> entity="pres:paul@somecell.example.com">
<tuple id="arcband"> <tuple id="arcband">
<status> <status>
skipping to change at page 24, line 38 skipping to change at page 20, line 38
</gs:ArcBand> </gs:ArcBand>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>TA-NMR</gp:method> <gp:method>TA-NMR</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 12 Figure 12: PIDF-LO Containing an Arc Band
An important note to make on the arc band is that the center point An important note to make on the arc band is that the center point
used in the definition of the shape is not included in resulting used in the definition of the shape is not included in resulting
enclosed area, and that Target may be anywhere in the defined area of enclosed area, and that Target may be anywhere in the defined area of
the arc band. the arc band.
5.2.6. Sphere 5.2.6. Sphere
The sphere is a volume that provides the same information as a circle The sphere is a volume that provides the same information as a circle
in three dimensions. The sphere has to be specified using a three in three dimensions. The sphere has to be specified using a three-
dimensional CRS. Figure 13 shows the sphere shape, which is dimensional CRS. Figure 13 shows the sphere shape type, which is
identical to the circle example, except for the addition of an identical to the circle example, except for the addition of an
altitude in the provided coordinates. altitude in the provided coordinates.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:sphere@example.com"> entity="pres:sphere@example.com">
<tuple id="sphere"> <tuple id="sphere">
<status> <status>
skipping to change at page 25, line 28 skipping to change at page 21, line 36
</gs:radius> </gs:radius>
</gs:Sphere> </gs:Sphere>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Device-Based_A-GPS</gp:method> <gp:method>Device-Based_A-GPS</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
Figure 13 Figure 13: PIDF-LO Containing a Sphere
5.2.7. Ellipsoid 5.2.7. Ellipsoid
The ellipsoid is the volume most commonly produced by GPS systems. The ellipsoid is the volume most commonly produced by GPS systems.
It is used extensively in navigation systems and wireless location It is used extensively in navigation systems and wireless location
networks. The ellipsoid is constructed around a central point networks. The ellipsoid is constructed around a central point
specified in three dimensions, and three axies perpendicular to one specified in three dimensions, and three axes perpendicular to one
another are extended outwards from this point. These axies are another are extended outwards from this point. These axes are
defined as the semi-major (M) axis, the semi-minor (m) axis, and the defined as the semi-major (M) axis, the semi-minor (m) axis, and the
vertical (v) axis respectively. An angle is used to express the vertical (v) axis, respectively. An angle is used to express the
orientation of the ellipsoid. The orientation angle is measured in orientation of the ellipsoid. The orientation angle is measured in
degrees from north, and represents the direction of the semi-major degrees from north, and represents the direction of the semi-major
axis from the center point. axis from the center point.
\ \
_.-\""""^"""""-._ _.-\""""^"""""-._
.' \ | `. .' \ | `.
/ v m \ / v m \
| \ | | | \ | |
| -c ----M---->| | -c ----M---->|
| | | |
\ / \ /
`._ _.' `._ _.'
`-...........-' `-...........-'
Figure 14 Figure 14: Example of an Ellipsoid
A PIDF-LO containing an ellipsoid appears as shown in Figure 15. A PIDF-LO containing an ellipsoid appears as shown in Figure 15.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:somone@gpsreceiver.example.com"> entity="pres:somone@gpsreceiver.example.com">
<tuple id="ellipsoid"> <tuple id="ellipsoid">
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 27, line 4 skipping to change at page 23, line 38
</gs:orientation> </gs:orientation>
</gs:Ellipsoid> </gs:Ellipsoid>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Hybrid_A-GPS</gp:method> <gp:method>Hybrid_A-GPS</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 15
Figure 15: PIDF-LO Containing an Ellipsoid
5.2.8. Prism 5.2.8. Prism
A prism may be used to represent a section of a building or range of A prism may be used to represent a section of a building or range of
floors of building. The prism extrudes a polygon by providing a floors of building. The prism extrudes a polygon by providing a
height element. It consists of a base made up of coplanar points height element. It consists of a base made up of coplanar points
defined in 3 dimensions all at the same altitude. The prism is then defined in 3 dimensions all at the same altitude. The prism is then
an extrusion from this base to the value specified in the height an extrusion from this base to the value specified in the height
element. The height of the Prism MUST be a positive value. The element. The height of the Prism MUST be a positive value. The
first and last points of the polygon have to be the same. first and last points of the polygon have to be the same.
For example, looking at the cube in Figure 16. If the prism is For example, looking at the cube in Figure 16: if the prism is
extruded from the bottom up, then the polygon forming the base of the extruded from the bottom up, then the polygon forming the base of the
prism is defined with the points A, B, C, D, A. The height of the prism is defined with the points A, B, C, D, A. The height of the
prism is the distance between point A and point E in meters. prism is the distance between point A and point E in meters.
G-----F G-----F
/| /| /| /|
/ | / | / | / |
H--+--E | H--+--E |
| C--|--B | C--|--B
| / | / | / | /
|/ |/ |/ |/
D-----A D-----A
Figure 16 Figure 16: Example of a Prism
The resulting PIDF-LO is shown in Figure 17. The resulting PIDF-LO is shown in Figure 17.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:mike@someprism.example.com"> entity="pres:mike@someprism.example.com">
<tuple id="prism"> <tuple id="prism">
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 28, line 43 skipping to change at page 25, line 44
</gs:Prism> </gs:Prism>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 17 Figure 17: PIDF-LO Containing a Prism
6. Security Considerations 6. Security Considerations
The primary security considerations relate to how location The primary security considerations relate to how location
information is conveyed and used, which are outside the scope of this information is conveyed and used, which are outside the scope of this
document. This document is intended to serve only as a set of document. This document is intended to serve only as a set of
guidelines as to which elements MUST or SHOULD be implemented by guidelines as to which elements MUST or SHOULD be implemented by
systems wishing to perform location dependent routing. The systems wishing to perform location dependent routing. The
ramification of such recommendations is that they extend to devices ramification of such recommendations is that they extend to devices
and clients that wish to make use of such services. and clients that wish to make use of such services.
7. IANA Considerations 7. Acknowledgments
This document does not introduce any IANA considerations.
8. Acknowledgments
The authors would like to thank the GEOPRIV working group for their The authors would like to thank the GEOPRIV working group for their
discussions in the context of PIDF-LO, in particular Carl Reed, Ron discussions in the context of PIDF-LO, in particular Carl Reed, Ron
Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall
and Robert Sparks. Furthermore, we would like to thank Jon Peterson and Robert Sparks. Furthermore, we would like to thank Jon Peterson
as the author of PIDF-LO and Nadine Abbott for her constructive as the author of PIDF-LO and Nadine Abbott for her constructive
comments in clarifying some aspects of the document. comments in clarifying some aspects of the document.
Thanks to Karen Navas for pointing out some omissions in the Thanks to Karen Navas for pointing out some omissions in the
examples. examples.
9. References 8. References
9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 8.1. Normative References
July 2006.
[GeoShape] [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007. Specification 06-142r1, Version: 1.0, April 2007.
[OGC-GML3.1.1] [OGC-GML3.1.1]
Portele, C., Cox, S., Daisy, P., Lake, R., and A. Portele, C., Cox, S., Daisy, P., Lake, R., and A.
Whiteside, "Geography Markup Language (GML) 3.1.1", Whiteside, "Geography Markup Language (GML) 3.1.1",
OGC 03-105r1, July 2003. OGC 03-105r1, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
9.2. Informative References 8.2. Informative References
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [3GPP.23.032]
(DHCPv4 and DHCPv6) Option for Civic Addresses 3rd Generation Partnership Project, "Universal
Configuration Information", RFC 4776, November 2006. Geographical Area Description (GAD)", 3GPP TS 23.032
V6.0.0, January 2005,
<http://www.3gpp.org/ftp/Specs/html-info/23032.htm>.
[CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03-
105r1, November 2005.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[3GPP-TS-23_032] [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
"3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; (DHCPv4 and DHCPv6) Option for Civic Addresses
Technical Specification Group Code Network; Universal Configuration Information", RFC 4776, November 2006.
Geographic Area Description (GAD)".
[CRS-URN] Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03-
105r1, November 2005.
[WGS84] US National Imagery and Mapping Agency, "Department of [WGS84] US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition", NIMA TR8350.2, January 2000. Edition", NIMA TR8350.2, January 2000.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Wollongong Wollongong
NSW Australia NSW Australia
Email: james.winterbottom@andrew.com EMail: james.winterbottom@andrew.com
Martin Thomson Martin Thomson
Andrew Corporation Andrew Corporation
Wollongong Wollongong
NSW Australia NSW Australia
Email: martin.thomson@andrew.com EMail: martin.thomson@andrew.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 83 change blocks. 
182 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/