draft-ietf-geopriv-pdif-lo-profile-02.txt   draft-ietf-geopriv-pdif-lo-profile-03.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Expires: August 8, 2006 Andrew Corporation Expires: September 4, 2006 Andrew Corporation
H. Tschofenig H. Tschofenig
Siemens Siemens
February 4, 2006 March 3, 2006
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-02.txt draft-ietf-geopriv-pdif-lo-profile-03.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 August 8, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 looks at existing interpret locations in a PIDF-LO. It further recommends a subset of
communications standards that make use of geodetic information for GML that MUST be implemented by applications involved in location
routing purposes and recommends a subset of GML that MUST be based routing.
implemented by applications to allow location dependent routing to
occur.
Table of Contents Table of Contents
1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 4 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 3
1.1. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using Location Information . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Single Civic Location Information . . . . . . . . . . . . 8 4. Using Location Information . . . . . . . . . . . . . . . . . . 6
4.2. Civic and Geospatial Location Information . . . . . . . . 9 4.1. Single Civic Location Information . . . . . . . . . . . . 7
4.2. Civic and Geospatial Location Information . . . . . . . . 8
4.3. Manual/Automatic Configuration of Location Information . . 11 4.3. Manual/Automatic Configuration of Location Information . . 11
5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12
6. Uncertainty in Location Representation . . . . . . . . . . . . 14 6. Geodetic Shape Representation . . . . . . . . . . . . . . . . 13
6.1. Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.3. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 24 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. One Dimensions . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative references . . . . . . . . . . . . . . . . . . . 19
7.4. Three Dimensions . . . . . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . . 19
7.5. Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 20
7.6. Temporal Dimensions . . . . . . . . . . . . . . . . . . . 26 A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 20
7.7. Units of Measure . . . . . . . . . . . . . . . . . . . . . 26 A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.8. Coordinate Reference System (CRS) . . . . . . . . . . . . 26 A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 22
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative references . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 34
A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 34
A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. CHANGES SINCE LAST TIME 1. CHANGES SINCE LAST TIME
1.1. 01 changes [[This section is informational only and will be removed before the
final version.]]
1.1. 03 changes
Removed some shape defintions, ellipses, arcbands.
Removed OMA shape definition comparisons.
Modified examples to use new civicAddr draft data.
Made extensive references to the GeoShape Draft.
1.2. 01 changes
minor changes to the abstract. minor changes to the abstract.
Minor changes to the introduction. Minor changes to the introduction.
Added and appendix to take implementers through how to create a Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [3]. PIDF-LO from data received using DHCP option 123 as defined in [2].
Rectified examples to use position and pos rather than location and Rectified examples to use position and pos rather than location and
point. point.
Corrected example 3 so that it does not violate SIP rules. Corrected example 3 so that it does not violate SIP rules.
Added addition geopriv elements to the status component of the figure Added addition geopriv elements to the status component of the figure
in "Using Location Information" to more accurately reflect the in "Using Location Information" to more accurately reflect the
cardinality issues. cardinality issues.
Revised text in section "Geodection Coordinate Representation. Revised text in section Geodetic Coordinate Representation. Removed
Removed last example as this was addressed with the change to last example as this was addressed with the change to position and
position and pos in previous examples. pos in previous examples.
2. Introduction 2. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [1] is The Presence Information Data Format Location Object (PIDF-LO) [3] 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 PIDF-LO may be associated privacy policies. Location information in a PIDF-LO may
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. Uses for PIDF-LO are envisioned in the civic location information [4]. A GML profile for expressing
context of numerous location based applications. This document makes geodetic shapes in a PIDF-LO is described in [5].Uses for PIDF-LO are
recommendations for formats and conventions to make interoperability envisioned in the context of numerous location based applications.
less problematic. To enhance clarify formats comparisons between GML This document makes recommendations for formats and conventions to
and the 3GPP Mobile Location Protocol (MLP) standard [4], are make interoperability less problematic.
examined.
3. Terminology 3. 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 [2]. document are to be interpreted as described in [1].
In this document a "discrete location" is defined as a location that
can be found based on the information used to describe it. It is not
necessarily a single point in space, but may be an area or volume
depending on what is being defined and the required precision.
4. Using Location Information 4. 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.
skipping to change at page 7, line 41 skipping to change at page 6, line 41
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 the following conventions being adopted: ambiguities led the following conventions being adopted:
Rule #1: A GeoPriv tuple MUST completely define a specific location. Rule #1: A geopriv element MUST describe a discrete location.
Rule #2: Where a location can be uniquely described in more than one Rule #2: Where a discrete location can be uniquely described in more
way, each location description SHOULD reside in a separate tuple. than one way, each location description SHOULD reside in a
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. location.
Rule #4: Providing more than one location in a single <location-info> Rule #4: Providing more than one location in a single <location-info>
element SHOULD be avoided where possible. element SHOULD be avoided where possible.
Rule #5: When providing more than one location in a single <location- Rule #5: When providing more than one location in a single
info> element they MUST be provided by a common source. If you <location-info> element the locations MUST be provided by a common
have more than one location in the <location-info> element, then source.
the combination (complex of)these elements defines the complete
location.
Rule #6: Providing more than one location in a single <location-info> Rule #6: Providing more than one location in a single <location-info>
element SHOULD only be done if they form a complex to describe the element SHOULD only be done if they form a complex to describe the
same location. For example, a geodetic location describing a same location. For example, a geodetic location describing a
point, and a civic location indicating the floor in a building. point, and a civic location indicating the floor in a building.
Rule #7: Where a location complex is provided in a single <location- Rule #7: Where a location complex is provided in a single
info> element, the higher precision locations MUST be provided <location-info> element, the macro locations MUST be provided
first. For example, a geodetic location describing a point, and a first. For example, a geodetic location describing an area, and a
civic location indicating the floor MUST be represented with the civic location indicating the floor MUST be represented with the
point 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. Initial priority location occurs earliest in the PIDF document. Initial
priority SHOULD be determined by the originating UA, the final priority SHOULD be determined by the originating UA, the final
priority MAY be determined by a proxy along the way. priority MAY be determined by a proxy along the way, or the UAS.
Rule #9: Where multiple PIDF documents are contained within a single Rule #9: Where multiple PIDF documents are contained within a single
request, document selection SHOULD be based on document order. request, document selection SHOULD be based on document order.
The following examples illustrate the useful of these rules. The following examples illustrate the application of these rules.
4.1. Single Civic Location Information 4.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 [5]. She constructs a Location Object location, for example using [6]. A Location Object is constructed
which consists of a single PIDF document, with a single geopriv consisting of a single PIDF document, with a single geopriv tuple,
tuple, with a single location residing in the <location-info> and a single location residing in the <location-info> element. This
element. This is largely unambiguous, and if this location is sent document is unambiguous, and should be interpreted correctly if sent
over the network, providing it understands civic addresses, correct of the network.
handling of any request should be possible.
4.2. Civic and Geospatial Location Information 4.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. Mike's computer receives a location Ethernet port in a spare cube. Mike's computer receives a location
over DHCP as defined in [3]. In this case the location is a geodetic over DHCP as defined in [2]. In this case the location is a geodetic
location, with the altitude represented as a building floor number. location, with the altitude represented as a building floor number.
This is constructed by Mike's computer into the following PIDF This is constructed by Mike's computer into the following PIDF
document: document:
<?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:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
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>
<cl:civilAddress> <cl:civicAddress>
<cl:FLR>2</cl:FLR> <cl:FLR>2</cl:FLR>
</cl:civilAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules/>
</gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2006-01-30T20:57:29Z</timestamp>
</tuple> </tuple>
<tuple id="sg89ae"> <tuple id="sg89ae">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:position> <Polygon srsName="urn:ogc:def::crs:EPSG::4326"
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326"> xmlns="http://www.opengis.net/gml">
<gml:pos>37.775 -122.4194</gml:pos> <exterior>
</gml:Point> <LinearRing>
</gml:position> <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>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules/>
</gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2006-01-30T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
The constructed PIDF document contains two geopriv elements each in a The constructed PIDF document contains two geopriv elements each in a
separate PIDF tuple, the first being a civic address made up of only separate PIDF tuple, the first being a civic address made up of only
floor, the second containing the provided geodetic information. If floor, the second containing the provided geodetic information. If
the location is required for routing purposes, which information is the location is required for routing purposes, which information is
used? Applying rule #8, we will likely fail, or at a minimum need to used? Applying rule #8, we will likely fail, or at a minimum need to
fall back to the second tuple describing the geodetic location, a fall back to the second tuple describing the geodetic location, a
route described by floor only is precise enough in the normal case to route described by floor only is not precise enough in the normal
permit route selection. If rule #6 and #7 are applied, then the case to permit route selection. If rule #6 and #7 are applied, then
revised PIDF-LO document would look creates a complex as shown below. the revised PIDF-LO document creates a complex 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:civilLoc" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
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>
<gml:position> <Polygon srsName="urn:ogc:def:crs:EPSG::4326"
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326"> xmlns="http://www.opengis.net/gml">
<gml:pos>37.775 -122.4194</gml:pos> <exterior>
</gml:Point> <LinearRing>
</gml:position> <pos>37.775 -122.4194</pos>
<cl:civilAddress> <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:FLR>2</cl:FLR> <cl:FLR>2</cl:FLR>
</cl:civilAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <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>
It is now clear that the main location of user is a geodetic location It is now clear that the main location of user is inside the
at latitude 37.775 and longitude -122.4194. Further that the user is rectangle bounded by the geodetic coordinates specfied. Further that
on the second floor of the building located at those coordinates. the user is on the second floor of the building located at these
coordinates.
4.3. Manual/Automatic Configuration of Location Information 4.3. Manual/Automatic Configuration of Location Information
Erin has a predefined civic location stored in her laptop, since she Loraine has a predefined civic location stored in her laptop, since
normally lives in Sydney, the address in her address is for her she normally lives in Sydney, the address in her address is for her
Sydney-based apartment. Erin decides to visit sunny San Francisco, Sydney-based apartment. Loraine decides to visit sunny San
and when she gets there she plugs in her laptop and makes a call. Francisco, and when she gets there she plugs in her laptop and makes
Erin's laptop receives a new location from the visited network in San a call. Loraine's laptop receives a new location from the visited
Francisco and adds this to her existing PIDF location document. network in San Francisco. As ths system cannot be sure that the pre-
Applying rule #9, the resulting order of location information in the existing and new location describe the same place, Loraine's computer
PIDF document should be San Francisco first, followed by Sydney. generates a new PIDF-LO and will use this to represent Loraine's
Since the information is provided by different sources, rule #8 location. If Loraine's computer were to add the new location to her
should also be applied and the information places in different tuples existing PIDF location document (breaking rule #3), then the correct
with San Francisco first. information may still be interpretted by location recipient providing
Loraine's system applies rule #9. In this case the resulting order
of location information in the PIDF document should be San Francisco
first, followed by Sydney. Since the information is provided by
different sources, rule #8 should also be applied and the information
placed in different tuples with San Francisco first.
5. Geodetic Coordinate Representation 5. Geodetic Coordinate Representation
The geodetic examples provided in [1] are illustrated using the gml: The geodetic examples provided in [3] are illustrated using the gml:
location element which uses the gml:coordinates elements (inside the location element which uses the gml:coordinates elements (inside the
gml:Point element) and this representation has several drawbacks. gml:Point element) and this representation has several drawbacks.
Firstly, it has been deprecated in later versions of GML (3.1 and Firstly, it has been deprecated in later versions of GML (3.1 and
beyond) making it inadvisable to use for new applications. Secondly, beyond) making it inadvisable to use for new applications. Secondly,
the format of the coordinates type is opaque and so can be difficult the format of the coordinates type is opaque and so can be difficult
to parse and interpret to ensure consistent results, as the same to parse and interpret to ensure consistent results, as the same
geodetic location can be expressed in a variety of ways. An geodetic location can be expressed in a variety of ways. The PIDF-LO
alternative is to use the gml:position and gml:pos elements. These Geodetic Shapes specification [5] provides a specific GML profile for
elements have a structured format, in that each field is represented expressing commonly used shapes using simple GML representations.
as a double, and a single space exists between each field. Such a The shapes defined in [5] are the recommended shapes to ensure
format does not introduce the same degree of misinterpretation. The interoperability between location based applications.
recommended representation therefore for expressing geodetic
coordinates for location based routing applications would be:
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos>37.775 -122.422</gml:pos>
</gml:Point>
</gml:position>
The coordinate reference system (CRS) indicates which numbers in the
sequence equate to latitude, longitude etc, and in addition to this
the CRS also provides an indication of direction represented by the
sign of the number. For example, in WGS-84 (represented as CRS:
4326), as shown in the code snippet above, the format is latitude
followed by longitude. A positive value for latitude represents a
location north of the equator while a negative value represents a
location south of the equator. Similarly for longitude, a positive
value represents a location east of Greenwich, while a negative value
represents a location west of Greenwich.
EPSG 4326 is the two dimensional WGS-84 representation, if we wanted
to represented this in three dimensions, that is with an altitude as
well, then we would use EPSG 4979 and the format would be as follows:
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4979">
<gml:pos>37.775 -122.422 22</gml:pos>
</gml:Point>
</gml:position>
The format using CRS:4979 is similar to CRS:4326, though we now have
an altitude value. Specifically the altitude is provided in metres
above the geoid, which will not be useful for general routing
applications since the geoid is generally neither ground-level nor
sea-level. However, for more specialized geographic applications it
may be useful.
6. Uncertainty in Location Representation 6. 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 today 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 implement 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.
There are six common ways to represent location and uncertainty, but [5] defines eight shape types most of which are easily translated in
are listed below for completeness: shapes definitions used in other applications and protocol, such as
Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For
o Arc band completeness the shape defined in [5] are listed below:
o Ellipsoid point with uncertainty circle
o Polygon
o Ellipsoid point with altitude
o Ellipsoid point with uncertainty ellipse
o Ellipsoid point with altitude and uncertainty ellipsoid
GML was designed to provide a very flexible abstraction on which
specific representations of geometric and geographic schemes could be
extended. Representing some of the above shapes is difficult if not
impossible using base GML. However, only a subset of GML, namely
feature.xsd, is mandatory for a PIDF-LO implementation. Extending
GML to easily represent these shapes may lead to interoperability
issues and so is not recommended. The authors of this document were
unable to find a means to express either an ellipse or and ellipsoid
using only the elements defined in feature.xsd.
The following sections describe four shapes that can be defined in
GML, and show the equivalent representation in 3GPP MLP [4].
6.1. Arc band
Arc band is used primarily where timing advance (TA) information is
known. Timing advance is a mechanism used in wireless communications
to help ensure that handsets and base-stations remained synchronized.
Timing advance is stepped based on signal propagation and is fairly
deterministic, for GSM each increase in TA value represents 553.85
metres.
The arc band type was developed to represent the area between two
successive TA values and an antenna opening. This is presented in
3GPP as a point, two radii, and two angles representing the start and
the stop of the angles for the opening.
,..__
/ `-.
/ `-.
/ `.
/ \
/__ \
. `-. \
start. `. \
angle \ .
. | |
o ' |
. / '
. / ;
stop . .,' /
angle `. /
`. /
`. ,'
`. ,'
`'
<pd>
<time utc_off="+1000">20041201092843</time>
<shape>
<CircularArcArea>
<coord>
<X>42.5463</X>
<Y>-73.2512</Y>
</coord>
<inRadius>1938.5</inRadius>
<outRadius>2492.3</outRadius>
<startAngle>63.7</startAngle>
<stopAngle>118.4</stopAngle>
</CircularArcArea>
</shape>
</pd>
The GML representation of this is below:
<?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:gml="http://opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:extentOf>
<gml:Polygon>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve>
<gml:segments>
<gml:ArcByCenterPoint >
<gml:pos
srsName="urn:EPSG:geographicCRS:4326">
42.5463 -73.2512
</gml:pos>
<gml:radius uom="urn:EPSG:uom:9001">
2492.3
</gml:radius>
<!--
It is difficult to determine the correct
interpretation of GML and EPSG #4326 to
determine how these angles are to be
interpreted.
Neither specification specifies how the values
are to be interpolated. That is, the direction
of rotation from start angle to end angle. It
is therefore assumed that a "clockwise"
(Northing to Easting) direction is chosen to
link the two points on the arc.
It is also assumed that a value of 0 degrees
indicates Northing and 90 degrees indicates
Easting.
-->
<gml:startAngle uom="urn:EPSG:uom:9102">
63.7
</gml:startAngle>
<gml:endAngle uom="urn:EPSG:uom:9102">
118.4
</gml:endAngle>
</gml:ArcByCenterPoint>
<gml:LineStringSegment>
<gml:posList
srsName="urn:EPSG:geographicCRS:4326">
42.535651 -73.224473 42.538018 -73.230411
</gml:posList>
</gml:LineStringSegment>
<gml:ArcByCenterPoint >
<gml:pos
srsName="urn:EPSG:geographicCRS:4326">
42.5463 -73.2512
</gml:pos>
<!--
Note that the decision to go with a "clockwise"
pass means that the start position of this
second arc is not contiguous with the end of
the last line.
-->
<gml:radius uom="urn:EPSG:uom:9001">
1938.5
</gml:radius>
<gml:startAngle uom="urn:EPSG:uom:9102">
63.7
</gml:startAngle>
<gml:endAngle uom="urn:EPSG:uom:9102">
118.4
</gml:endAngle>
</gml:ArcByCenterPoint>
<gml:LineStringSegment>
<gml:posList
srsName="urn:EPSG:geographicCRS:4326">
42.554016 -73.230007 42.556220 -73.223952
</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2004-12-01T09:28:43+10:00</timestamp>
</tuple>
</presence>
This representation poses a few potential problems over the 3GPP
representation. In the 3GPP representation the point is absolute,
and everything else is defined relative to this point, ensuring that
the band is indeed bounded. The representation of arc band above
does not share all of these properties. In the GML arc band
representation above, the point and radii are relative, but the
bounding lines of the starting and finishing angles are not, these
are necessarily defined as independent line segments. By having to
define the arc enclosures as individual line segments it is possible
to define an unbounded arc band which would consist of two arcs some
arbitrary distance apart with two lines that may or may not intersect
them.
A second concern with this representing uncertainty using this
method, is that there is no explicit statement or way of indicating
to the receiving application what type of uncertainty is being
represented. Today several different representations of uncertainty
are valid with in the same application, so knowing which type is
being used, and how to interpret it is important, and this is
particularly true if the shape must also be validated as is the case
above.
Ensuring the legality of this shape type when represented in GML is
more complex than in MLP as the type must first be determined before
its validity can be assessed. Users of this shape type may be better
served by a formal shape definition being introduced into GeoPriv so
that these problems can be more readily overcome.
6.2. Ellipsoid Point With Uncertainty Circle
This shape type is used extensively over the North American NENA
defined E2 interface for transporting mobile geodetic location from
the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is
defined as a WGS-84 point (ellipsoid point), and a radius or
uncertainty around that point, specified in metres. The 3GPP MLP
representation for an ellipsoid point with uncertainty is defined as
follows:
<pd>
<time utc_off="+1000">20041201092843</time>
<shape>
<CircularArea>
<coord>
<X>42.5463</X>
<Y>-73.2512</Y>
</coord>
<radius>850.24</radius>
</CircularArea>
</shape>
</pd>
This shape is similarly defined in GML below:
<?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:gml="http://opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:extentOf>
<gml:Polygon>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve>
<gml:segments>
<gml:CircleByCenterPoint >
<gml:pos
srsName="urn:EPSG:geographicCRS:4326">
42.5463 -73.2512
</gml:pos>
<gml:radius uom="urn:EPSG:uom:9001">
850.24
</gml:radius>
</gml:CircleByCenterPoint>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2004-12-01T09:28:43+10:00</timestamp>
</tuple>
</presence>
This type does not have all of the problems associated with the arc
band representation, in that the radius of the circle is relative to
the centre, and so the validation is unnecessary. However it does
suffer from the potential problem that the application still needs to
determine the type of uncertainty being represented, though this
maybe made more clear through the explicit use of the gml:
CircleByCenterPoint element.
6.3. Polygon
A polygon is defined as a set of points to form an enclosed bounded
shape. It is here that GML and the 3GPP shapes are most similar.
The representation for a polygon in GML is given first:
<?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:gml="http://opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:extentOf>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList
srsName="urn:EPSG:geographicCRS:4326">
42.556844 -73.248157
42.549631 -73.237283
42.539087 -73.240328
42.535756 -73.254242
42.542969 -73.265115
42.553513 -73.262075
42.556844 -73.248157
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:extentOf>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2004-12-13T14:49:53+10:00</timestamp>
</tuple>
</presence>
The GML object here is clear in its definition. A gml:LinearRing
MUST have a minimum of four points, with the first and last points
being the same. The 3GPP MLP representation for a polygon is
provided below.
<pd>
<time utc_off="+1000">20041201092843</time>
<shape>
<Polygon>
<outerBoundaryIs>
<LinearRing>
<coord>
<X>42.556844</X>
<Y>-73.248157</Y>
</coord>
<coord>
<X>42.549631</X>
<Y>-73.237283</Y>
</coord>
<coord>
<X>42.539087</X>
<Y>-73.240328</Y>
</coord>
<coord>
<X>42.535756</X>
<Y>-73.254242</Y>
</coord>
<coord>
<X>42.542969</X>
<Y>-73.265115</Y>
</coord>
<coord>
<X>42.553513</X>
<Y>-73.262075</Y>
</coord>
<coord>
<X>42.556844</X>
<Y>-73.248157</Y>
</coord>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</shape>
</pd>
While these two representations are very similar and precise, they
are not widely used at present. If only a coverage area is required
without a nominal central point requiring specification, then this
form is ideal for representation using GML.
7. Baseline Geometry
PIDF-LO suggests to use GMLv3 feature.xsd, which provides a subset of
the available GML functionality. As a consequence a number of
further XML files are implicitly included, namely
geometryBasic0d1d.xsd, geometryBasic2d.xsd, temporal.xsd,
measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and
basicTypes.xsd, as being necessary to support. This provides for a
vast range of possibilities which would pose significant
complications to implementors wish to develop location dependent
routing applications. By agreeing to a minimal set of data
appropriate for routing, a minimum set of GML that MUST be
implemented by a given application type can also be set. This does
not preclude the additional functionality from being implemented,
merely that it may not be understood by some nodes.
7.1. Zero Dimensions
The minimum supported set of elements is position/Point/pos provided
by geometryBasic0d1d.xsd.
Thus a point location has only one representation as follows:
<gml:position xmlns:gml="http://www.opengis.net/gml">
<gml:Point srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>4.5 -36.2</gml:pos>
</gml:Point>
</gml:position>
The <location> and <coord> objects MUST NOT be used since they are
deprecated in GML 3.1 and their functionality can be substituted with
the above-described elements.
Note that pos allows altitude to be expressed based on the selected
Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most
Coordinate Reference Systems use altitude above the geoid and not
altitude above the ground.
7.2. One Dimensions
Support for one dimensional shapes (such as the LineString or the
posList object)is not required except as a part of two dimensional
shapes.
geometryBasic0d1d.xsd provides these geometric properties and
objects.
7.3. Two Dimensions
The examples previously used were all contructed using elements from
this schema which reuse functionality from geometryBasic2d.xsd. As
was described earlier the arcband definition in GML is problematic
for producing a closed solid and SHOULD consequently be avoided. As
a result of this, elements required exclusively for representing the
arcband shape have not been included in the minimum supported element
set. The minimum element set is therefore restricted to circle and
polygon.
Circle:
extentOf/
Polygon/
exterior/
Ring/
curveMember/
Curve/
segments/
CircleByCentrePoint/ -> Circle
pos
radius
Alternatively it would be possible to use the following structure to
express a circle using the <gml:Circle> element with three pos
elements as well. However, the usage of pos and radius, as shown
above, is inline with the model used by the 3GPP.
Polygon:
extentOf/
Polygon/
exterior/
LinearRing/
pos or posList -> Polygon
7.4. Three Dimensions
Support for three dimensions is not required
7.5. Envelopes
The Envelope element is a representation of a bounding box and can be
expressed in two or three dimensions. Defining a space using the
Envelope element should be done with extreme caution due to
continuity problems at the extremities of the CRS. In WGS-84, two
envelopes are required at the 180th meridian. The minimum set of
elements required to support an Envelope are:
boundBy/
Envelope/
upperCorner/
Point/
Pos
lowerCorner/
Point/
Pos/
7.6. Temporal Dimensions
Support for temporal elements is not required
7.7. Units of Measure o Point (2d or 3d)
The base SI units as a minimum MUST be supported. For measures of o Polygon (2d)
distance this is metres. The EPSG URN for metres is:
metres = urn:ogc:def:uom:EPSG:9001:6.6 o Circle (2d)
Angles are frequently expressed in terms of both degrees and radians, o Ellipse (2d)
consequently both MUST be implemented.
degrees = urn:ogc:def:uom:EPSG:9102:6.6 o Arc band (2d)
radians = urn:ogc:def:uom:EPSG:9101:6.6
Further units of measurement are not required. o Sphere (3d circle)
7.8. Coordinate Reference System (CRS) o Ellipsoid (3d)
There are a very large number of coordinate reference systems in o Prism (3d polygon)
existence today, but many are, however, not in widespread use.
Existing communications protocols such as those used in both the
ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized
on WGS-84. It is recommended for routing purpose that only WGS-84
coordinate types MUST be implemented and further that this set be
restricted to the following:
WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326 [5] also describes a standard set of coordinate reference systems
WGS84(3D) = urn:ogc:def:crs:EPSG:6.6:4979 (CRS), unit of measure and conventions relating to lines and
distances that will be repeated here.
8. Recommendations 7. 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 4 give guidelines on the ambiguity of PIDF-LO with regard to Section 4 give guidelines on the ambiguity of PIDF-LO with regard to
the occurrence of multiple location information. It is recommend the occurrence of multiple location information. It is recommend
that gml:position, gml:pos types be used to specify locations when that only the shape types and shape representations described in [5]
locations are needed for routing and specifically emergency routing. be used to express geodetic locations for exchange between general
Enhancements to GMLv3 feature.xsd may need to be defined to allow applications. By standardizing geodetic data representation
complex shapes types to be specified in a way that makes them easy to interoperability issues are mitigated.
distinguish and validate. This is particularly important if the data
is to be used during the decision making process of routing signaling
messages.
Only a limited subset of GML functionality from the feature.xsd
schema is necessary to describe a geodetic location with sufficient
precision to allow a routing decision to be made. Restricting both
the amount of GML that MUST be implemented, and the number of
variations in which this data can be expressed significantly reduces
the likelihood of interoperability issues in the future. Precedents
exist in the other communications protocols for restricting CRS types
and representations for the sake of simplicity and interoperability,
and the recommendation is made to adopt similar restrictions for
mandatory implementable components of GeoPriv.
If Geodetic information is to be provided via DHCP, then a minimum If Geodetic information is to be provided via DHCP, then a minimum
resolution of 20 bits SHOULD be specified for both the Latitude and resolution of 20 bits SHOULD be specified for both the Latitude and
Longitude fields so that sub 100 metre precision is achieved. Where Longitude fields to achieve sub 100 metre precision. Where only two
only two dimensional objects are required polygons SHOULD be used to dimensional objects are required polygons SHOULD be used to express
express the enclosed area. Where 3 dimensions are required a 3 the enclosed area. Where 3 dimensions are required a rectangular
dimensional bounding box representing a rectangular prism SHOULD be prism SHOULD be used.
used with care taken around the 180th meridian.
9. Security Considerations 8. 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 9. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
11. Acknowledgments 10. 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 James Polk and discussions in the context of PIDF-LO, in particular Carl Reed, Ron
Henning Schulzrinne. Furthermore, we would like to thanks Jon Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
Peterson as the author of PIDF-LO and Nadine Abbott for her to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
constructive comments in clarifying some aspects of the document. her constructive comments in clarifying some aspects of the document.
12. Open Issues
Need to get define minimal subset of Civic information that is useful
for routing purposes. May be hard to get normative, but hopefully we
can get something that is generally representative.
Need agreement on minimal set of shape support.
Need to go through the rules to enhance clarity. These rules are 11. Open Issues
highly likely to be important in quite a number of Location Dependent
Routing (LDR) based applications, including ECRIT. General feedback
is that they are not clear or precise enough yet. Henning has
provide some good feedback here that I have not had time to
incorporate yet, some of these comments will hopefully be easier to
resolve if open issue 1 above is also resoved.
13. References Do we need to indicate which shapes are acceptable for emergency
calling? Ceratinly not all can be used today, for example the
polygon and prism types will not work with NENA i2 as it is defined
today due to restrictions over the VE2 interface [7].
13.1. Normative references 12. References
[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 12.1. Normative references
RFC 4119, December 2005.
[2] 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.
13.2. Informative References 12.2. Informative References
[3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", [3] Peterson, J., "A Presence-based GEOPRIV Location Object
March 2004. Format", RFC 4119, December 2005.
[5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-01 (work in
progress), January 2006.
[5] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
for the Representation of Uncertainty in PIDF-LO",
January 2006.
[6] 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", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006. progress), January 2006.
[6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". [7] "NENA Standard for the Implementation of the Wireless Emergency
Service Protocol E2 Interface".
[7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [8] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-07 (work in
progress), February 2006.
[9] "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)".
[8] "NENA Standard for the Implementation of the Wireless Emergency [10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
Service Protocol E2 Interface".
[9] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-06 (work in
progress), October 2005.
[10] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in
progress), September 2004.
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data
RFC-3825 [3] describes a means by which an end-point may learns it RFC-3825 [2] describes a means by which an end-point may learns it
location from information encoded into DHCP option 123. The location from information encoded into DHCP option 123. The
following section describes how and end-point can take this following section describes how and end-point can take this
information and represent it in a well formed PIDF-LO describing this information and represent it in a well formed PIDF-LO describing this
geodetic location. geodetic location.
The location information described in RFC-3825 consists of a The location information described in RFC-3825 consists of a
latitude, longitude, altitude and datum. latitude, longitude, altitude and datum.
A.1. Latitude and Longitude A.1. Latitude and Longitude
skipping to change at page 36, line 16 skipping to change at page 22, line 16
The altitude elements define how the altitude is encoded and to what The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either metres, or level of precision. The units for altitude are either metres, or
floors, with the actual measurement being encoded in a similar manner floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8 to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components. bit fractional components.
A.3. Generating the PIDF-LO A.3. Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used. If the geodetic location expressed by a polygon SHOULD be used, with points
altitude is expressed in floors and is required, the altitude SHOULD expressed in a counter-clockwise direction. If the altitude is
be expressed as a civic floor number as part of the same location- expressed in floors and is required, the altitude SHOULD be expressed
info element. In the example above the GML for the location would be as a civic floor number as part of the same location-info element.
expressed as follows: In the example above the GML for the location would be expressed as
follows:
<gml:extentOf>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList srsName="urn:ogc:def:crs:EPSG:6.6:4326">
-34.4165 150.5332 <Polygon srsName="urn:ogc:def:crs:EPSG::4326"
-34.4165 150.5337 xmlns="http://www.opengis.net/gml">
-34.4170 150.5537 <exterior>
-34.4170 150.5532 <LinearRing>
-34.4165 150.5332 <pos>-34.4165 150.5332</pos>
</gml:posList> <pos>-34.4170 150.5532</pos>
</gml:LinearRing> <pos>-34.4170 150.5537</pos>
</gml:exterior> <pos>-34.4165 150.5337</pos>
</gml:Polygon> <pos>-34.4165 150.5332</pos>
</gml:extentOf> </LinearRing>
</exterior>
</Polygon>
If a floor number of say 3 were included, then the location-info If a floor number of say 3 were included, then the location-info
element would contain the above information and the following: element would contain the above information and the following:
<cl:civilAddress> <civicAddress
<cl:FLR>2</cl:FLR> xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
</cl:civilAddress> <FLR>2</FLR>
</civicAddress>
When altitude is expressed as an integer and fractional component, as When altitude is expressed as an integer and fractional component, as
with the latitude and longitude, it expresses a range, and this with the latitude and longitude, it expresses a range which requires
cannot be easily expressed in polygon form. Envelopes, as described the prism form to be used. Care must be taken to ensure that the
earlier, define upper and lower bounds for rectangular enclosures, points are defined in a counter-clowise direction to ensure that the
both in two and 3 dimensions, and SHOULD be used where an altitude upward normal points up.
range is specified. Care must be taken around the 180th meridian to
ensure a misrepresentation does not occur should the 180th meridian
be crossed.
Extending the previous example to include an altitude expressed in Extending the previous example to include an altitude expressed in
metres rather than floors. AltRes is set to a value of 19, and the 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 Altitude value is set to 34. Using similar techniques as shown in
the latitude and longitude section, a range of altitudes between 32 the latitude and longitude section, a range of altitudes between 32
metres and 40 metres is described. The Envelope would therefore be metres and 40 metres is described. The prism would therefore be
defined as follows: defined as follows:
<gml:boundBy> <Prism srsName="urn:ogc:def:crs:EPSG::4976"
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:6.6:4976"> xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
<gml:upperCorner> xmlns:gml="http://www.opengis.net/gml">
<gml:Point> <base>
<gml:Pos>-34.4165 150.5337 40</gml:Pos> <gml:Polygon>
</gml:Point> <gml:exterior>
</gml:upperCorner> <gml:LinearRing>
<gml:lowerCorner> <gml:pos>-34.4165 150.5332 32</gml:pos>
<gml:Point> <gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:Pos>-34.4170 150.5332 32</gml:Pos> <gml:pos>-34.4170 150.5537 32</gml:pos>
</gml:Point> <gml:pos>-34.4165 150.5337 32</gml:pos>
</gml:lowerCorner> <gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:Envelope> </gml:LinearRing>
</gml:boundBy> </gml:exterior>
</gml:Polygon>
</base>
<height uom="urn:ogc:def:uom:EPSG::9001">
8
</height>
</Prism>
The Method value SHOULD be set to DHCP. Note that this case, the The Method value SHOULD be set to DHCP. Note that this case, the
DHCP is referring to the way in which location information was DHCP is referring to the way in which location information was
delivered to the IP-device, and not necessarily how the location was delivered to the IP-device, and not necessarily how the location was
determined. determined.
The timestamp value SHOULD be set to the time that location was The timestamp value SHOULD be set to the time that location was
retrieved from the DHCP server. retrieved from the DHCP server.
The client application MAY insert any usage rules that are pertinent 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 to the user of the device and that comply with [8]. A guideline is
that the any retention-expiry value SHOULD NOT exceed the current that the any retention-expiry value SHOULD NOT exceed the current
lease time. lease time.
The Provided-By element SHOULD NOT be populated as this is not The Provided-By element SHOULD NOT be populated as this is not
provided by the source of the location information. provided by the source of the location information.
The 3 completed PIDF-LO representations are provided below, and The 3 completed PIDF-LO representations are provided below, and
represent a location without altitude, a location with a civic represent a location without altitude, a location with a civic
altitude, and a location represented as a 3 dimensional rectangular altitude, and a location represented as a 3 dimensional rectangular
prism. prism.
<?xml version="1.0"?> <?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://opengis.net/gml" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com"> entity="pres:user@example.com">
<tuple id="a6fea09"> <tuple id="a6fea09">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:extentOf> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:Polygon>
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList <gml:pos>-34.4165 150.5332</gml:pos>
srsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:pos>-34.4170 150.5532</gml:pos>
-34.4165 150.5332 <gml:pos>-34.4170 150.5537</gml:pos>
-34.4165 150.5337 <gml:pos>-34.4165 150.5337</gml:pos>
<gml:pos>-34.4165 150.5332</gml:pos>
-34.4170 150.5537
-34.4170 150.5532
-34.4165 150.5332
</gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gml:extentOf>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules/>
</gp:usage-rules> <gp:method>DHCP</gp:method>
<method>DHCP</method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp> <timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
<?xml version="1.0"?> <?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" 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:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com"> entity="pres:user@example.com">
<tuple id="a6fea09"> <tuple id="a6fea09">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:extentOf> <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:Polygon>
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList <gml:pos>-34.4165 150.5332</gml:pos>
srsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:pos>-34.4170 150.5532</gml:pos>
-34.4165 150.5332 <gml:pos>-34.4170 150.5537</gml:pos>
-34.4165 150.5337 <gml:pos>-34.4165 150.5337</gml:pos>
-34.4170 150.5537 <gml:pos>-34.4165 150.5332</gml:pos>
-34.4170 150.5532
-34.4165 150.5332
</gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gml:extentOf>
<cl:civilAddress> <cl:civilAddress>
<cl:FLR>2</cl:FLR> <cl:FLR>2</cl:FLR>
</cl:civilAddress> </cl:civilAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules/>
</gp:usage-rules> <gp:method>DHCP</gp:method>
<method>DHCP</method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp> <timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
<?xml version="1.0"?> <?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://opengis.net/gml" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com"> entity="pres:user@example.com">
<tuple id="a6fea09"> <tuple id="a6fea09">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:boundBy> <gs:Prism srsName="urn:ogc:def:crs:EPSG::4976">
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:6.6:4976"> <gs:base>
<gml:upperCorner> <gml:Polygon>
<gml:Point> <gml:exterior>
<gml:Pos>-34.4165 150.5337 40</gml:Pos> <gml:LinearRing>
</gml:Point> <gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:upperCorner> <gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:lowerCorner> <gml:pos>-34.4170 150.5537 32</gml:pos>
<gml:Point> <gml:pos>-34.4165 150.5337 32</gml:pos>
<gml:Pos>-34.4170 150.5332 32</gml:Pos> <gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:Point> </gml:LinearRing>
</gml:lowerCorner> </gml:exterior>
</gml:Envelope> </gml:Polygon>
</gml:boundBy> </gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
8
</gs:height>
</gs:Prism>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules/>
</gp:usage-rules> <gp:method>DHCP</gp:method>
<method>DHCP</method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp> <timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
 End of changes. 93 change blocks. 
834 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/