draft-ietf-geopriv-pdif-lo-profile-05.txt   draft-ietf-geopriv-pdif-lo-profile-06.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: Informational Andrew Corporation Expires: September 6, 2007 Andrew Corporation
Expires: April 26, 2007 H. Tschofenig H. Tschofenig
Siemens Siemens Networks GmbH & Co KG
October 23, 2006 March 5, 2007
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-05.txt draft-ietf-geopriv-pdif-lo-profile-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 so when information needs to be constrained in how it is represented so
that the number of options that need to be implemented in order to that the number of options that need to be implemented in order to
make use of it are reduced. There is growing interest in being able make use of it are reduced. There is growing interest in being able
to use location information contained in a PIDF-LO for routing to use location information contained in a PIDF-LO for routing
applications. To allow successfully interoperability between applications. To allow successfully 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 PIDF-LO. This tightly constrained than is currently specified in the PIDF-LO. This
document makes recommendations on how to constrain, represent and document makes recommendations on how to constrain, represent and
interpret locations in a PIDF-LO. It further recommends a subset of interpret locations in a PIDF-LO. It further recommends a subset of
GML that MUST be implemented by applications involved in location GML that MUST be implemented by applications involved in location
based routing. based routing.
Table of Contents Table of Contents
1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 05 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. 04 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Using Location Information . . . . . . . . . . . . . . . . . . 6
1.3. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Single Civic Location Information . . . . . . . . . . . . 8
1.4. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Civic and Geospatial Location Information . . . . . . . . 8
2. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Manual/Automatic Configuration of Location Information . . 9
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11
5. Using Location Information . . . . . . . . . . . . . . . . . . 9 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12
5.1. Single Civic Location Information . . . . . . . . . . . . 11 5.2. Complex Shape Examples . . . . . . . . . . . . . . . . . . 12
5.2. Civic and Geospatial Location Information . . . . . . . . 11 5.2.1. Polygon Representation and Usage . . . . . . . . . . . 12
5.3. Manual/Automatic Configuration of Location Information . . 12 5.2.2. Prism Representation and Usage . . . . . . . . . . . . 14
6. Geodetic Coordinate Representation . . . . . . . . . . . . . . 14 5.2.3. Arc Band Respresentation and Usage . . . . . . . . . . 16
7. Geodetic Shape Representation . . . . . . . . . . . . . . . . 15 5.2.4. Ellipsoid Representation and Usage . . . . . . . . . . 18
7.1. Polygon Restriction . . . . . . . . . . . . . . . . . . . 16 5.3. Emergency Shape Representations . . . . . . . . . . . . . 20
7.2. Emergency Shape Representations . . . . . . . . . . . . . 16 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 22
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative references . . . . . . . . . . . . . . . . . . . 26
12.1. Normative references . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Uncertainty in The RFC-3825 LCI Representation . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 28
A.1. Conversion From LCI Form . . . . . . . . . . . . . . . . . 22
A.2. Conversion To LCI Form . . . . . . . . . . . . . . . . . . 22
A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 23
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 24
A.3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 26
B.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 26
B.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. CHANGES SINCE LAST TIME
[[This section is informational only and will be removed before the
final version.]]
1.1. 05 changes
Clarified definitions more.
Clarified rules.
Clarified examples, and removed confusion caused by the illustration
of how not to represent location.
1.2. 04 changes
Added a section to recommend restricting Polygon to 16 points for
routing and other real-time applications.
Added section detailing caution when selecting shapes for emergency
routing.
Modified the recommendations section to include the two above
additions.
Added a second appendix detailing problems with expressing
uncertainty using LCI.
1.3. 03 changes
Removed some shape definitions, ellipses, arcbands.
Removed OMA shape definition comparisons.
Modified examples to use new civicAddr draft data.
Made extensive references to the GeoShape Draft.
1.4. 01 changes
minor changes to the abstract.
Minor changes to the introduction.
Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [3].
Rectified examples to use position and pos rather than location and
point.
Corrected example 3 so that it does not violate SIP rules.
Added addition geopriv elements to the status component of the figure
in "Using Location Information" to more accurately reflect the
cardinality issues.
Revised text in section Geodetic Coordinate Representation. Removed
last example as this was addressed with the change to position and
pos in previous examples.
2. To Do
Get Appendices moved into the RFC 3825 Biz document.
Get an OGC reference for the GeoShapes specification
3. Introduction 1. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [2] is The Presence Information Data Format Location Object (PIDF-LO) [2] is
the IETF recommended way of encoding location information and the IETF 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 GMLv3, or as be described in a geospatial manner based on a subset of GMLv3, or as
civic location information [5]. A GML profile for expressing civic location information [4]. A GML profile for expressing
geodetic shapes in a PIDF-LO is described in [7]. Uses for PIDF-LO geodetic shapes in a PIDF-LO is described in [6]. Uses for PIDF-LO
are envisioned in the context of numerous location based are envisioned in the context of numerous location based
applications. This document makes recommendations for formats and applications. This document makes recommendations for formats and
conventions to make interoperability less problematic. conventions to make interoperability less problematic.
4. 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 [1]. document are to be interpreted as described in [1].
The definition for "Target" is taken from [6]. The definition for "Target" is taken from [5].
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. It must be described area or volume in which a Target can be found. It must be described
with sufficient precision to address the requirements of an intended with sufficient precision to address the requirements of an intended
application. application.
The term "location complex" is used to describe location information The term "location complex" 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 a location complex might be a geodetic polygon An example of a location complex 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.
5. Using Location Information 3. Using Location Information
The PIDF format provides for an unbounded number of tuples. The The PIDF format provides for an unbounded number of tuples. The
geopriv element resides inside the status component of a tuple, hence geopriv element resides inside the status component of a tuple, hence
a single PIDF document may contain an arbitrary number of location a single PIDF document may contain an arbitrary number of location
objects some or all of which may be contradictory or complementary. objects some or all of which may be contradictory or complementary.
The actual location information is contained inside a <location-info> The actual location information is contained inside a <location-info>
element, and there may be one or more actual locations described element, and there may be one or more actual locations described
inside the <location-info> element. inside the <location-info> element.
Graphically, the structure of the PIDF/PIDF-LO can be depicted as Graphically, the structure of the PIDF-LO can be depicted as follows:
follows:
PIDF document PIDF document
tuple 1 tuple 1
status status
geopriv geopriv
location-info location-info
civicAddress civicAddress
location geodetic
location...
usage-rules usage-rules
geopriv 2 geopriv 2
geopriv 3 geopriv 3
. .
. .
. .
tuple 2 tuple 2
tuple 3 tuple 3
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 users of location to confusion for the generators, conveyors and users 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 users of location information conatined in a PIDF-LO to ensure and users of location information contained in a PIDF-LO to ensure
that a consistent interpretation of the data can be achieved. 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
than one way, each location description SHOULD reside in a than one way, each location description SHOULD reside in a
separate tuple. separate tuple.
Rule #3: Providing more than one location in a single presence Rule #3: Providing more than one location in a single presence
document (PIDF) MUST only be done if all objects describe the same document (PIDF) MUST only be done if all objects describe the same
location. This may occur if a Target's location is determined location. This may occur if a Target's location is determined
using a series of different techniques. using a series of different techniques.
Rule #4: Providing more than one location in a single <location- Rule #4: Providing more than one location in a single <location-
info> element SHOULD be avoided where possible. info> element SHOULD be avoided where possible.
Rule #5: When providing more than one location in a single Rule #5: When providing more than one location in a single
<location-info> element the locations MUST be provided by a common <location-info> element the locations MUST be provided by a common
source. source at the same time and by the same method.
Rule #6: Providing more than one location in a single <location- Rule #6: Providing more than one location in a single <location-
info> element SHOULD only be done if they form a complex to info> element SHOULD only be done if they form a complex to
describe the same location. For example, a geodetic location describe the same location. For example, a geodetic location
describing a point, and a civic location indicating the floor in a describing a point, and a civic location indicating the floor in a
building. building.
Rule #7: Where a location complex is provided in a single <location- Rule #7: Where a location complex is provided in a single <location-
info> element, the coarse location information MUST be provided info> element, the coarse location information MUST be provided
first. For example, a geodetic location describing an area, and a first. For example, a geodetic location describing an area, and a
civic location indicating the floor should be represented with the civic location indicating the floor should be represented with 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 tuple Rule #8: Where a PIDF document contains more than one tuple
containing a status element with a geopriv location element , the containing a status element with a geopriv location element , the
priority of tuples SHOULD be based on tuple position within the priority of tuples SHOULD be based on tuple position within the
PIDF document. That is to say, the tuple with the highest PIDF document. That is to say, the tuple with the highest
priority location occurs earliest in the PIDF document. priority location occurs earliest in the PIDF document.
Rule #9: Where multiple PIDF documents can be sent of 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 be SHOULD be based on document order, with the first document be
considered first. considered first.
The following examples illustrate the application of these rules. The following examples illustrate the application of these rules.
5.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 [4]. location, for example using the DHCP civic mechanism defined in [3].
A Location Object is constructed consisting of a single PIDF A Location Object is constructed consisting of a single PIDF
document, with a single geopriv tuple, and a single location residing document, with a single geopriv tuple, and a single location residing
in the <location-info> element. This document is unambiguous, and in the <location-info> element. This document is unambiguous, and
should be interpreted consitently by receiving nodes if sent over the should be interpreted consistently by receiving nodes if sent over
network. the network.
5.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 the location is a Ethernet port in a spare cube. In this case the location is a
geodetic location, with the altitude represented as a building floor geodetic location, with the altitude represented as a building floor
number. The main location of user is inside the rectangle bounded by number. Mike's main location is the point specified by the geodetic
the geodetic coordinates specified. Further that the user is on the coordinates. Further, Mike is on the second floor of the building
second floor of the building located at these coordinates. Applying located at these coordinates. Applying rules #6 and #7 are applied,
rules #6 and #7 are applied, the PIDF-LO document creates a complex the PIDF-LO document creates a complex as shown below.
as shown below.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gml="http://www.opengis.net/gml"
entity="pres:mike@seattle.example.com"> entity="pres:mike@seattle.example.com">
<tuple id="sg89ab"> <tuple id="sg89ab">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<Polygon srsName="urn:ogc:def:crs:EPSG::4326" <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml"> <gml:pos>-43.5723 153.21760</gml:pos>
<exterior> </gml:Point>
<LinearRing>
<pos>37.775 -122.4194</pos>
<pos>37.555 -122.4194</pos>
<pos>37.555 -122.4264</pos>
<pos>37.775 -122.4264</pos>
<pos>37.775 -122.4194</pos>
</LinearRing>
</exterior>
</Polygon>
<cl:civicAddress> <cl:civicAddress>
<cl:FLR>2</cl:FLR> <cl:FLR>2</cl:FLR>
</cl:civicAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
5.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 her address is for her she normally lives in Sydney, the address is for her Sydney-based
Sydney-based apartment. Loraine decides to visit sunny San apartment. Loraine decides to visit sunny San Francisco, and when
Francisco, and when she gets there she plugs in her laptop and makes she gets there she plugs in her laptop and makes a call. Loraine's
a call. Loraine's laptop receives a new location from the visited laptop receives a new location from the visited network in San
network in San Francisco. As this system cannot be sure that the Francisco. As this system cannot be sure that the pre-existing, and
pre-existing and new location describe the same place, Loraine's new location, describe the same place, Loraine's computer generates a
computer generates a new PIDF-LO and will use this to represent new PIDF-LO and will use this to represent Loraine's location. If
Loraine's location. If Loraine's computer were to add the new Loraine's computer were to add the new location to her existing PIDF
location to her existing PIDF location document (breaking rule #3), location document (breaking rule #3), then the correct information
then the correct information may still be interpreted by location may still be interpreted by location recipient providing Loraine's
recipient providing Loraine's system applies rule #9. In this case system applies rule #9. In this case the resulting order of location
the resulting order of location information in the PIDF document information in the PIDF document should be San Francisco first,
should be San Francisco first, followed by Sydney. Since the followed by Sydney. Since the information is provided by different
information is provided by different sources, rule #8 should also be sources, rule #8 should also be applied and the information placed in
applied and the information placed in different tuples with San different tuples with the tuple containing the San Francisco location
Francisco first. first.
6. Geodetic Coordinate Representation 4. Geodetic Coordinate Representation
The geodetic examples provided in RFC 4119 [2] are illustrated using The geodetic examples provided in RFC 4119 [2] are illustrated using
the gml:location element which uses the gml:coordinates elements the gml:location element which uses the gml:coordinates elements
(inside the gml:Point element) and this representation has several (inside the gml:Point element) and this representation has several
drawbacks. Firstly, it has been deprecated in later versions of GML drawbacks. Firstly, it has been deprecated in later versions of GML
(3.1 and beyond) making it inadvisable to use for new applications. (3.1 and beyond) making it inadvisable to use for new applications.
Secondly, the format of the coordinates type is opaque and so can be Secondly, the format of the coordinates type is opaque and so can be
difficult to parse and interpret to ensure consistent results, as the difficult to parse and interpret to ensure consistent results, as the
same geodetic location can be expressed in a variety of ways. The same geodetic location can be expressed in a variety of ways. The
PIDF-LO Geodetic Shapes specification [7] provides a specific GML PIDF-LO Geodetic Shapes specification [6] provides a specific GML
profile for expressing commonly used shapes using simple GML profile for expressing commonly used shapes using simple GML
representations. The shapes defined in [7] are the recommended representations. The shapes defined in [6] are the recommended
shapes to ensure interoperability between location based shapes to ensure interoperability between location based
applications. applications.
7. 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
implement 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 [7] defines eight shape The PIDF-LO Geodetic Shapes specification [6] defines eight shape
types most of which are easily translated in shapes definitions used types most of which are easily translated into shapes definitions
in other applications and protocol, such as Open Mobile Alliance used in other applications and protocols, such as Open Mobile
(OMA) Mobile Location Protocol (MLP). For completeness the shape Alliance (OMA) Mobile Location Protocol (MLP). For completeness the
defined in [7] are listed below: shapes defined in [6] are listed below:
o Point (2d or 3d) o Point (2d or 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)
o Sphere (3d circle) o Sphere (3d)
o Ellipsoid (3d) o Ellipsoid (3d)
o Prism (3d polygon) o Prism (3d)
The GeoShape specification [7] also describes a standard set of The GeoShape specification [6] also describes a standard set of
coordinate reference systems (CRS), unit of measure and conventions coordinate reference systems (CRS), unit of measure (UoM) and
relating to lines and distances. GeoShape mandates the use the conventions relating to lines and distances. GeoShape mandates the
WGS-84 Coordinate reference system and restricts usage to EPSG-4326 use the WGS-84 Coordinate reference system and restricts usage to
for two dimensional (2d) shape representations and EPSG-4979 for EPSG-4326 for two dimensional (2d) shape representations and EPSG-
three dimensional (3d) volume representations. Distance and heights 4979 for three dimensional (3d) volume representations. Distance and
are expressed in meters using EPSG-9001. heights are expressed in meters using EPSG-9001.
7.1. Polygon Restriction It is RECOMMENDED that where uncertainty is included, a confidence of
68% (or one standard deviation) is used. Specifying a convention for
confidence enables better use of uncertainty values.
The Polygon shape type defined in [7] intentionally does not place 5.1. Polygon Restrictions
The Polygon shape type defined in [6] intentionally does not place
any constraints on the number of vertices that may be included to any constraints on the number of vertices that may be included to
define the bounds of the Polygon. This allows arbitrarily complex define the bounds of the 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 may complex shapes consisting of tens or even hundreds of points could
result in significant performance impacts. To mitigate this risk it result in significant performance impacts. To mitigate this risk it
is recommended that Polygons be restricted to a maximum of 16 points is recommended that Polygons be restricted to a maximum of 15
when the location information is intended for use in real-time discrete points (16 including the repeated point) when the location
applications. This limit of 16 points is chosen to allow moderately information is intended for use in real-time applications. This
complex shape definitions while at the same time enabling limit of 15 points is chosen to allow moderately complex shape
interworking with other location transporting protocols such as those definitions while at the same time enabling interoperation with other
defined in 3GPP ([8]) and OMA where the 16 point limit is already location transporting protocols such as those defined in 3GPP ([7])
imposed. and OMA where the 15 point limit is already imposed.
Polygons are defined with the minimum distance between two adjacent Polygons are defined with the minimum distance between two adjacent
vertices (geodesic). A connecting line SHALL NOT cross another vertices (geodesic). A connecting line SHALL NOT cross another
connecting line of the same Polygon. Polygons SHOULD be defined with connecting line of the same Polygon. Polygons SHOULD be defined with
the upward normal pointing up, this is accomplished by defining the the upward normal pointing up, this is accomplished by defining the
vertices in counter-clockwise direction. vertices in counter-clockwise direction.
7.2. Emergency Shape Representations Points specified in a polygon must be coplanar, and it is recommended
that where points are specified in 3 dimensions that all points
maintain the same altitude.
5.2. Complex Shape Examples
This section provides some examples of where some of the more complex
shapes are used, how they are determined, and how they are
represented in a PIDF-LO. Complete details on all of the Geoshape
types are provided in [6].
5.2.1. Polygon Representation and Usage
The polygon shape may be used to represent a building outline or
coverage area. The first and last points of the polygon must be the
same to form a closed shape. For example looking at the octagon
below with vertices, A,H,G,F,E,D,C,B,A. The resulting polygon will be
defined with 9 points, with the first and last points both having the
coordinates of point A.
B-------------C
/ \
/ \
/ \
A D
| |
| |
| |
| |
H E
\ /
\ /
\ /
G--------------F
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:octagon@example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
<gml:pos>43.211 -73.422</gml:pos> <!--H-->
<gml:pos>43.111 -73.322</gml:pos> <!--G-->
<gml:pos>43.111 -73.222</gml:pos> <!--F-->
<gml:pos>43.211 -73.122</gml:pos> <!--E-->
<gml:pos>43.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--C-->
<gml:pos>43.411 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5.2.2. Prism Representation and Usage
A prsim may be used to represent a section of a building or range of
floors of building. The prism extrudes a polygon by providing a
height element. It consists of a base made up of coplanar 3 points
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
element. If the height is negative, then the prism is extruded from
the top down, while a positive height extrudes from the bottom up.
The first and last points of the polygon must be the same to form a
closed shape.
For example looking at the cube below. If the prism is 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 the
distance between point A and point E in meters. The resulting
PIDF-LO is provided below.
G-----F
/| /|
/ | / |
H--+--E |
| C--|--B
| / | /
|/ |/
D-----A
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:mike@someprism.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
42.556844 -73.248157 36.6 <!--A-->
42.656844 -73.248157 36.6 <!--B-->
42.656844 -73.348157 36.6 <!--C-->
42.556844 -73.348157 36.6 <!--D-->
42.556844 -73.248157 36.6 <!--A-->
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
2.4
</gs:height>
</gs:Prism>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5.2.3. Arc Band Respresentation and Usage
The arc band shape type is commonly generated in wireless systems
where timing advance or code offsets sequences are used to compensate
for distances between handsets and the access point. The arc band is
represented as two radii emanating from a central point, and two
angles which represent the starting angle and the opening angle of
the arc. In a cellular environment the central point is nominally
the location of the cell tower, the two radii are determined by the
extent of the timing advance, and the two angles are generally
provisioned information.
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
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
the start angle is 20 degrees from north, and the opening angle is
120 degrees, an arc band representing Paul's location would look
similar to the figure below.
N ^ ,.__
| a(s) / `-.
| 20 / `-.
|--. / `.
| `/ \
| /__ \
| . `-. \
| . `. \
|. \ \ .
---c-- a(o) -- | | -->
|. / 120 ' | E
| . / '
| . / ;
.,' /
r(i)`. /
(3594m) `. /
`. ,'
`. ,'
r(o)`'
(4148m)
The resulting PIDF-LO is reflected below.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:paul@somecell.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>
-43.5723 153.21760
</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
3594
</gs:innerRadius>
<gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
4148
</gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
20
</gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
20
</gs:openingAngle>
</gs:ArcBand>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
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
enclosed area, and that Target may be anywhere in the defined area of
the arc band.
5.2.4. Ellipsoid Representation and Usage
The ellipsoid is the volume most commonly produced by GPS systems.
It is used extensively in navigation systems and wireless location
networks. The ellipsoid is constructed around a central point
specified in three dimensions, and three axies perpendicular to one
another are extended outwards from this point. These axies are
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
orientation of the ellipsoid. The orientation angle is measured in
degrees from north, and represents the direction of the semi-major
axis from the center point.
\
_.-\""""^"""""-._
.' \ | `.
/ v m \
| \ | |
| -c ----M---->|
| |
\ /
`._ _.'
`-...........-'
A PIDF-LO containing an ellipsoid would like something like the
sample below.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:somone@gpsreceiver.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">
<gml:pos>
42.5463 -73.2512 26.3
</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
7.7156
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
3.31
</gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
28.7
</gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
90
</gs:orientation>
</gs:Ellipsoid>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5.3. Emergency Shape Representations
In some parts of the world cellular networks constraints are placed In some parts of the world cellular networks constraints are placed
on the shape types that can be used to represent the location of an on the shape types that can be used to represent the location of an
emergency caller. These restrictions, while to some extend are emergency caller. These restrictions, while to some extend are
artificial, may pose significant interoperability problems in artificial, may pose significant interoperability problems in
emergency networks were they to be unilaterally lifted. The largest emergency networks were they to be unilaterally lifted. The largest
impact likely being on Public Safety Answer Point (PSAP) where impact likely being on Public Safety Answer Point (PSAP) where
multiple communication networks report emergency data. Wholesale multiple communication networks report emergency data. Wholesale
swap-out or upgrading of this equipment is deemed to be complex and swap-out or upgrading of this equipment is deemed to be complex and
costly and has resulted in a number of countries, most notably the costly and has resulted in a number of countries, most notably the
United States, to adopt migratory standards towards emergency IP United States, to adopt migratory standards towards emergency IP
telephony support. Where these migratory standards are implemented telephony support. Where these migratory standards are implemented
restrictions on acceptable geodetic shape types to represent the restrictions on acceptable geodetic shape types to represent the
location of an emergency caller may exist. Conversion from one shape location of an emergency caller may exist. Conversion from one shape
type to another should be avoided to eliminate the introduction of type to another should be avoided to eliminate the introduction of
errors in reported location. errors in reported location.
In North America the migratory VoIP emergency services standard (i2) In North America the migratory VoIP emergency services standard (i2)
[11] reuses the NENA E2 interface [12] which restriction geodetic [8] reuses the NENA E2 interface [9] which restriction geodetic shape
shape representation to a point, a point with an uncertain circle, a representation to a point, a point with an uncertain circle, a point
point with an altitude and an uncertainty circle. The NENA with an altitude and an uncertainty circle. The NENA recommended
recommended shapes can be represented in a PIDF-LO using the GeoShape shapes can be represented in a PIDF-LO using the GeoShape Point,
Point, GeoShape Circle, and GeoShape Sphere definitions respectively. GeoShape Circle, and GeoShape Sphere definitions respectively.
8. Recommendations 6. Recommendations
As a summary, this document gives a few recommendations on the usage As a summary, this document gives a few recommendations on the usage
of location information in PIDF-LO. Nine rules specified in of location information in PIDF-LO. Nine rules specified in
Section 5 give guidelines on avoiding ambiguity in PIDF-LO Section 3 give guidelines on avoiding ambiguity in PIDF-LO
interpretations when multiple locations may be provided to a Target interpretations when multiple locations may be provided to a Target
or location recipient. or location recipient.
It is recommend that only the shape types and shape representations It is recommended that only the shape types and shape representations
described in [7] be used to express geodetic locations for exchange described in [6] be used to express geodetic locations for exchange
between general applications. By standardizing geodetic data between general applications. By standardizing geodetic data
representation interoperability issues are mitigated. representation interoperability issues are mitigated.
It is recommended that GML Polygons be restricted to a maximum of 16 It is recommended that GML Polygons be restricted to a maximum of 16
points when used in location-dependent routing and other real-time points when used in location-dependent routing and other real-time
applications to mitigate possible performance issues. This allows applications to mitigate possible performance issues. This allows
for interoperability with other location protocols where this for interoperability with other location protocols where this
restriction applies. restriction applies.
Geodetic location may require restricted shape definitions in regions Geodetic location may require restricted shape definitions in regions
where migratory emergency IP telephony implementations are deployed. where migratory emergency IP telephony implementations are deployed.
Where the acceptable shape types are not understood restrictions to Where the acceptable shape types are not understood restrictions to
Point, Circle and Sphere representations should be used to Point, Circle and Sphere representations should be used to
accommodate most existing deployments. accommodate most existing deployments.
Conversions from one geodetic shape type to another should be avoided Conversions from one geodetic shape type to another should be avoided
where data is considered critical and the introduction of errors where data is considered critical and the introduction of errors
considered unacceptable. considered unacceptable.
If geodetic information is to be provided via DHCP, then a minimum In the absence of any application specific knowledge shapes and
resolution of 20 bits SHOULD be specified for both the Latitude and volumes should assumed to have a corresponding confidence value of
Longitude fields to achieve sub 100 meter precision. 68% when associated representing a Target's location.
9. Security Considerations 7. 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.
10. IANA Considerations 8. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
11. Acknowledgments 9. 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 and Henning Schulzrinne. Furthermore, we would like Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
her constructive comments in clarifying some aspects of the document. her constructive comments in clarifying some aspects of the document.
12. References 10. References
12.1. Normative references 10.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", [2] Peterson, J., "A Presence-based GEOPRIV Location Object
RFC 4119, December 2005. Format", RFC 4119, December 2005.
[3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [3] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", draft-ietf-geopriv-dhcp-civil-09 (work in Information", RFC 4676, October 2006.
progress), January 2006.
[5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), September 2006. progress), February 2007.
[6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [5] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[7] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes [6] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application
for the Representation of Uncertainty in PIDF-LO", January 2006. Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification 06-142, Version:
0.0.9, December 2006.
12.2. Informative References 10.2. Informative References
[8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal Technical Specification Group Code Network; Universal
Geographic Area Description (GAD)". Geographic Area Description (GAD)".
[9] Schulzrinne, H., "Common Policy: A Document Format for [8] "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
[11] "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP
Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec
2005". 2005".
[12] "NENA Standard for the Implementation of the Wireless Emergency [9] "NENA Standard for the Implementation of the Wireless Emergency
Service Protocol E2 Interface, NENA 05-001, Dec 2003". Service Protocol E2 Interface, NENA 05-001, Dec 2003".
Appendix A. Uncertainty in The RFC-3825 LCI Representation [10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
RFC-3825 [3] defines a binary geodetic representation referred to as Configuration Information", RFC 3825, July 2004.
Location Configuration Information LCI. The way that LCI represents
uncertainty is through a resolution parameter that indicates how many
binary digits of each axis are significant or accurate. This is
explained in detail in [3] with a series of examples, with a further
example provided in Appendix B of this document. In short LCI
describes a rectangular prism that is aligned along the north-south/
east-west/up-down axes.
This appendix should be regarded as informative only and provides
guidance on aspects concerning the interpretation of uncertainty as
it applies to the binary geodetic LCI representation defined in RFC-
3825 [3].
A.1. Conversion From LCI Form
From the example in RFC 3825, 38.89868 degrees is encoded into a
34bit twos-complement number:
000100110.1110011000001111111001000
The resolution value for this axis indicates how many of thess bits
are actually significant. A resolution of 18 indicates that the last
16 bits of the number could be either 1 or zero:
000100110.111001100xxxxxxxxxxxxxxxx
To determine the uncertainty assume a range from the minimum possible
value (all zeros for the last 16 bits) to the maximum (all ones):
000100110.1110011000000000000000000 to
000100110.1110011001111111111111111
This yields the range in the example to be between 38.8984375 degrees
and 38.9003906 degrees (rounded to 7 decimal places).
A.2. Conversion To LCI Form
Converting location information into the LCI format involves
converting the original shape to a rectangular prism. To do this
determine the minimum and maximum values for each of the axes:
latitude, longitude and altitude. This results in a slightly
increased area, but the overall effect is minimal.
+----------.....----------+
| _d^^^^^^^^^b_ |
| .d''yyyyyyyyyyy``b. |
| .p'yyyyyyyyyyyyyyyyy`q. |
|.d'yyyyyyyyyyyyyyyyyyy`b.|
.d'yyyyyyyyyyyyyyyyyyyyy`b.
::yyyyyyyyyyyyyyyyyyyyyyy::
:: ................... ::
::vvvvvvvvvvvvvvvvvvvvvvv::
`p.vvvvvvvvvvvvvvvvvvvvv.q'
|`p.vvvvvvvvvvvvvvvvvvv.q'|
| `b.vvvvvvvvvvvvvvvvv.d' |
| `q..vvvvvvvvvv..p' <-+----Area Increase
| ^q........p^ |
+---------''''------------+
It's important to note the resulting area cannot be less that the
starting area. This is because the starting area represents a set of
points and the Target may reside at anyone of these points with equal
probability. If the area is cropped there is a risk that the
Target's position will be one of the discarded points yielding an
incorrect result. In general the increases in area are minimal, for
a circular area, as shown, the increase ratio is 4:pi; a square
building will at most double the size of the area.
A.2.1. Example 1
Looking at a random example from 32.98004 degrees to 32.98054397
degrees the approximate distance is 56 meters. Converting each value
into a 34-bit twos-complement number yields the following:
000100000.1111101011100011111001110 to
000100000.1111101100000100111011100
^^^^^^^^^^^^^^^^^
To ensure that the encoded value represents the full range from the
lowest to highest value, take the common stem as marked this above.
There are 16 common bits between low and high. To check, convert the
value back by making the last 18 bits either 0 or 1 as described
earlier. This leads to a range from 32.9765625 degrees to 32.9843745
degrees, which is approximately 870 meters a significant increase
over the original 56 meters.
A.2.2. Example 2
Take the range from 31.9999985 degrees to 32.00000274 degrees, which
is about 0.5 meters in distances ranging around 32 degrees. This
results in the following binary values:
000011111.1111111111111111111001110 to
000100000.0000000000000000001011100
^^^
Only 3 bits are common to both values which yields an encoded range
from 0 to 64 degrees, or a distance of 3,500 kilometers.
A.3. Problem
The LCI encoding breaks when the uncertainty that is being
represented causes a change in a relatively significant binary digit.
This results in an expanded uncertainty, possibly very large,
depending on which binary digit changes. In many cases the change
will be in lower-order digits, which will result in a relatively
small increase in uncertainty, but certain values will yield an
almost useless location see Appendix A.2.2.
This problem is exacerbated at the three zero points - the Greenwich
Meridian, Equator and at the surface of the geoid (altitude). In
these cases, if the input uncertainty spans the zero point, the
resolution value ends up as zero; that is, it indicates that there is
no useful information for that parameter.
The original uncertainty has very little bearing on this problem - a
small value can be increased to any value. More precise location
determination technologies only reduce the probability of large
problems occurring, although the nature of the encoding is such that
any uncertainty can be greatly increased.
A.4. Conclusion
Uncertainty is a reality of location and important for a number of
applications. LCI's limited form means that adapting existing
uncertainty information, for example a circle as in Appendix A.2.2,
results in a small error. The introduction of this small encoding
error is, however, insignificant when compared to the error that can
be introduced by the way that the resolution parameter is
interpreted.
Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data
This appendix is informative only.
RFC 3825 [3] describes a means by which an end point may learn it
location from information encoded into DHCP option 123. The
following section describes how and end point can take this
information and represent it in a well formed PIDF-LO describing this
geodetic location.
The location information described in RFC 3825 consists of a
latitude, longitude, altitude and datum.
B.1. Latitude and Longitude
The latitude and longitude values are represented in degrees and
decimal degrees. Latitude values are positive if north of the
equator, and negative if south of the equator. Similarly
longitudinal values are positive if east of the Greenwich meridian,
and negative if west of the Greenwich meridian.
The latitude and longitude values are each 34 bit long fields
consisting of a 9 bit integer component and a 25 bit fraction
component, with negative numbers being represented in 2s complement
notation. The latitude and longitude fields are each proceeded by a
6 bit resolution field, the LaRes for latitude, and the LoRes for
longitude. The value in the LaRes field indicates the number of
significant bits to interpret in the Latitude field, while the value
in the LoRes field indicates the number of significant bits to
interpret in the Longitude field.
For example, if you are in Wollongong Australia which is located at
34 Degrees 25 minutes South and 150 degrees 32 minutes East, this
would translate to -34.41667, 150.53333 in decimal degrees. If these
numbers are translated to their full 34 bit representations, then we
arrive the following:
Latitude = 111011101.1001010101010101000111010
Longitude = 0100101101000100010001000010100001
RFC 3825, uses the LaRes and LoRes values to specify a lower and
upper boundary for location thereby specifying an area. The size of
the area specified is directly related to the value specified in the
LaRes and LoRes fields.
Using the previous example, if LaRes is set 7, then lower latitude
boundary can be calculated as -256+128+64+16+8+4, which is -36
degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which
is -35 degrees. LoRes may be used similarly for Longitude.
So what level of precision is useful? Well, certain types of
applications and regulations call for different levels of precision,
and the required precision may vary depending on how the location was
determined. For cellular 911 calls in the United States, for
example, if the network measures the location then the caller should
be within 100 meters, while if the handset does the measurement then
the location should be within 50 meters. Since DHCP is a network
based mechanism we will benchmark off 100 meters (approximately 330
ft) which is still a large area.
For simplicity we shall assume that we are defining a square, in
which we are equally to appear anywhere. The greatest distance
through this square is across the diagonal, so we make this 100
meters.
+----------------------+
| _/|
| _/ |
| _/ |
| _/ |
| _/ |
| 100_/ metres |
| _/ |
| _/ |
| _/ |
| _/ |
|_/ |
+----------------------+
The distance between the top and the bottom and the left and the
right is the same, the area being a square, and this works out to be
70.7 meters. When expressed in decimal degrees, the third point
after the decimal place represents about 100 meter precision, this
equates to 10 binary places of fractional part. A 70 meter distance
is required, so 11 fractional binary digits are necessary resulting
in a total of 20 bits of precision.
With -34.4167, 150.5333 encoded with 20 bits of precision for the
LaRes and LoRes, the corners of the enclosing square are:
Point 1 (-34.4170, 150.5332)
Point 2 (-34.4170, 150.5337)
Point 3 (-34.4165, 150.5332)
Point 4 (-34.4165, 150.5337)
B.2. Altitude
The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either meters, or
floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components.
B.3. Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used, with points
expressed in a counter-clockwise direction. If the altitude is
expressed in floors and is required, the altitude SHOULD be expressed
as a civic floor number as part of the same <location-info> element.
In the example above the GML for the location would be expressed as
follows:
<Polygon srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<exterior>
<LinearRing>
<pos>-34.4165 150.5332</pos>
<pos>-34.4170 150.5532</pos>
<pos>-34.4170 150.5537</pos>
<pos>-34.4165 150.5337</pos>
<pos>-34.4165 150.5332</pos>
</LinearRing>
</exterior>
</Polygon>
No Altitude
If a floor number of say 3 were included, then the location-info
element would contain the above information and the following:
<civicAddress
xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<FLR>2</FLR>
</civicAddress>
Civic Altitude
When altitude is expressed as an integer and fractional component, as
with the latitude and longitude, it expresses a range which requires
the prism form to be used. Care must be taken to ensure that the
points are defined in a counter-clockwise direction to ensure that
the upward normal points up.
Extending the previous example to include an altitude expressed in
metres rather than floors. AltRes is set to a value of 19, and the
Altitude value is set to 34. Using similar techniques as shown in
the latitude and longitude section, a range of altitudes between 32
meters and 40 meters is described. The prism would therefore be
defined as follows:
<Prism srsName="urn:ogc:def:crs:EPSG::4976"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml">
<base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332 32</gml:pos>
<gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:pos>-34.4170 150.5537 32</gml:pos>
<gml:pos>-34.4165 150.5337 32</gml:pos>
<gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</base>
<height uom="urn:ogc:def:uom:EPSG::9001">
8
</height>
</Prism>
The Method value SHOULD be set to Wiremap.
The timestamp value SHOULD be set to the time that location was
retrieved from the DHCP server.
The client application MAY insert any usage rules that are pertinent
to the user of the device and that comply with [9]. A guideline is
that the any retention-expiry value SHOULD NOT exceed the current
lease time.
The Provided-By element SHOULD NOT be populated as this is not
provided by the source of the location information.
The 3 completed PIDF-LO representations are provided below, and
represent a location without altitude, a location with a civic
altitude, and a location represented as a 3 dimensional rectangular
prism.
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332</gml:pos>
<gml:pos>-34.4170 150.5532</gml:pos>
<gml:pos>-34.4170 150.5537</gml:pos>
<gml:pos>-34.4165 150.5337</gml:pos>
<gml:pos>-34.4165 150.5332</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Geodetic Location Only PIDF-LO
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332</gml:pos>
<gml:pos>-34.4170 150.5532</gml:pos>
<gml:pos>-34.4170 150.5537</gml:pos>
<gml:pos>-34.4165 150.5337</gml:pos>
<gml:pos>-34.4165 150.5332</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
<cl:civilAddress>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Geodetic Location with Civic Floor PIDF-LO
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4976">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332 32</gml:pos>
<gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:pos>-34.4170 150.5537 32</gml:pos>
<gml:pos>-34.4165 150.5337 32</gml:pos>
<gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
8
</gs:height>
</gs:Prism>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Wiremap</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Rectangular Prism PIDF-LO
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
Siemens Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 62 change blocks. 
672 lines changed or deleted 429 lines changed or added

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