draft-ietf-geopriv-pdif-lo-profile-08.txt   draft-ietf-geopriv-pdif-lo-profile-09.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Updates: 4119 (if approved) Andrew Corporation Updates: 4119 (if approved) Andrew Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: December 31, 2007 Nokia Siemens Networks Expires: April 3, 2008 Nokia Siemens Networks
June 29, 2007 October 1, 2007
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-08.txt draft-ietf-geopriv-pdif-lo-profile-09.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 December 31, 2007. This Internet-Draft will expire on April 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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.
that the number of options that need to be implemented in order to In these circumstances the range of options that need to be
make use of it are reduced. There is growing interest in being able implemented are reduced. There is growing interest in being able to
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 the RFC 4119
(PIDF-LO). This document makes recommendations on how to constrain, (PIDF-LO). This document makes recommendations on how to constrain,
represent and interpret locations in a PIDF-LO. It further represent and interpret locations in a PIDF-LO. It further
recommends a subset of GML that is mandatory to implemented by recommends a subset of GML that is mandatory to implement by
applications involved in location based routing. applications involved in location based routing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Using Location Information . . . . . . . . . . . . . . . . . . 6 3. Using Location Information . . . . . . . . . . . . . . . . . . 6
3.1. Single Civic Location Information . . . . . . . . . . . . 8 3.1. Single Civic Location Information . . . . . . . . . . . . 9
3.2. Civic and Geospatial Location Information . . . . . . . . 8 3.2. Civic and Geospatial Location Information . . . . . . . . 9
3.3. Manual/Automatic Configuration of Location Information . . 9 3.3. Manual/Automatic Configuration of Location Information . . 10
4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10 3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11
5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12
5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 13
5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 14
5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 21 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative references . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 29 9.1. Normative references . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [2] is The Presence Information Data Format Location Object (PIDF-LO)
the recommended way of encoding location information and associated [RFC4119] is the recommended way of encoding location information and
privacy policies. Location information in a PIDF-LO may be described associated privacy policies. Location information in a PIDF-LO may
in a geospatial manner based on a subset of GMLv3, or as civic be described in a geospatial manner based on a subset of GMLv3, or as
location information [6]. A GML profile for expressing geodetic civic location information [I-D.ietf-geopriv-revised-civic-lo]. A
shapes in a PIDF-LO is described in [4]. Uses for PIDF-LO are GML profile for expressing geodetic shapes in a PIDF-LO is described
envisioned in the context of numerous location based applications. in [GeoShape]. Uses for PIDF-LO are envisioned in the context of
This document makes recommendations for formats and conventions to numerous location based applications. This document makes
make interoperability less problematic. recommendations for formats and conventions to 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 [3] and caters for a general presence data model is described in [RFC4479] and caters for
presence document to describe different aspects of the reachability a 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 and recommendations in this document flexibility is important, and recommendations in this document make
make no attempt to forbid the usage of a PIDF-LO in this manner. no attempt to forbid the usage of a PIDF-LO in this manner. This
This document provides a specific set of guidelines for building document provides a specific set of guidelines for building presence
preence documents when it is important to unambiguously convey documents when it is important to unambiguously convey exactly one
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 [1]. document are to be interpreted as described in [RFC2119].
The definition for "Target" is taken from [7]. 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. It must be described area or volume in which a Target can be found.
with sufficient precision to address the requirements of an intended
application.
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_ is 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 an LCS, or by the Target itself. It specifically does not refer by a LIS, or by the Target itself. It specifically does not refer to
to the LCP used to deliver location information either to the Target the LCP used to deliver location information either to the Target or
or the Recipient. the Recipient.
The term _source_ is used to refer to the LCS, 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> elements. The PIDF format provides for an unbounded number of <tuple>,
Each <tuple> element contains a single <status> element that may <device>, and <person> elements. Each of these elements contains a
contain more than one <geopriv> element as a child element. Each single <status> element that may contain more than one <geopriv>
<geopriv> element must contain at least the following two child element as a child. Each <geopriv> element must contain at least the
elements: <location-info> element and <usage-rules> element. One or following two child elements: <location-info> element and <usage-
more chunks of location information are contained inside a <location- rules> element. One or more chunks of location information are
info> element. 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"?> <?xml version="1.0" encoding="UTF-8"?>
<presence> <presence>
<tuple> -- #1 <tuple> -- #1
<status> <status>
skipping to change at page 6, line 38 skipping to change at page 6, line 38
... ...
location chunk #n location chunk #n
<usage-rules> <usage-rules>
</geopriv> </geopriv>
<geopriv> -- #2 <geopriv> -- #2
<geopriv> -- #3 <geopriv> -- #3
... ...
<geopriv> -- #m <geopriv> -- #m
</status> </status>
</tuple> </tuple>
<device>
<status>
<geopriv> -- #1
<location-info>
location chunk #1
location chunk #2
...
location chunk #n
<usage-rules>
</geopriv>
<geopriv> -- #2
<geopriv> -- #3
...
<geopriv> -- #m
</status>
</device>
<person>
<status>
<geopriv> -- #1
<location-info>
location chunk #1
location chunk #2
...
location chunk #n
<usage-rules>
</geopriv>
<geopriv> -- #2
<geopriv> -- #3
...
<geopriv> -- #m
</status>
</person>
<tuple> -- #2 <tuple> -- #2
<tuple> -- #3 <device> -- #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
than one way, each location description SHOULD reside in a than one way, each location description SHOULD reside in a
separate <tuple> element. separate <tuple>, <device>, or <person> element.
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 all objects refer to presence document (PIDF) MUST only be done if the locations refer
the same place. to the same place or are put into different element types. For
example, one location in a <tuple>, a second location in a
<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. series of different techniques, or the Target wishes to
represent her location as well as the location of her PC. In
general avoid putting more than one location into a document
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 common
source at the same time and by the same location determination source at the same time and by the same location determination
method. method.
skipping to change at page 8, line 5 skipping to change at page 8, line 41
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 compound location 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. first.
For example, a geodetic location describing an area, and a For example, a geodetic location describing an area, and a
civic location indicating the floor should be represented with civic location indicating the floor should be represented with
the area first followed by the civic location. the 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 <geopriv>
element containing a <status> element with a <geopriv> element, element, the priority of interpretation is given to the first
the priority of tuples SHOULD be based on position of the <tuple> <device> element in the document containing a location. If no
element within the PIDF document. That is to say, the tuple with <device> element containing a location is present in the document,
the highest priority location occurs earliest in the PIDF then priority is given to the first <tuple> element containing a
document. location. Locations contained in <person> tuples SHOULD only be
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 [5]. location, for example using the DHCP civic mechanism defined in
A Location Object is constructed consisting of a single PIDF [RFC4776]. A Location Object is constructed consisting of a single
document, with a single <tuple> element, a single <status> element, a PIDF document, with a single <tuple> or <device> element, a single
single <geopriv> element, and a single location chunk residing in the <status> element, a single <geopriv> element, and a single location
<location-info> element. This document is unambiguous, and should be chunk residing in the <location-info> element. This document is
interpreted consistently by receiving nodes if sent over the network. unambiguous, and should be interpreted consistently by receiving
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 below. resulting compound location information is 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: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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:mike@seattle.example.com"> entity="pres:mike@seattle.example.com">
<tuple id="sg89ab"> <device id="sg89ab">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326" <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>-43.5723 153.21760</gml:pos> <gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point> </gml:Point>
<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> <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</device>
</presence> </presence>
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 pre-existing, and
new location, describe the same place, Loraine's computer generates a new location, both describe the same place, Loraine's computer
new PIDF-LO and will use this to represent Loraine's location. If generates a new PIDF-LO and will use this to represent Loraine's
Loraine's computer were to add the new location to her existing PIDF location. If Loraine's computer were to add the new location to her
location document (breaking rule #3), then the correct information existing PIDF location document (breaking rule #3), then the correct
may still be interpreted by the Location Recipient providing information may still be interpreted by the Location Recipient
Loraine's system applies rule #9. In this case the resulting order providing Loraine's system applies rule #9. In this case the
of location information in the PIDF document should be San Francisco resulting order of location information in the PIDF document should
first, followed by Sydney. Since the information is provided by be San Francisco first, followed by Sydney. Since the information is
different sources, rule #8 should also be applied and the information provided by different sources, rule #8 should also be applied and the
placed in different tuples with the tuple containing the San information placed in different tuples with the tuple containing the
Francisco location first. San Francisco location first.
3.4. Multiple Location Objects in a Single PIDF-LO
Vanessa has her PC with her at the park, but to avoid being disturbed
she reports her location as being in the office. The resulting
PIDF-LO will have a <device> element showing the location of
Vanessa's PC as the park, and a <person> element saying that Vanessa
is in her office.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:mike@seattle.example.com">
<device id="nesspc-1">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
<cl:civicAddress>
<cl:FLR>2</cl:FLR>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</device>
</presence>
4. 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 [RFC4119] are illustrated
the <gml:location> element, which uses the <gml:coordinates> element using the <gml:location> element, which uses the <gml:coordinates>
inside the <gml:Point> element and this representation has several element inside the <gml:Point> element and this representation has
drawbacks. Firstly, it has been deprecated in later versions of GML several drawbacks. Firstly, it has been deprecated in later versions
(3.1 and beyond) making it inadvisable to use for new applications. of GML (3.1 and beyond) making it inadvisable to use for new
Secondly, the format of the coordinates type is opaque and so can be applications. Secondly, the format of the coordinates type is opaque
difficult to parse and interpret to ensure consistent results, as the and so can be difficult to parse and interpret to ensure consistent
same geodetic location can be expressed in a variety of ways. The results, as the same geodetic location can be expressed in a variety
PIDF-LO Geodetic Shapes specification [4] provides a specific GML of ways. The PIDF-LO Geodetic Shapes specification [GeoShape]
profile for expressing commonly used shapes using simple GML provides a specific GML profile for expressing commonly used shapes
representations. The shapes defined in [4] are the recommended using simple GML representations. The shapes defined in [GeoShape]
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 [4] defines eight shape The PIDF-LO Geodetic Shapes specification [GeoShape] defines eight
types most of which are easily translated into shapes definitions shape types most of which are easily translated into shapes
used in other applications and protocols, such as Open Mobile definitions used in other applications and protocols, such as Open
Alliance (OMA) Mobile Location Protocol (MLP). For completeness the Mobile Alliance (OMA) Mobile Location Protocol (MLP). For
shapes defined in [4] 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)
o Sphere (3d) o Sphere (3d)
o Ellipsoid (3d) o Ellipsoid (3d)
o Prism (3d) o Prism (3d)
All above-listed shapes are mandatory to implement. All above-listed shapes are mandatory to implement.
The GeoShape specification [4] also describes a standard set of The GeoShape specification [GeoShape] also describes a standard set
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 WGS-84 conventions relating to lines and distances. The use of the WGS-84
coordinate reference system and the usage of EPSG-4326 (as identified coordinate reference system and the usage of EPSG-4326 (as identified
by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape
representations and EPSG-4979 (as identified by the URN representations and EPSG-4979 (as identified by the URN
urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume
representations is mandated. Distance and heights are expressed in representations is mandated. Distance and heights are expressed in
meters using EPSG-9001 (as identified by the URN 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 identified by the URN urn:ogc:def:uom:EPSG::9101
Implementations MUST specify the CRS using the srsName attribute on Implementations MUST specify the CRS using the srsName attribute on
the outermost geometry element. The CRS MUST NOT be respecified or the outermost geometry element. The CRS MUST NOT be respecified or
changed for any sub-elements. The srsDimension attribute SHOULD be changed for any sub-elements. The srsDimension attribute SHOULD be
omitted, since the number of dimensions in these CRSs is known. A omitted, since the number of dimensions in these CRSs is known. A
CRS MUST be specified using the above URN notation only, CRS MUST be specified using the above URN notation only;
implementations do not need to support user-defined CRSs. implementations do not need to support user-defined CRSs.
It is RECOMMENDED that where uncertainty is included, a confidence of It is RECOMMENDED that where uncertainty is included, a confidence of
68% (or one standard deviation) is used. Specifying a convention for 68% (or one standard deviation) is used. Specifying a convention for
confidence enables better use of uncertainty values. confidence enables better use of uncertainty values.
5.1. Polygon Restrictions 5.1. Polygon Restrictions
The Polygon shape type defined in [4] intentionally does not place The Polygon shape type defined in [GeoShape] intentionally does not
any constraints on the number of vertices that may be included to place any constraints on the number of vertices that may be included
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 it result in significant performance impacts. To mitigate this risk it
is recommended that Polygon shapes be restricted to a maximum of 15 is recommended that Polygon shapes be restricted to a maximum of 15
points (16 including the repeated point) when the location points (16 including the repeated point) when the location
information is intended for use in real-time applications. This information is intended for use in real-time applications. This
limit of 15 points is chosen to allow moderately complex shape limit of 15 points is chosen to allow moderately complex shape
definitions while at the same time enabling interoperation with other definitions while at the same time enabling interoperation with other
location transporting protocols such as those defined in 3GPP (see location transporting protocols such as those defined in 3GPP (see
[9]) and OMA where the 15 point limit is already imposed. [3GPP-TS-23_032]) and OMA where the 15 point limit is already
imposed.
Polygons are defined with the minimum distance between two adjacent The edges of a polygon are defined by the shortest path between two
vertices (geodesic). To avoid the incursion of significant errors points in space (not a geodesic curce). To avoid significant errors
length between adjacent vertices SHOULD be restricted to a maximum of arising from potential geodesic interpolation, the length between
130km. More information relating to this restriction is provided in adjacent vertices SHOULD be restricted to a maximum of 130km. More
[4]. information relating to this 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 SHOULD be defined with the upward normal pointing up, this Polygons SHOULD be defined with the upward normal pointing up. This
is accomplished by defining the vertices in counter-clockwise is accomplished by defining the vertices in a counter-clockwise
direction. direction.
Points specified in a polygon MUST be coplanar, and it is RECOMMENDED Points specified in a polygon MUST be coplanar and it is RECOMMENDED
that where points are specified in 3 dimensions that all points that where points are specified in 3 dimensions that all points
maintain the same altitude. maintain 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 [4]. types are provided in [GeoShape].
5.2.1. Point 5.2.1. Point
The point shape type is the simplest form of geodetic LI, which is The point shape type is the simplest form of geodetic LI, which is
natively supported by GML. The gml:Point element is used when there natively supported by GML. The gml:Point element is used when there
is no known uncertainty. A point also forms part of a number of is no known uncertainty. A point also forms part of a number of
other geometries. A point may be specified using either WGS 84 other geometries. A point may be specified using either WGS 84
(latitude, longitude) or WGS 84 (latitude, longitude, altitude). The (latitude, longitude) or WGS 84 (latitude, longitude, altitude). The
next example shows a 2d point: next example shows a 2d point:
<?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="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:point2d@example.com"> entity="pres:point2d@example.com">
<tuple id="sg89abcd"> <device id="sg89abcd">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326" <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </device>
</presence> </presence>
The next example shows a 3d point: The next example shows a 3d point:
<?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="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:point3d@example.com"> entity="pres:point3d@example.com">
<tuple id="sg89ab5"> <device id="sg89ab5">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979" <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-34.407 150.883 24.8</gml:pos> <gml:pos>-34.407 150.883 24.8</gml:pos>
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </device>
</presence> </presence>
5.2.2. Polygon 5.2.2. Polygon
The polygon shape may be used to represent a building outline or The polygon shape 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 octagon below with vertices, the same. For example, looking at the hexagon below with vertices,
A, H, G, F, E, D, C, B, A. The resulting polygon will be defined with A, F, E, D, C, B, A. The resulting polygon will be defined with 7
9 points, with the first and last points both having the coordinates points, with the first and last points both having the coordinates of
of point A. point A.
B-------------C B-------------C
/ \ / \
/ \ / \
/ \ / \
A D A D
| |
| |
| |
| |
H E
\ / \ /
\ / \ /
\ / \ /
G--------------F F--------------E
<?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="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:octagon@example.com"> entity="pres:octagon@example.com">
<tuple id="sg89ab"> <tuple id="sg89ab">
<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>
<gml:LinearRing> <gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos> <!--A--> <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> <!--F-->
<gml:pos>43.111 -73.322</gml:pos> <!--G--> <gml:pos>43.111 -73.222</gml:pos> <!--E-->
<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.311 -73.122</gml:pos> <!--D-->
<gml:pos>43.411 -73.222</gml:pos> <!--C--> <gml:pos>43.411 -73.222</gml:pos> <!--C-->
<gml:pos>43.411 -73.322</gml:pos> <!--B--> <gml:pos>43.411 -73.322</gml:pos> <!--B-->
<gml:pos>43.311 -73.422</gml:pos> <!--A--> <gml:pos>43.311 -73.422</gml:pos> <!--A-->
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</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 6 Figure 7
In addition to the form shown in Figure 6 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 which 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 7. Both forms are permitted. compact form is shown in Figure 8. Both forms are permitted.
<?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="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:octagon@example.com"> entity="pres:octagon@example.com">
<tuple id="sg89ab"> <tuple id="sg89ab">
<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>
<gml:LinearRing> <gml:LinearRing>
<gml:posList>43.311 -73.422 43.211 -73.422 <gml:posList>43.311 -73.422 43.111 -73.322
43.111 -73.322 43.111 -73.222 43.111 -73.222 43.311 -73.122
43.211 -73.122 43.311 -73.122
43.411 -73.222 43.411 -73.322 43.411 -73.222 43.411 -73.322
43.311 -73.422 43.311 -73.422
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</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 8
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 centre
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
skipping to change at page 29, line 9 skipping to change at page 31, line 9
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.
9. References 9. References
9.1. Normative references 9.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005.
[3] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[4] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Schema for use by the Internet Engineering Task Force (IETF)", July 2006.
Candidate OpenGIS Implementation Specification 06-142, Version:
0.0.9, December 2006.
9.2. Informative References [GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007.
[5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [I-D.ietf-geopriv-revised-civic-lo]
and DHCPv6) Option for Civic Addresses Configuration Thomson, M. and J. Winterbottom, "Revised Civic Location
Information", RFC 4776, November 2006. Format for PIDF-LO",
draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
February 2007.
[6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 9.2. Informative References
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), February 2007.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
Polk, "Geopriv Requirements", RFC 3693, February 2004. (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[8] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Configuration Protocol Option for Coordinate-based Location J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
Configuration Information", RFC 3825, July 2004.
[9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [3GPP-TS-23_032]
Technical Specification Group Code Network; Universal Geographic "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Area Description (GAD)". Technical Specification Group Code Network; Universal
Geographic Area Description (GAD)".
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
 End of changes. 61 change blocks. 
182 lines changed or deleted 252 lines changed or added

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